> 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.
It's required whenever your clock cycle time is near your timing requirements. Not so much a problem with multi GHz microcontrollers, but still needed for cheap ones.
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 know it's probably an intentional exaggeration... but are there really any microcontrollers over 1 GHz core clock? Fast I know of is ST at around 600 MHz.
Space Invaders was written by hand, as professional development tools cost way too much at that point. This interview contains a picture of a couple of the pages from the Space Invaders source code notebook. https://shmuplations.com/spaceinvaders/
Basically play "human assembler", write down the source code as assembler mnemonics on paper, then use a lookup table to convert the assembler mnemonics into hex machine code numbers, and type those numbers into the computer, while keeping track of jump target and subroutine start adresses.
// xref 0462
//
// This code is using the shot counter as an index into the ROM
// (where some code resides), for the purposes of random number generation.
//
// For the saucer direction logic, only bit 0 of each bytecode is used.
//
// The 256 bytes used reside at 0800 -> 08FF
//
// If you check bit 0 of each byte in that ROM section, you will find that there is no bias,
// and there are exactly 128 0's and 128 1's.
//
// It seems unlikely that this was an accident, I think Nishikado deliberately constructed
// the ROM this way, and used some well placed NOPs to achieve fair balance.
//
// E.g. these NOPs
//
// 0854: 00 00 00
// 0883: 00 00 00
//
// This information can be exploited to the player's advantage.
//
// If using the shot counting trick to get high scores, the
// expected saucer direction for the first 6 saucers (if counting),
// will be as follows:
//
// [22,37,52,67,82,97]
// [0, 1, 1, 0, 1, 1]
// [L, R, R, L, R, R]
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.
I had the same idea as an "over the weekend" project. I had the sprites moving (with each invader's "arms" animated while the grid moved) and could control the player. Clearly the "over the weekend" was too ambitious, and I stopped before ever trying to add fire/bullets/collision/etc. So I essentially got no where, but effectively killed the weekend while spending $0 while avoided doing other things that would have definitely cost >$0.
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.
Thank you. Looks like I overcomplicated things. I won't even use a vintage CPU, maybe a STM32, so that would be even easier. I guess the only complicated thing is if I want to invent "cartridges" so that involves some hardware.
And yeah I agree those earlier discrete logic games are tough to copy. I think those games were made in hardware with little software.
I think what he meant is that the earlier arcades were done directly in hardware with very little software, so you have to copy the hardware or use emulation.
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.
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...
“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.”
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.
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.
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.
> 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.
It's required whenever your clock cycle time is near your timing requirements. Not so much a problem with multi GHz microcontrollers, but still needed for cheap ones.
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.
Yep, it's a practice I still engage in with several of my microcontroller-based projects.
I know it's probably an intentional exaggeration... but are there really any microcontrollers over 1 GHz core clock? Fast I know of is ST at around 600 MHz.
ARM Cortex based ones exceed 1GHz [1]. Although, maybe the definition of microcontroller is a bit fuzzy these days.
[1] https://www.mouser.com/c/semiconductors/integrated-circuits-...
ARM Cortex-A is an application processor, not a microcontroller. With an MMU (can run a full OS like Linux) and without internal memory.
Cortex-M is a microcontroller, without MMU (can't run Linux etc.), and typically has internal RAM and flash.
Only the NXP i.MXRT1170 reaches 1 GHz CPU clock, and this is not multi-GHz as the prior comment declared.
Space Invaders was written by hand, as professional development tools cost way too much at that point. This interview contains a picture of a couple of the pages from the Space Invaders source code notebook. https://shmuplations.com/spaceinvaders/
“Space Invaders was written by hand”
I’m a neophyte. What do you mean by this? You mean “100100101…” by hand or…?
Basically play "human assembler", write down the source code as assembler mnemonics on paper, then use a lookup table to convert the assembler mnemonics into hex machine code numbers, and type those numbers into the computer, while keeping track of jump target and subroutine start adresses.
I think at least some of the NOPs are due to this
From my C transliteration: https://github.com/loadzero/si78c/blob/master/si78c.c
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”.
I had the same idea as an "over the weekend" project. I had the sprites moving (with each invader's "arms" animated while the grid moved) and could control the player. Clearly the "over the weekend" was too ambitious, and I stopped before ever trying to add fire/bullets/collision/etc. So I essentially got no where, but effectively killed the weekend while spending $0 while avoided doing other things that would have definitely cost >$0.
So congrats on sticking to it to complete yours
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...
Very nice. I have a sim. story but about Donkey Kong on the C64.
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".
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...
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-...
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
On the other hand, many of the old games are exhaustively documented and built for component-level repair. A trade-off, I suppose.
Thank you. Looks like I overcomplicated things. I won't even use a vintage CPU, maybe a STM32, so that would be even easier. I guess the only complicated thing is if I want to invent "cartridges" so that involves some hardware.
And yeah I agree those earlier discrete logic games are tough to copy. I think those games were made in hardware with little software.
> 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.
I think what he meant is that the earlier arcades were done directly in hardware with very little software, so you have to copy the hardware or use emulation.
Is that different from other software? You have to copy the hardware or use emulation no matter what.
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.
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...
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.”
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.
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.
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
The theme song: https://www.youtube.com/watch?v=qg_wuKLqV8g
such a classic game
how do I play this
with joy in your heart at the memory of better, simpler times.