Comment on Kool-Aid Man (1983) for the Atari 2600
Redkey@programming.dev 1 week ago
There’s a… not exactly a bug, but an unannounced change, in the graphics chip in some later versions of the Atari 2600, which has been named after this game by the fan/homebrew community. On most 2600 console versions, it’s possible for a game to perform a particular graphics operation at an unintended time and get an undocumented but consistent and useful result.
On the differing consoles, the result is slightly different, and because of the way this game is written, it often causes a chain of actions that end up making Kool-Aid Man bounce around continuously as if being hit by enemies, even though nothing is touching him.
FiddlersViridian@sh.itjust.works 1 week ago
Interesting! I’ve never heard of that before, and I love this sort of thing. Do you have any more info about it, or maybe an Atariage thread with more details?
I did a quick search and found a couple references to a problem with it on the 2600 Jr when the difficulty switch is set to A. Is that it?
Redkey@programming.dev 1 week ago
I’ve been trying to research the various glitches and variations between versions because I’m working on something that uses some undocumented features and precise timing. Unfortunately, I don’t have one good link that explains it well.
The issue stems from how player objects (the 2600 equivalent to sprites) are placed horizontally. For good and interesting reasons which are also technically involved and complicated, programmers can’t just send an X value to the graphics chip. Instead there’s a two-step process. First, the program sends a signal to the graphics chip when the TV raster is at approximately the desired horizontal position on the screen. Then, because it’s often not possible to nail the timing of that signal to the exact pixel position, the graphics chip has a facility to “jog” the various graphical objects left or right by a very small amount at a time.
According to the official programmers’ documentation, this final “jog” should only be done at one specific time during each video scanline. If we only do it this way, it works correctly on pretty much every version of the console. However, doing it “correctly” also introduces a short black line at the left side of that scanline. If we instead send the “jog” signal at certain other times, no black line appears. Additionally, the exact distances moved change depending on when we send the signal, which can be worked around or are sometimes even beneficial.
Kool-Aid Man uses these undocumented “jog” timings, as several games did. But it displays a score counter at the top of the screen by using the player objects placed very close together. It seems that the console versions in question (later 2600 Juniors and some 7800s) are more sensitive to the timing being used, as you can sometimes see the parts of the score flicking left or right by one pixel.
The Atari 2600 also has a hardware collision detection system, which reports when any two moving screen objects overlap with each other or the background. Once a collision occurs, the relevant flag will stay set until the program clears it. Kool-Aid Man uses this system to detect when the player character touches enemies. But the program only clears the collision flags once, at the bottom of each frame, and the same player objects are used to draw the score. So when the two parts of the score flicker into each other, it registers as a collision between player objects, which the game interprets as a collision between Kool-Aid Man and a Thirsty.
As you mentioned, I’ve read that setting the console switches a certain way can prevent this issue, but I’m not sure why. My guess is that setting some switches one way rather than another causes a conditional branch instruction that checks the switches to branch rather than fall through, which takes one extra instruction cycle (or vice versa), which is then enough to stabilize the score display and stop the parts from colliding.
FiddlersViridian@sh.itjust.works 1 week ago
This is really interesting, thanks for the details. I fiddle around with 6510 assembly sometimes, and didn’t realize that the 6507 and other chips that the 2600 uses required those tricks for the player objects. The things that developers manage to make the 2600 do with such limited hardware blows my mind.
I have a couple different 2600 versions, a Jr, a colecovision Atari adapter and maybe a couple other variants in the closet that I’ll try to dig out this weekend and see how it handles this game! Unfortunately I don’t have a 7800, despite that being the console I had as a kid. I should add that to the wish list.