Space Invaders

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.

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/

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

    // 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]

The background sound feels like a spacey jingle. I like it. It's mesmerizing lol.

Very nice. I have a sim. story but about Donkey Kong on the C64.

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 "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".

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.

I loved Star Castle.

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.”

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.

with joy in your heart at the memory of better, simpler times.