That's common for machine code written without an assembler but typed directly into a hex monitor (don't know if Invaders was developed that way though). You kept a couple of nops in 'reserve' - usually after branches and returns - so that fixes can be applied without having to move the rest of the code around (which would mean retyping everything).
Manually add up all cycles for each instruction in each branch, then pad the shorter with noop to make them the same. Repeat for each code path, and cry when you need to make a change.
I first stumbled upon this game in the 1990s in my school’s computer laboratory. I wanted to develop something similar on my own but the little GW-BASIC programming I knew and the very limited access to computers (<= 3 hours per month) I had wasn’t sufficient to take on an endeavour like this. I did write a few simple text adventure games and a BRICKS clone too. But writing an invaders-like game was too challenging for me back then.
Finally, three years ago, I sat down one afternoon and fulfilled that childhood dream of mine.
Here’s the result: https://susam.net/invaders.html
It’s a single HTML page with no external dependencies, so you are very welcome to “View Source”.
So congrats on sticking to it to complete yours
Coin-op video games have (2) because they use the same coin mechanisms as pinball games and have the same vulnerability.
I used to play pinball seriously [1][2] and frequently found machines where the type 1 tilt was insensitive or not working at all, whereas I never found a machine where the type 2 tilt didn't work. The type 2 tilt still gives you trouble when using certain tactics to rescue the ball from the drain, such as giving a hard impact to the left or right front of the table, though pulling the table quickly a few inches forward works on a machine with a dead type 1 tilt.
[1] get a score two orders of magnitude higher than most people would think possible, leave 30 credits on the machine
[2] get threatened that they'd kick me out of the game room as an undergraduate at a state school, never get bothered as a grad student at an Ivy League school
The "slam tilt" switch for [2] is a leaf switch with a small intertial counterweight on one of the leafs and rarely falls apart.
Funny enough, modern slot machines still call a tamper or intrusion event a "tilt".
> Also joining Apple Arcade on April 3 are Space Invaders Infinity Gene Evolve, the newest entry in the influential series by TAITO CORPORATION
https://www.apple.com/newsroom/2025/03/apple-arcade-launches...
https://apps.apple.com/us/app/spaceinvaders-infinitygene-evo...
Here’s how to add it, if you’re curious. (Blog is from a job site I run.)
https://www.firmwarejobs.com/blog/buildroot-by-example-pt-1-...
I guess there are two ways to do it. One is to use an FPGA board, but you would need to build a soft core. The other is to buy physical components (CPU, clocks, resistors, capacitors, ROMs/RAMs, etc.) and build a prototype on a few bread boards, in Ben Eater's style, but you need to purchase a lot of components.
I wouldn't go down the emulation route because it is less interesting.
The more I think about it, the more I think it's fun project. One gets to learn so much with it. I have always wondered how the Japanese built those little machines that made -- and still make the world gone crazy, but all those interviews with Nintendo/Sony/Sega people were mostly focused on game directors, producers, designers and artists. There were not even enough with programmers, let alone hardware designers. But I could be wrong. Maybe I just didn't look hard enough or need to learn Japanese.
Emulation with an FPGA is arguably harder.
Hardest of all is copying the earlier video games where everything ran on discrete logic - often extremely clever.
Even something like Pong is an interesting challenge.
On the other hand, many of the old games are exhaustively documented and built for component-level repair. A trade-off, I suppose.
What does this mean? I'm not aware of a big pickup in analog computing.
I'm wondering what the mechanism is here to avoid bus contention between the video circuit and the CPU both accessing the VRAM at the same time.
Might be evident from studying the schematic I would suppose...
“Space Invaders uses a simple display format where bytes are read from memory in order via an address counter, and shifted out via a shift register. Timing is controlled by discrete hardware.
The video hardware has priority over the CPU. When it needs to read a byte it asserts the 8080's READY signal, giving it exclusive access to the memory bus. This can be seen on the schematic (https://www.robotron-2084.co.uk/taito/documents/space-invade...) at 5F.
This technique has the advantage of the 8080 not having to be synchronized with the display hardware at all.”
The 2600 had 128 bytes of RAM. It supported a small number of fixed sprites. These were implemented by setting the X and Y coordinates in registers; as the scan-out of pixels passed that point, it would switch to drawing in the sprite color if a pixel was present at the bit position in the sprite.
It was possible to count how far down the screen the scan-out had got and re-use a sprite that had already been used above, to get more than the allowed number of sprites.
See the book Racing the beam for a lot more detail.
Edit: however this WAS a VRAM system. Seems to have added a dedicated shift helper but is still using blitting to VRAM. See "game timing" section of OP page.
Many times the RAM was dual ported (CPU writes while video hardware reads).
Other times they'd do clever clock tricks... for example, using 10 MHz capable RAM, generate a 10 MHz clock, and divide it down to two different 5 Mhz. One 5MHz clock is sync'd to the rising edge of 10 MHz, the other is sync'd to the falling edge. Sort of "interleaving" the two 5 MHz clocks. Total clock rate is 10 MHz, but the two 5MHz hardware circuits are out of phase and don't interfere with each other.
Later on, as RAM prices fell and double buffered images became economically possible in arcade machines, true page flipping started getting used, they would simply isolate the CPU and video buses from each other as the frame buffer was flipped. I know this is how things worked on I, Robot (1984)... this technique could have been used earlier but not much as not many games had real frame buffers at the time.