26

Galaga was a popular arcade game developed and released by Namco (Midway in N. America) in 1981. It had amazing, fast, smooth 2D-sprite graphics, and relied on Namco hardware that utilized 3 Z80 CPUs running at ~3 MHz.

I am aware from the limited information found online that the 3 Z80s were divided up as one main CPU, and a co-processor each for sound and graphics. I'm mostly interested in how the Z80 for graphics processing was utilized to manage the drawing of all the sprites. Although, I would assume a similar means of sharing data existed for the sound co-processor too.

I think it is noteworthy that none of the 8-bit single CPU home or console systems of the 1980s faithfully reproduced this game. There was a weak port for the Atari 7800 and a decent, serviceable port for the NES, which still falls well short of the arcade game graphics. So I am guessing that the sprite hardware available for the top 8-bit home systems was no match for Namco's custom graphics hardware.

How did the Namco hardware create such an effective graphics rendering engine from slow, cheap, multiprocessing Z80 CPUs?

Improve this question
8
  • 2
    Based on github.com/mamedev/mame/blob/master/src/mame/drivers/galaga.cpp and other sources, it sounds like they had sprite hardware in there as well? Underneath the section that begins with the Galaga heading at line 186, I see sprite registers listed in the 'COMMON' part of the memory map on lines 247, 249 and 251. Also computerarcheology.com/Arcade/Galaga mentions that "[a] hardware device mapped into the top of the RAM area controls the display of 64 sprites."
    – Tommy
    Sep 14, 2017 at 17:37
  • 1
    An interesting question, thanks. There's a schematic here which sheds a little light but unfortunately not enough to answer the question: the three Z80As (clocked @ 18.432MHz / 4 = ~4.6MHz, so overclocked) have a local bank of EPROMs (mapped 0 - 16K in their address space) and shared access to the rest of the system, so each could at least theoretically do anything. The one in position 4M is clearly the main processor (it has a full 16K of EPROM while the others only have 4K each), and will have priority over the others when accessing the shared bus.
    – Jules
    Sep 14, 2017 at 23:59
  • 1
    On the video board, there are a lot of different buses that can all be driven independently. Interesting sections include the buses labeled "data bus C" and "data bus D" -- these do in fact contain both data (4 bits wide) and address (9 and 10 bits respectively). The addresses are generated by counters that are loaded from CPU-connected buses, and connect to SRAMs that can be paged in or out on demand which are either written to by the CPU or read through multiplexers directly into a chip that appears to be a colour palette lookup into the output. I believe these are sprite generators.
    – Jules
    Sep 15, 2017 at 1:11
  • 1
    @jules according to wikipedia, the CPUs ran at 3,072 Mhz
    – Tommylee2k
    Feb 16, 2018 at 11:14
  • @Tommylee2k - interesting; the claim at wikipedia seems to be sourced to a (slightly less readable copy of) the same schematic I based mine on. 3.072MHz would be correct for a divide-by-6 from the clock source, but looking at the schematic again I misread how the off-page connections work; a 6.144MHz clock goes into a custom IC ("07XX") and one of its outputs is the CPU clock signal, presumably halved from the input. Interestingly, there's still overclocking going on even at that speed: the main processor is a Z80A; but the others are labelled as plain Z80s and are running on the same clock.
    – Jules
    Feb 16, 2018 at 13:19

2 Answers 2

Reset to default
17

Galaga has specialized graphics hardware that draws 64 individual sprites, so to update a screen full of objects you only need to update 256 bytes at the most. The star field is generated completely in hardware with a LFSR (linear feedback shift register), and there is a 8x8 tile map to draw the score and any other text. I'd guess the Galaga CPUs are spinning their wheels most of the time.

Its predecessor, Galaxian, was even more limited. It only had one CPU, and only 8 hardware sprites (plus 8 bullet/missile/bomb sprites) but managed to draw 46 enemies on screen.

It did this by using the tile map. Each 8-pixel high column of tiles (which was a horizontal row, since the screen was rotated 90 degrees) could be individually scrolled by writing to its corresponding scroll register.

