14

Reading about the Fujitsu Micro 7, I found out that it used a pair of 6809 microprocessors: one as main CPU and one as graphics processor.

That made me remember that when running old arcade games with MAME, I often saw configurations with several Z80A microprocessors, presumably using one of them for graphics. I didn't think much of the fact at that time, but I now find myself fascinated by the concept of having a general purpose CPU used as a video processor, in contrast with chips like the VIC-II or the TMS9918, or even the 6845.

I'd like to add such an architecture to one of my retro designs. Do you guys know about some resources (schematics, theory of operation books, ROM disassembly, etc) where I could find details about some actual implementations of the 80s?

4
  • 3
    Would you count the BBC Micro in tube processor mode? That's well-documented. If you attach a 68000, an 80286, ARM, etc, or even just a second 6502, to the BBC Micro via the tube interface then appropriate software runs entirely on the second processor with the original machine being [more or less] demoted to just doing the drawing and audio generation, and passing input in the other direction. So a large part of the original 6502's responsibilities become graphics processing. But this may be a stretch, being a reuse of the regular MOS HAL routines?
    – Tommy
    Jul 26, 2022 at 19:42
  • 4
    Does this answer your question? How did Z80 multiprocessing work in the Namco Galaga hardware?
    – Brian H
    Jul 26, 2022 at 20:51
  • 1
    You could also have a closer look at the MAME source code. Jul 26, 2022 at 21:34
  • 1
    You might be interested in the УКНЦ or UKNC, which has two PDP11 compatible processors. Graphics and other I/O processing is delegated to one of the processors. Oct 30, 2023 at 16:49

2 Answers 2

11

Well, since the question itself is way too broad for any useful answer not being a list answer, let's add some FM7 background

The FM7's Sub-CPU, the one doing the graphics, had its own a Sub-Sub-CPU, a 4 bit controller doing the keyboard :))

Having multiple CPU's each operating a dedicated part was quite common for professional systems, not just the IBM-PC having an 8 bit keyboard controller, or the Superbrain having a second Z80 CPU to handle it's FD system. And a professional system is where the FM7 inherited it: The FM8 introduced in 1981 - soon to be replaces by the FM7 as "low end" and the FM11 as business system. Well, not so "low end" with a price of ~600 GBP at a time when the 48 KiB Spectrum, a true home computer, sold at less than a third of that (175 GBP).

Being a business system and as such poised to handle the high variety of Japanese character displays, the FM8 got a dedicated graphics system with it's own 6809. Not so much for speed concern, although it helped, but to simplify software design and, most important, leaving enough usable RAM for applications - after all, the display had to be plain bitmap, thus already a B&W one would need 16 KiB, having 8 colours tripled that. So no chance to have that within the main address space.

As feature reduced version of the FM8 the FM7 inherited that feature, still being an upper end machine with 64 + 48 KiB RAM.

Comparing the Sub-CPU to a GPU replacing, including replacement of classic video controllers like VIC or 6845 does not really match up. Yes, the 6809 does a lot of bit fiddling, but there is still dedicated hardware outputting RAM bitmap to video. So it's more like taking a CGA (or VGA) and add a CPU. The picture is displayed anyway, without any help of that CPU, but with it, much more tasks can be offloaded.

Since the FM series Sub-CPU also had its Sub-Sub-CPU for the keyboard, the whole system is more like a close coupled terminal. An idea used by several other machines as well. Just think of various Z80 cards for the Apple II, where the host machine is 'reduced' to being a terminal, handling not just video, but all I/O including disks (*1) or sound as well(*2).

In fact, there is another quite popular UK machine which made that even a systematic feature: The BBC Micro. With a second CPU added, the BBC becomes a sub-system to whatever second CPU is plugged in - including another 6502. So quite like the FM machines.

Lesser known, but quite admired back then was the 1978 MicroAngelo card by SCION, a S100 bus high resolution graphics card with local memory and its own Z80 CPU to execute graphics primitives. Its manual may be a good read to gather ideas about instruction building.


So, how does it work?

Since both are complete systems, all it needs is a communication linke. That can be a serial line, like with a classic terminal, a pair of 8 bit wide ports (think two 6522 in handshake mode), some FIFO (speeding communication quite up), or some dual ported RAM. The later being what is used in the FM7.

There is a 128 byte RAM located at $FC80 used to send commands to the Sub-CPU. Whenever the CPU wants to do so, it

  • checks a port bit to see if the Sub-CPU is still executing, or idle
  • when idle the Main-CPU halts the Sub-CPU
  • writes a command byte and optional parameters to the dual port RAM
  • releases the Sub-CPU which in turn
  • sets the busy flag
  • takes the command byte and executes whatever is requested.
  • optional returning data
  • finally setting the busy flag and
  • return to idle operation.

Call this 'Theory of Operation', but there is no secret trick or incredible complex operation, only two independent computer systems talking via a communication link.

I guess at minimum that would be three commands like

  • Initialize System; maybe accompanied with basic settings for foreground/background/border colour and alike
  • Clear Screen
  • Output a Character

From there on, add whatever might be useful, like

  • Output a String; speeding up communication
  • Position Cursor
  • Set Character set
  • Load Character Definition
  • Set Character Orientation; like for writing at arbitrary angles
  • Set a Graphics Cursor
  • Draw
    • a Line
    • a Rectangle filled/unfilled
    • a Circle
    • a Series of Lines
    • a Circle Section
    • ... whatever

Heck,

  • add BitBlit with off screen sources for sprites etc.
  • add memory read/write to manage such resources
  • or even upload custom code.

I guess you get the picture by now. No dark secret magic, just outsourcing the very functions your programs need.


