Rush Hour ?-??-83


This is the earliest of three known prototypes for Rush Hour.  While all three prototypes are fairly far along, they differ greatly in their stability.  This prototype has a very unstable display and is prone to rolling and flickering to the point of making it nearly impossible to play.  Also everything is slower in this version due to the lower framerate which is the result of timer underflows.  The oil slicks are functional in this version 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 framerate is lower which results in everything being slightly slower
The starting tune is much slower
The sounds are slower and longer
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
Some different source code fragments are visible in the code:

The graphics are a few scanlines higher
There is one fewer HMOV line on the left side of the screen
The initial timer values are different
There is debugging code active


Note the debug graphics on the bottom


There's also one fewer HMOV line


The debug graphics mirror each other when you find the carriers for some reason


The game gets out of sync a LOT



Return to Rush Hour