Pong Game triggers game over immediately on MAC OSX

[intractablehero]

Hello,

I just finished Ch. 11 and passed all tests, however, when I run the Pong game in the VMEmulator on my Mac OSX (Monterey 12.4, Intel I7), game over is triggered immediately and a score of 1 is shown. I didn't get a chance to move the bat.. in 'no animation' mode game over is shown as soon as I click run.

I ran the exact same code on Linux, and the game works fine. Also, I noticed that translating the .jack code using the supplied JackCompiler tool resulted in the same behaviour; on my MAC, game over triggered immediately.

I wondered if the game was simply running 'too fast' on my Mac, and added a "do Sys.wait(50);" command at the very end of the Ball.move() method in Ball.jack. This fixed the issue!

I don't know enough about the source code, or differences in JRE on MAC/Linux, but is it possible there is such a speed difference when running the VMEmulator on Mac? I'm currently using Java SE Runtime Environment 18.0.1.1+2-6.

This post is mostly for curiosity, since my fix worked well enough to solve my problem. Just thought I'd let the community know and also hope someone more knowledgeable can answer my question. If there is a way to ensure consistent behaviour across OS's that would be good, since I plan on teaching from this textbook next year, and my students use different OS's.

Thanks!

ps - great book! Love it.

[WBahn]

That seems quite possible. In the early days of personal computers, nearly all machines ran at 4.77 MHz (that was a frequency that was easily derived from cheap television crystals). Because of the extreme limitation in both speed and memory, game makers relied heavily on delay loops to control timing and this worked well enough since most machines ran at the same clock speed. But then speeds started to increase and games ran too fast to play (as did other applications that either played this same timing game or that merely tried to run as fast as the machine allowed). This led to "Turbo" mode, which was a switch on the front of the machine that let the machine run at its normal speed -- in non-turbo mode, the system clock was reduced to 4.77 MHz so that affected legacy code could run properly.

Today, most code that has timing/speed sensitivities use operating system calls to control the speed to a consistent level. My guess is that VM emulator code for the MAC didn't get this done correctly.

[intractablehero]

Thank you!

-Robert

[The Gigabiter]

Turbo mode actually dropped back to 4.77 for some reason I cannot fathom. This led to some rather amusing incidents involving inexperienced people LOL!

[WBahn]

The Gigabiter wrote

Turbo mode actually dropped back to 4.77 for some reason I cannot fathom. This led to some rather amusing incidents involving inexperienced people LOL!

That wasn't the case on any of the machines I ever used. The default was that it was in Turbo mode and ran at the full clock frequency, while turning Turbo mode off artificially slowed the CPU down to the equivalent of 4.77 MHz (or close to it, depending on the technique used). We had a few machines where I worked that ran at 33 MHz or 66 MHz in Turbo mode and had a display on the case that showed that when in Turbo mode (of course, it was just a hardwired display, it wasn't actually measuring anything) and showed 'LO' when you took it out of Turbo mode.