1. The 810 bug is interesting in that there is no obvious reason for it. There's nothing interesting about that number that would lead one to expect to find bugs occurring there. It's not at any interesting boundary in decimal or binary, for instance, where it might hit some special case that is easy to botch.
I've never heard any explanation for what the devil was happening.
2. Speaking of botched special cases, Defender also had a bug that gave you a lot of bonus ships, although the Defender bug actually made sense.
Defender wrapped at 1 million. If the bonus was 10k, as soon as you hit 990k it started giving you a bonus ship every time you did anything that scored points. This lasted until you wrapped. You then stopped getting bonus ships until you scored enough points to earn all those bonus ships you had gotten from the bug between 990k and wrap.
I've read that the reason for this bug was pretty simple. Every time you scored, the game did something like this:
if new_score > next_bonus
award_bonus_ship()
next_bonus += 10k
So consider when next_bonus == 990k. You hit or cross 990k, get a bonus ship, and next_bonus gets bumped up to 1 million...but that's the wrap point, so next_bonus actually gets set to 0. Now you earn some more points, but are still between 990k and 1 million. Your score is greater then next_bonus (which is 0), so you get a bonus, and next_bonus goes to 10k. Repeat until new_score finally wraps.
3. The most spectacular bug I've seen in an arcade game was in Battlezone, the vector graphics tank battle game, the one where you fought another tank on a plane littered with cubes and pyramids, with jagged mountains in the distance.
After a while, if you evaded the shots from the enemy long enough but failed to kill him, the enemy tank would go away and a missile would come for you, which was much harder to kill than a tank.
Some clever people figured out that if you timed it right, you could get it to send the missile while the last shot from the enemy tank was still in transit. If you then died on that shot, when the next round started, the damn missile would still be there. This was pretty anoying, until someone got the bright idea of doing this ON THEIR LAST TANK.
The game then gives the GAME OVER screen, and then it goes into attract mode where it runs a demo script showing game play. That leftover missile ends up in the demo, where it kills the demo tank, and the demo round ends. Apparently, whoever wrote the demo script did not expect the demo tank to ever die, so the demo ending at this point was unexpected, and according to the story we heard, the machine crashed and needed a hard reboot.
We knew someone who owned a Battlezone, and told him about this. He put some free games on and let our best Battlezone player try to set this up. It did indeed work, and the left over missile did indeed kill the demo tank.
And then we smelled burning electronics and the monitor burned out. Apparently, the software was responsible for the monitor timing, and could put it in states that were very very bad.
Of course, this one example doesn't prove that our experiment actually killed the hardware--it could have just been a coincidence. The owner was a Caltech student, and so understood what it took to do a proper experiment, but for some reason refused to let us do the experiment again once he replaced the monitor.
1. The 810 bug is interesting in that there is no obvious reason for it. There's nothing interesting about that number that would lead one to expect to find bugs occurring there. It's not at any interesting boundary in decimal or binary, for instance, where it might hit some special case that is easy to botch.
I've never heard any explanation for what the devil was happening.
2. Speaking of botched special cases, Defender also had a bug that gave you a lot of bonus ships, although the Defender bug actually made sense.
Defender wrapped at 1 million. If the bonus was 10k, as soon as you hit 990k it started giving you a bonus ship every time you did anything that scored points. This lasted until you wrapped. You then stopped getting bonus ships until you scored enough points to earn all those bonus ships you had gotten from the bug between 990k and wrap.
I've read that the reason for this bug was pretty simple. Every time you scored, the game did something like this:
So consider when next_bonus == 990k. You hit or cross 990k, get a bonus ship, and next_bonus gets bumped up to 1 million...but that's the wrap point, so next_bonus actually gets set to 0. Now you earn some more points, but are still between 990k and 1 million. Your score is greater then next_bonus (which is 0), so you get a bonus, and next_bonus goes to 10k. Repeat until new_score finally wraps.3. The most spectacular bug I've seen in an arcade game was in Battlezone, the vector graphics tank battle game, the one where you fought another tank on a plane littered with cubes and pyramids, with jagged mountains in the distance.
After a while, if you evaded the shots from the enemy long enough but failed to kill him, the enemy tank would go away and a missile would come for you, which was much harder to kill than a tank.
Some clever people figured out that if you timed it right, you could get it to send the missile while the last shot from the enemy tank was still in transit. If you then died on that shot, when the next round started, the damn missile would still be there. This was pretty anoying, until someone got the bright idea of doing this ON THEIR LAST TANK.
The game then gives the GAME OVER screen, and then it goes into attract mode where it runs a demo script showing game play. That leftover missile ends up in the demo, where it kills the demo tank, and the demo round ends. Apparently, whoever wrote the demo script did not expect the demo tank to ever die, so the demo ending at this point was unexpected, and according to the story we heard, the machine crashed and needed a hard reboot.
We knew someone who owned a Battlezone, and told him about this. He put some free games on and let our best Battlezone player try to set this up. It did indeed work, and the left over missile did indeed kill the demo tank.
And then we smelled burning electronics and the monitor burned out. Apparently, the software was responsible for the monitor timing, and could put it in states that were very very bad.
Of course, this one example doesn't prove that our experiment actually killed the hardware--it could have just been a coincidence. The owner was a Caltech student, and so understood what it took to do a proper experiment, but for some reason refused to let us do the experiment again once he replaced the monitor.