History was made lastnight in Space Armada....

[History was made lastnight in Space Armada....]

No prob, mr_me. For sure, this is a very difficult glitch to exploit. I was able to replicate only part of it, and then only with a few hacks to the ROM (invincibility, indestructible shields, etc.). You have to catch the program in a very particular state. Because the missile goes through the saucer (i.e., continues up after hitting the saucer, as opposed to disintegrating as it does when it hits a shield or armada ship), I believe you have to hit the saucer through the shield, so that your missile disintegrates fast enough to be able to shoot another missile before the saucer “breaking apart” animation is completed. Then, on top of that, the timing must be such that the saucer has not registered as depleting your shield (this ensures both that you get points for the saucer strike and that your shield gets rebuilt, so that you can continue doing this forever). As I have not completely replicated this (particularly the part where the appearance of the next armada is delayed), I may have some of the details wrong or missing.

 

Putting the eligibility for inclusion in high score lists aside, I would consider catching this glitch a considerable feat of skill and luck. Having spent uncountable hours into this game as a child without ever witnessing the glitch, my hats off to anyone who is able to do it.

[Hardware Questions for the Creator of the Colecovision?]

Thank you for the color, Thom. I'm still curious whether it was ever considered to contract out (or hire the means to develop internally) any custom silicon. Without an exclusive license (which I doubt TI gave them), using off the shelf chips is a not the most sound choice from a business perspective, as competitors can easily copy (although with 20/20 hindsight, that didn't turn out to be how the market played). There were better custom/proprietary chips out there, and other players in the market who had the means to engineer their own ICs. Would love to know whether my childhood console system was ever contemplated to be something even better than what it was.

[Hardware Questions for the Creator of the Colecovision?]

Would love to know whether they ever considered using a more powerful graphics processor than the relatively off-the-shelf TI processor with only 16 colors / 1 color per sprite.

[History was made lastnight in Space Armada....]

This is very cool, and I had never known about this glitch in the game. Trying it out, I’ve been able to reproduce it, at least the portion where the saucer “respawns” (not that part where the appearance of the new armada is delayed as a result of continuing to shoot the saucer).

 

Having read the code for this game a few years ago to implement invincibility and other hacks, I can tell you that you shouldn’t read too much into the fact that the game allows seemingly unreachable scores. The game does in fact allow nine-digit scores (sorry if that’s a spoiler). The reason for this, however, is very mundane. The game code uses 16-bit RAM to store the score. The score is stored in a special format that allows the game code to easily display it on screen by just calling a procedure in the Intellivision’s “EXEC” (the Intellivision’s “operating system,” if you will, that is stored in ROM on the Intellivision’s circuit board). Without boring you with the details, a score stored in this format in only one 16-bit memory location would limit the score to a number that is far too low and very achievable. So, the programmers used two 16-bit memory locations (one memory location for the least significant 16 bits of the score and another memory location for the most significant 16 bits). In that format, using 32 bits, the score can indeed go up to nine decimal digits.

 

As for the glitch, this is how it works: The EXEC tells the cartridge program when a collision has occurred on the screen, such as when two sprites come into contact with each other or when a sprite comes into contact with a tile on the screen. The Intellivision’s hardware can support only eight sprites natively, and the game code uses one of these eight sprites for the saucer and another for the missile that the player shoots. When the saucer gets hit by a missile sprite, the game code changes the graphics of the saucer sprite to go through the animation of the saucer breaking apart. However, if you hit the saucer while it is in the middle of its “breaking apart” animation, the EXEC registers that as another collision between the missile sprite and the saucer sprite and notifies the game code. The game code then thinks a new saucer was struck, so it gives the player points for another saucer strike and then restarts the “breaking apart” animation. If timed right, and the saucer is low enough that the time it takes for a new missile to hit the saucer is less than the time it takes for the full “breaking apart” animation to take its course, this can go on forever. What the game code should have done when it receives notification of a collision between a saucer and a missile is first check whether that saucer sprite is already in the middle of its “breaking apart” animation (and, if so, not restart the animation or award additional points).