That must have taken a lot of dedication, looking through the code, they had to manually specify nearly every byte of the memory. I wonder how different this is from just writing an emulator for the original architecture.
That struct wouldn't actually have been in the original game. The idiomatic C analogue would be static variables inside functions, or (occasionally) global variables, but that wouldn't make it a memory-accurate reimplementation.
I think the game code proper starts around line 670, but still, there's quite a lot of emulator code interspersed with the game logic after that point. (Multiple-line functions for something that would've been a single memory read in the original game.)
Well, that struct is that toaster, or its memory layout declared in C syntax, including all the game's global variables. It's surprising how many there are.
> The original code is interrupt driven, and partially co-operatively multitasked. The game spends about a third of the time running the main thread, which gets pre-empted by the midscreen and vblank interrupts. The other two thirds of the time is split between those interrupt contexts, which are not pre-empted, but decide when to return to main.
That's just how interrupts work; it is not cooperative multitasking. Taking an interrupt which just returns (no scheduler) is not usually called preemption.
Especially since usually the entire point of an interrupt triggered by some hardware-related event (vsync, hsync etc) is that the main thread is not yielding or doing anything at all to cooperate.
The keyboard controls are:
a LEFT
d RIGHT
1 1P
2 2P
j FIRE
5 COIN
t TILT
TILT! I was surprised and amused to see that there's an actual tilt sensor input.
I think most people with a passing familiarity with arcade machines know that pinball machines had "tilt" sensors. People would smack, shake, tilt, etc. the tables in an attempt to change the trajectory of the ball. Or, perhaps they just abused them out of frustration. So, there were tilt sensors built into pinball machines that would end your game and light up a "TILT" message if tried those potentially damaging shenanigans. After all, those machines weren't cheap.
I had no idea they were built into early solid state games like Space Invaders as well. That's hilarious.
I guess people tried jiggling the machines in order to help them avoid the aliens? Or Taito, at least, feared they would?
Most pinball machines have two tilt sensors, one is the regular one that, in modern incarnations, chides you for tilting and if you do it too much will end your current ball. There's a second, the slam tilt sensor that mostly detects kicking the coin door, etc, and reboots the machine (ending the whole game and maybe dropping any existing credits)
I'm wondering if it was just "vestigial" from whatever boards they were using. I imagine a pinball machine base overlaps a fair amount with it's coin mechanisms.
I suspect it was damage prevention, much more so than cheating.
Cheating only affected the arcade owners if you were cheating on a busy machine, and somehow cheating well enough to actually extend your game. Longer games = less quarters.
But, really, how many people were cheating at pinball well enough to extend their games? I think that would take some serious skill. I think most people banging the machines damaged the machines far more often than they extended their games. So I think it was mostly about that.
The irony of the pinball TILT sensor, at least in my personal experience, is that if you don't understand what the "TILT!" indicator on the backboard means - which childhood me and my aunt, trying to play a game of pinball in probably a Pizza Hut in the late 80s and stymied by a mysterious "TILT" light, clearly did not - is that one might misinterpret it as an instruction to attempt tilting the machine, thereby facilitating exactly the sort of damaging behavior which the malfunctioning sensor was intended to guard against.
I always felt it's misleading to display these as white on black. In the original arcade they'd be visually suspended over a painted background, with colored cellophane applied to the glass.
First you have to (or someone else has to) disassemble the original binary, since the original source code is usually long gone.
Then you have to actually go through the code to try to understand it all - this is difficult to do in a high level language, but even more so in assembly. Even if it's already disassembled and someone else has already added comments it's still not easy.
If you don't already know the ASM language being used, you have to also learn that as you go.
Only once you have a complete understanding of the ASM code can you even begin reimplementing it in C.
Then you have to test it and make sure it actually functions like the original.
20 comments
[ 3.0 ms ] story [ 52.7 ms ] threadSo much code for such a simple game.
Now imagine the code base of original Diablo. And yet, it run (still does) on a toaster.
I think the game code proper starts around line 670, but still, there's quite a lot of emulator code interspersed with the game logic after that point. (Multiple-line functions for something that would've been a single memory read in the original game.)
No need to imagine! https://github.com/diasurgical/devilution
This is >99% binary exact when compiling with the original toolchain.
That's just how interrupts work; it is not cooperative multitasking. Taking an interrupt which just returns (no scheduler) is not usually called preemption.
Especially since usually the entire point of an interrupt triggered by some hardware-related event (vsync, hsync etc) is that the main thread is not yielding or doing anything at all to cooperate.
I think most people with a passing familiarity with arcade machines know that pinball machines had "tilt" sensors. People would smack, shake, tilt, etc. the tables in an attempt to change the trajectory of the ball. Or, perhaps they just abused them out of frustration. So, there were tilt sensors built into pinball machines that would end your game and light up a "TILT" message if tried those potentially damaging shenanigans. After all, those machines weren't cheap.
I had no idea they were built into early solid state games like Space Invaders as well. That's hilarious.
I guess people tried jiggling the machines in order to help them avoid the aliens? Or Taito, at least, feared they would?
I suspect it was damage prevention, much more so than cheating.
Cheating only affected the arcade owners if you were cheating on a busy machine, and somehow cheating well enough to actually extend your game. Longer games = less quarters.
But, really, how many people were cheating at pinball well enough to extend their games? I think that would take some serious skill. I think most people banging the machines damaged the machines far more often than they extended their games. So I think it was mostly about that.
http://tipsgeneral.com/how-to/geek-trivia-the-screen-of-spac...
Though, having said that, this source I just looked up to get a screenshot suggests that's actually an enhancement added after the initial release.
edit to add: a better, non-blogspammy article that discusses this and provides an emulator:
https://tobiasvl.github.io/blog/space-invaders/
Show HN: Space Invaders in C - https://news.ycombinator.com/item?id=21719575 - Dec 2019 (105 comments)
First you have to (or someone else has to) disassemble the original binary, since the original source code is usually long gone.
Then you have to actually go through the code to try to understand it all - this is difficult to do in a high level language, but even more so in assembly. Even if it's already disassembled and someone else has already added comments it's still not easy.
If you don't already know the ASM language being used, you have to also learn that as you go.
Only once you have a complete understanding of the ASM code can you even begin reimplementing it in C.
Then you have to test it and make sure it actually functions like the original.
I did something similar in ARM7 (non-thumb) https://github.com/tuckerpo/MicroSpaceInvaders