> The assembly code is filled with lots of questionable structures. In general, there are lots and lots of NOP instructions. Some are executed in the code flow, but most are used as padding between code sections.
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).
Even using an assembler, (which we did most of the time), we would leave a pool at the end of each PROM (and they were PROMs with a 6 week lead time) so we could patch a bug and only have to change one PROM and not the whole set.
This is the game that originally inspired me to computer programming.
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.
Pinball games usually have two tilt mechanisms: (1) to prevent you from moving the playfield as a whole, and (2) to prevent you from smashing the coin mechanism in front of the cabinet because otherwise you could get free plays by smashing the coin mech.
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 "plumb-bob" tilt for [1] is dependent on a conical weight hanging on a rod, surrounded by a brass ring. Raising the weight higher or lower makes the tilt more or less sensitive by changing the distance between the cone and ring. Many operators adjust this and fail to fasten it tightly enough and the cone falls into the cabinet.
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".
The hardware part fascinates me more. Has anyone fancied building a X-bit game console drawing schematics?
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.
And of course Space Invaders was programmed inside of a Dwarf Fortress game. It’s simplified of course and not exactly real time lol. Wonder what it would take to emulate the full version inside of DF.
Objects at the top of the screen are drawn after the mid-screen interrupt. Objects at the bottom of the screen are drawn after the end-screen interrupt. Thus the code and hardware work on different halves of the screen.
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...
RAM was too expensive to have two full frame buffers with page flipping. So they resorted to timing tricks.
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.
Hardware sprite systems such as the Atari 2600 did not have any VRAM.
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.
“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.”
There was a vector-based cabinet predating Space Invaders: Cinematronics' Space Wars (1977), which used custom hardware to re-implement the original PDP-1 Spacewar! game. It was strictly a two-player game; you couldn't play against the computer. Cinematronics would use the platform for later games like Star Castle and Tail Gunner, also vector-based.
> The assembly code is filled with lots of questionable structures. In general, there are lots and lots of NOP instructions. Some are executed in the code flow, but most are used as padding between code sections.
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).
Even using an assembler, (which we did most of the time), we would leave a pool at the end of each PROM (and they were PROMs with a 6 week lead time) so we could patch a bug and only have to change one PROM and not the whole set.
And about the ones in the code flow, it was also pretty common practice in those days to use NOPs as time delays.
This is the game that originally inspired me to computer programming.
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”.
The background sound feels like a spacey jingle. I like it. It's mesmerizing lol.
Thanks! Yes, the background music too is inspired by the four-note loop of the original Space Invaders. Here’s the source code for it: https://github.com/susam/invaders/blob/0.9.0/invaders.html#L...
Pinball games usually have two tilt mechanisms: (1) to prevent you from moving the playfield as a whole, and (2) to prevent you from smashing the coin mechanism in front of the cabinet because otherwise you could get free plays by smashing the coin mech.
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 "plumb-bob" tilt for [1] is dependent on a conical weight hanging on a rod, surrounded by a brass ring. Raising the weight higher or lower makes the tilt more or less sensitive by changing the distance between the cone and ring. Many operators adjust this and fail to fasten it tightly enough and the cone falls into the cabinet.
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".
I always use ascii_invaders, an ncurses based Space Invaders clone, as my first test package on a new buildroot system.
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-...
New titles are still being produced by Taito. The corporation is a subsidiary of Square Enix since 2006, but I still find it impressive. E.g.:
> 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...
The hardware part fascinates me more. Has anyone fancied building a X-bit game console drawing schematics?
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.
Building a system around a vintage CPU is pretty straightforward, especially if you keep it simple with static memory.
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.
> Hardest of all is copying the earlier video games where everything ran on discrete logic
What does this mean? I'm not aware of a big pickup in analog computing.
Hardest of all is copying the earlier video games
On the other hand, many of the old games are exhaustively documented and built for component-level repair. A trade-off, I suppose.
And of course Space Invaders was programmed inside of a Dwarf Fortress game. It’s simplified of course and not exactly real time lol. Wonder what it would take to emulate the full version inside of DF.
https://youtu.be/j2cMHwo3nAU
Objects at the top of the screen are drawn after the mid-screen interrupt. Objects at the bottom of the screen are drawn after the end-screen interrupt. Thus the code and hardware work on different halves of the screen.
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...
RAM was too expensive to have two full frame buffers with page flipping. So they resorted to timing tricks.
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.
Hardware sprite systems such as the Atari 2600 did not have any VRAM.
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.
https://retrocomputing.stackexchange.com/a/11456:
“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.”
There was a vector-based cabinet predating Space Invaders: Cinematronics' Space Wars (1977), which used custom hardware to re-implement the original PDP-1 Spacewar! game. It was strictly a two-player game; you couldn't play against the computer. Cinematronics would use the platform for later games like Star Castle and Tail Gunner, also vector-based.
I loved Star Castle.
such a classic game
how do I play this