P.S.: Unlike the FM I'd rather not build my own video output hardware but use a ready available 9958, to spare the additional development, even if just used in a fixed bitmap mode.

P.P.S.: Oh, and if you're add it, think about a third CPU (well, fourth considering keyboard&mouse :)) dedicated to sound. Since sound needs to run continuous and uninterrupted it will benefit even more from having it's own CPU. If drawing lags at times it'll be a minor nuisance, if sound lags, it'll be a major one.

Communication might be done much like with video. Also, using an existing synthesizer chip (FM preferred) will simplify design and give the CPU more room to handle complex higher level stuff, like preparing instrument tables, translating MIDI, mixing sounds or even creating 3D positioning. The Sky is the limit :))


*1 - Another example is the 1979 Superbrain employing a secondary Z80 to handle the Floppy drives. Of course going tha way also leads to all those machines that had 'intelligent' peripherals, from HP and Commodore all the way to Apple.

*2 - The main differences in case of the Apple II is that both CPU share the same memory and only one can work at any given time.

2
  • 2
    Nice touch noticing that moving video to another processor, frees memory on this processor which for 8-bit machines is quite precious. I never thought of that, but it is a very good reason Jul 26, 2022 at 21:37
  • @ThorbjørnRavnAndersen Actually, it's not that big an issue since the memory could be bank switched anyway. Bank switching would reduce efficiency slightly, but the speed gains from avoiding that were tiny compared to the speed gains from having a second CPU do the heavy lifting for multi-pixel graphics operations.
    – cjs
    Jul 27, 2022 at 4:59
7

The FM-7 implementation was quite simple. The "sub-CPU" had its own address space with the bit-mapped frame buffer, local working RAM, character ROM, program ROM and 128 bytes of RAM shared with the main CPU. (The sub-CPU was also responsible for dealing with keyboard input and perhaps a few other things unrelated to the video display; most other I/O was handled by the main CPU directly accessing the peripheral chips.)

Programs running on the main CPU would put requests in the shared RAM which the program running on the sub-CPU would then read and execute, returning results (if any) in the same way. The sub-CPU would update the frame buffer, organised as three 16K bit-mapped monochrome planes, one each for the red, green and blue (or, for monochrome, intensity) components of the signal generating the 640×200 display. The usual simple shift-register arrangement produced a three-bit wide video signal displaying this frame buffer; this was three-channel digital RGB on the colour output and a greyscale CVBS signal with eight levels of intensity (brightness) on the monochrome video output.

More details on the hardware, including ROM dumps and schematics, are available in the GitLab repo retroabandon/fm7re. The software interface is described in the 富士通 FM-7 ユーザーズマニュアル システム仕様 (Fujitsu FM-7 User Manual: System Specification) in section 2.2 (Firmware, "Display Sub System"). I'm unfortunately not aware of any English-language resources for this, but the symbol names for the routines are in English and Google Translate can help with the descriptions. A dump of the sub-CPU ROM is available in the repo above, but I've not gotten around to starting a disassembly of it yet.

Essentially, this works exactly as a computer with only one CPU and a similar "dumb" frame buffer (such as the Apple II) works except that the processing load is distributed amongst two CPUs running in parallel. This naturally falls into a "client-server" arrangement where the main CPU sends requests of some sort to the graphics CPU. These requests must be simple enough for the main CPU to generate that it takes little time to do so yet encode enough work that it's worth having a separate CPU do the processing in parallel. Typical requests might be to draw a line, do a flood-fill, display a character or bitmap at some arbitrary position, orientation and scaling (similar to a sprite), or scroll the screen in one direction or another. CPU-based graphics subsystems may or may not offer the ability to download custom code to that system for operations not supported by the standard code. (I believe the FM-7 did not allow for this.)

The biggest difference you'll see from a dedicated video chip is that there are some graphicsthat can be done more quickly and easily as a bunch of logic gates than as a software program on a given CPU. One example is certain kinds of shifts; this is the reason that Space Invaders, though it did most graphics processing using its 8080A CPU, included dedicated shift hardware to which the CPU would hand off some of the shifting operations. (There are also things that can be done better by a CPU—typically certain more complex operations—but these can often simply be done by the main CPU, regardless of the graphics subsystem.)

7
  • Did the aliens in space invaders not descend a multiple of eight pixels at a time? All of the smooth object motion in Space Invaders is between matching positions on different scan lines, which I wouldn't think would require any shifting.
    – supercat
    Jul 27, 2022 at 14:58
  • @supercat There are a lot of objects in Space Invaders that move left and right pixel by pixel....
    – cjs
    Jul 27, 2022 at 15:05
  • 1
    If I recall there are two kinds of 3-scan-line-wide objects that are about 9 pixels long, and player shots are smaller; I can't imagine any hardware that would help with drawing those more than would a 112-byte table of preshifted shapes. If aliens can move downward by non-multiple-of-eight values and their shapes aren't kept in shifted and non-shifted forms, drawing those might benefit from hardware, but for smaller bombs and shots I don't see such benefit unless I'm missing something.
    – supercat
    Jul 27, 2022 at 15:17
  • @supercat Well, it's certainly something you could post as a question here on RCSE.
    – cjs
    Jul 27, 2022 at 15:24
  • 1
    You need shifted sprites for the bullets and explosions. Basically on screen you need four sprites or maybe eight if you want to do bullets as indvidual sprites. I think for the arcade space invaders hardware you actually could get away without the shift register and using some ROM space. I think I can pack the whole game into 16K ROM / 2K RAM on a STM8 part. My only cheat is the saucer is always on an even pixel boundary, and I think I'm okay on ROM space but I haven't finished all the code yet on the STM8 as my current dev part is 32K ROM.
    – PeterI
    Jul 27, 2022 at 22:27

You must log in to answer this question.

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