Si78c: Memory-accurate reimplementation of Space Invaders in C(github.com)
github.com
Si78c: Memory-accurate reimplementation of Space Invaders in C
https://github.com/loadzero/si78c
20 コメント
The keyboard controls are:
a LEFT
d RIGHT
1 1P
2 2P
j FIRE
5 COIN
t TILT
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?
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.
Were tilt sensors a damage prevention thing? I always assumed it was just an anti-cheat
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 just guessing...
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.
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.
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 admire the dedication to projects like this.
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.
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.
One past thread:
Show HN: Space Invaders in C - https://news.ycombinator.com/item?id=21719575 - Dec 2019 (105 comments)
Show HN: Space Invaders in C - https://news.ycombinator.com/item?id=21719575 - Dec 2019 (105 comments)
Very nice.
I did something similar in ARM7 (non-thumb) https://github.com/tuckerpo/MicroSpaceInvaders
I did something similar in ARM7 (non-thumb) https://github.com/tuckerpo/MicroSpaceInvaders
To get the rom
wget https://archive.org/download/MAME2003_Reference_Set_MAME0.78_ROMs_CHDs_Samples/roms/invaders.zip
unzip invaders.zip -d inv1[deleted]
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.
Holy Moly, look at that monster struct at line 125.
So much code for such a simple game.
Now imagine the code base of original Diablo. And yet, it run (still does) on a toaster.
So much code for such a simple game.
Now imagine the code base of original Diablo. And yet, it run (still does) on a toaster.
> Now imagine the code base of original Diablo.
No need to imagine! https://github.com/diasurgical/devilution
This is >99% binary exact when compiling with the original toolchain.
No need to imagine! https://github.com/diasurgical/devilution
This is >99% binary exact when compiling with the original toolchain.
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.)
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.
[deleted]
> 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.
That's just how interrupts work; it is not cooperative multitasking. Taking an interrupt which just returns (no scheduler) is not usually called preemption.
Agreed.
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.
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.
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/