How did people program for Consoles with multiple CPUs?

Question

I'm specifically interested in the Sega Mega Drive/Genesis, which used a 68000 CPU, but also a Z80, mainly used to control the sound hardware and provide backward compatibility with the Master System.

There was also the Atari Jaguar, with it's Tom and Jerry RISC chips, the Sega Saturn, Featuring a total of eight processors, and probably a lot more.

When writing code (assuming ASM), how would these additional processors be used/accessed? Did one write regular 68000 code (even for sound) and the 68000 itself handled talking to the Z80? Did one need to write two different programs, one for each CPU? If yes, how did they communicate with each other? Or is memory mapping used, which would require a binary that has both 68000 and Z80 instructions in them, making sure that the Z80 code is in a specific memory region?

(This isn't about "regular" multi-processing, like on newer consoles with multi-core CPUs that are all the same. This is about consoles with a main CPU and specialized co-processors for e.g., Sound. Basically, the Sega Genesis, though I'm looking at building my own custom system, so I'm more interested in the basic principles.)

Answer 1

It varies machine to machine; at the simplest end is the Neo Geo — its 68000 and Z80 have completely independent buses. You write one program for the 68000 and one for the Z80 and a single pipe of communication joins the two: post a byte to the Z80 and it'll trigger an NMI; the Z80 can read the command byte from a certain port and write a response to another, the 68000 can poll for the response. Neo Geo also supplied a sample set of Z80 code so you could just treat it as an advanced sound generator and not worry about the implementation if you prefer.

The Mega Drive has a more complicated system of shared buses; the Z80 has some memory on a private bus but the cartridge bus is a shared resource and I think the Z80 can also share some RAM. In that system the VDP can also act as a bus master so in net it's the Z80 getting access to the shared resources only when nobody else is attempting an access, the 68000 having priority only when it doesn't chose to start a VDP transfer, and the VDP having top priority for those periods when the 68000 has command it to do something.

If you ever hear scratchy sampled audio in a Mega Drive game then it's likely to be the Z80 trying to stream from the cartridge but frequently losing out on access slots.

The Saturn is like a more advanced Mega Drive except that the main CPUs have caches that can also be configured as small local memory pools. So if you're careful you can mostly keep them off the shared bus, gaining a significant performance benefit — Virtua Fighter 2 manages to keep most of the data for each player local to a single CPU for most of a frame, the laziest PlayStation ports do nothing in particular and either end up only using a single CPU or effectively doing so as a result of collection.

The Jaguar is supposed to work similarly to the Saturn but, quelle surprise, Atari rushed it to market so there's a significant bug affecting the RISC CPU's accesses to RAM when performing certain types of jump. That's how it often ends up being treated as a machine with a 68000 central processor when really the 68000 was intended just to be an intelligent scheduler.

So: across these systems one generally writes a different program for each processor, and either nominates one as a coordinator or uses a series of ad hoc means of point-to-point communication.

If it sounds hard to get right, that's because it is — programmers much prefer systems like the original PlayStation with a single CPU that just goes quickly.

Answer 2

There are two basic techniques: shared memory and dedicated communication ports.

Shared memory simply allows both processors to access the same memory bus. There are some issues, as the bus has to be shared and one CPU has to get priority so code must be designed to take unpredictable extra delays into account. The Megadrive is a good example of that, with the Z80 CPU losing cycles to the 68000 and the graphics subsystem.

It's actually a quite awkward system but they wanted the Z80 for backwards compatibility with Master System games. The system has a dedicated sound chip and the overhead for playing back music and sound effects is so low that there is little benefit to offloading it from the 68000.

The other issue with shared memory is that if one CPU is writing to it while the other is reading it, the reading CPU can end up with corrupt data. Therefore some kind of arbitration is needed, often based on atomic update operations.

Communication ports allow two CPUs on separate buses to communicate. Each CPU has its own bus, its own RAM, its own peripherals and a single I/O port that lets it communicate with the other CPU(s). The port usually allows commands and small amounts of data to be sent, often one way, from one CPU to another and an acknowledgement to be sent back. The Neo Geo is an example of a system that works that, or more common in the west was BBC Micro with its optional second processor via the "tube".

Software for each CPU was written and debugged separately.