Rush Hour ?-??-83


This is the second of three known prototypes for Rush Hour.  While it is much more stable than the first prototype, it still has major issues with its display kernel.  It appears that some of the source code fragments present in the earlier prototype have been removed here.  Another difference in this prototype is that the oil slicks are functional whereas they were disabled in the last version.  The reason for this is because the code for the skidding caused by the oil slicks is extremely buggy and can cause the player to continually skid upwards (pinning the player to the top of the road) if the car hits one in the bottom lane.  This bug also is also triggered if the player hits a car in the bottom lane as car collisions also trigger the skidding code.

What makes these prototypes interesting is that there is some odd debugging code active that at first glance looks like random garbage on the screen.  The reason for this is that the programmer was trying to figure out how long specific blocks of code were taking so he could adjust them because if the code takes too long or too little time it can cause the display kernel to lose sync which makes the picture roll or flicker.

The way this debugging code works is that the code displays whatever value is in register PF2 (playfield register 2) and outputs it on the screen as graphics.  Normally this value is just a loop timer value that counts down to zero and will display whatever number it is currently on as a graphic pattern on the screen based on which bits are set for the given number in binary (eg. a 4 will display a x-- pattern, 3 will display an -xx, 2 will display -x- , and 1 will display a --x pattern).  These patterns are the 'graphical garbage that is displayed over the screen.  This timer normally runs every 64 cycles, however if the timer underflows then the loop countdown happens every cycle which creates a different looking pattern.  This is when the game begins to lose sync and roll.

The programmer was attempting to fix these issues by setting initial timer values which controlled how long a block of code is allowed to run.  By tweaking these values the programmer was able to get the display to be more and more stable.  It's also worth noting that Rush Hour uses a great many timer values for its code whereas most games only use two.


The oil slicks are functional and cause the player to skid in a random direction
Being hit by a car causes the player to skid randomly in a direction
There is a bug with the skidding code hat cause your car to continually skid upwards if you get hit in the bottom lane
The graphics are a few scanlines higher
The initial timer values are different
There is debugging code active


Those graphics below the radar mean there is an underflow in the loop


Notice how everything is a few scanlines higher


The color and appearance of the debug graphics change depending on what's happening in the game


The game still completely loses sync sometimes



Return to Rush Hour