I could say plenty more about the architecture of the Galaxian code itself, but I've detailed enough to put together a framework for a transcode/port on another platform. Not so much an issue in a controlled environment such as the Galaxian arcade machine hardware a different matter perhaps on a modern, mutli-tasking platform. It may be worth noting here that Galaxian assumes that there will always be sufficient time for the main code to empty the command queue before the next interrupt, as there is no concurrency protection around the queue pointer manipulation in the main code. For example, whenever a player shoots an alien - which is processed by the NMI - the NMI can queue a command to update the player score. In Galaxian there is a command queue, implemented via a circular buffer, that is written by the NMI and read by the main code, which allows the NMI to, well, queue a number of commands to be performed by the main code between interrupts. The main code does all the updating of the tilemap contents (the actual characters you see on the screen). So what is left for the main code to do then? In Galaxian the main code performs functions such as printing text, scores etc on the screen, and also removing aliens from the swarm as they dive, and adding them back to the swarm if they return. runs the game state machine(s) handling title screens, attract mode and game mechanics such as AI, movement, bullets, exploding etc and in the process updating the memory buffer with tile attribute and sprite data for the next screen refresh (NMI).reads and debounces player control inputs.updates the tilemap attributes (colours and scroll registers) and sprites from a memory buffer.

Typically the NMI would also update the physical display, handle in-game timers, control sound and debounce inputs for example.Īs for Galaxian specifically, it does the following: This would include things like player movement, enemy AI, player shots and bullets etc. So in a game like Galaxian, there are two contexts of code execution the 60Hz VBLANK interrupt, which is wired to the Z80's NMI and causes the CPU to execute code at address 0066h, and the main code which starts executing at address 0000h when the CPU is reset and runs (continues) after the aforementioned NMI handler routine is finished until it fires again.Īside from various hardware functions, the NMI handler contains all the processing in the game that affects, and is affected by, the speed that the game is running. Not only does this allow the game to update the sprites without any flicker or tear, it also serves as a reliable, periodic timer on which to base the speed of the game. Before we can create a framework for the transcoded game, we need to understand the architecture of the original.Įvery single arcade game that I have reverse-engineered thus far has been driven by the 60Hz VBLANK interrupt.

Galaxian sprites