So when enemies were in formation, they were drawn/animated with the tile map and moved from side-to-side using the hardware scrolling registers. When they started their attack on the player, they were converted to sprites, then back again if they returned to the formation. The player's ship was also animated this way.

Improve this answer
5
  • Interesting. Did Galaxian reuse objects reused mid-frame, or did clusters of shots or descending flagship-plus-escorts groups share sprites, or what? If the player and shot are two sprites, that would leave only six for enemies and their shots.
    – supercat
    Feb 15, 2018 at 19:49
  • 1
    @supercat - if my reading of the Galaga schematic is correct, its sprite generators are triggered from timers that would need to be reset by the CPU on every video line, so reusing them in multiple lines of the same frame wouldn't be a problem at all. I'd presume that it had inherited that aspect of the design from Galaxian.
    – Jules
    Feb 16, 2018 at 13:32
  • 4
    Looking at the specs of the machine as described here, I wonder why the NES port was considered subpar (I haven't actually seen it, so can't really comment). The NES is a slightly lower resolution display (256x224 vs 224x288), but otherwise has similar hardware specs (64 sprites, 16 colours, a single ~1.7MHz 6502 which per recent discussions ought to easily exceed performance of a single ~3.1MHz Z80, and it seems only the main CPU did much work in Galaga).
    – Jules
    Feb 16, 2018 at 15:05
  • 2
    @Jules: I've not played the NES port, but it's possible for a port on superior hardware to be downright terrible because the game mechanics are implemented badly. As for technical specs, the NES has a limit of four sprites per horizontal line; a player shot plus a monster shot plus two formation monsters plus an outside monster could hit that limit.
    – supercat
    Feb 16, 2018 at 15:37
  • 2
    Galaxian only used the 8 sprite slots for enemies that are attacking the player. As described above, the tile map draws the stationary enemies (when they're in formation) and also the player's ship. There are 8 separate slots for missiles, but they're hard-coded to a 1-pixel wide shape. So you have up to 16 moving objects on-screen overlapping the tile map (even though there are limitations like only 2 missiles can a scanline)
    – 8bitworkshop
    Feb 16, 2018 at 18:37
16

The three CPUs were designated as follows:

CPU 1 - Main game logic and control of the other two
CPU 2 - Graphics and enemy movement
CPU 3 - Sound

The three CPUs communicate via shared RAM. CPU 2 and 3 perform start-up checks (such as a ROM checksum) and then go into infinite loops, with all activity happening inside interrupts triggered by CPU 1.

CPU 2 is responsible for moving enemies, moving the player's shots and ship, moving the background and doing collision detection. It's code has been disassembled and you can see that it has a few simple commands that are triggered by interrupt. CPU 3 is basically the same.

Note that CPU 2 can refuse commands in cases where they are impossible to execute, e.g. when it has run out of free sprite slots. The enemies are drawn as part of the background tiles when not in flight, to save sprite slots.

Improve this answer
4
  • That feels very over-engineered for the game presented, so follow-on query: was that a standard Namco arrangement, or very closely related to their other machines at the time? I know that in cabinets, spending an extra $50-or-whatever on components and getting to market sooner is probably a win, but it feels counterintuitive to me that even optimisation of engineering time would arrive at that arrangement just for that game. But maybe I'm underestimating it; it's one of those I'm aware of but have never played that much.
    – Tommy
    Feb 16, 2018 at 19:07
  • 1
    They wanted a lot of moving objects on screen, with complex patterns. The Z80 parts available to them at the time couldn't reach high speeds and only executed a few hundred thousand instructions per second. Also, standard Z80s are much cheaper than custom graphics/sound chips.
    – user
    Feb 16, 2018 at 21:39
  • Did the sound board bash values out to a DAC like Eugene Jarvis' sound board (Williams), but with a Z80 instead of a 6800? I remember thinking at the time that the music seemed pretty sophisticated, but I've since done four-voice music on the Atari 2600 while showing a pretty game-select screen.
    – supercat
    Feb 16, 2018 at 23:56
  • 1
    It's got a custom waveform playback chip with 3 voices. The sound Z80 programs it and the chip itself fetches sound samples from PROM for playback.
    – user
    Feb 17, 2018 at 8:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .