As near as I can tell, there seems to have been roughly speaking two schools of thought when it comes to graphics hardware among early consoles, what I will call the Atari and Texas Instruments schools. The Atari school is exemplified by the Atari 8-bit computer series' ANTIC coprocessor, which contained a minimal instruction set that described, operationally, how to construct the screen. The TI school conversely, is typified by the TMS9918 chip, which contains a series of hardware registers, which describes the placement of objects on a screen, which are set by the CPU. Of course, neither of these examples are the first of their kind, but I would rather consider both to be the ur-example of their ilk.

What I am interested in are examples besides ANTIC of the Atari School of graphics hardware design. Also, I'm aware that displays are somewhat common in 3D hardware, so I'm mostly interested in the pre-3D era. Myer and Sutherland's 1968 paper On the Design of Display Processors lists a few examples of this approach, for instance the DEC-338. The real question is what counts as a "display list" design. The MSX2's V9958 has hardware accelerated line drawing commands. On the other hand, TI's TMS340x0 series chips were just general purpose programmable CPUs with graphics-oriented instructions. In my mind, for a design to count, it must be able to execute a series of instructions or commands, on it's own, without CPU-intervention, while having a sub-Turing complete (or at least, very limited) instruction set. (Yes, I know that all these systems have finite memory and thus aren't equivalent to a UTM strictly speaking anyway). So perhaps there are no conditionals, or no jumps, or something like that.

Examples I am aware of:

  1. Aforementioned ANTIC
  2. Aforementioned DEC-338
  3. The Amiga's COPPER probably narrowly counts (unsurprising given the same team was behind it as the Atari)

I am not really convinced that the 7800 or Amstrad roller ram really count as display lists, since neither are really instruction sets. On the other hand, the TMS340x0 is simply too powerful and general purpose to be an example of what I mean.

  • Not sure what the restriction of an instruction set should be good for. What is the benefit of a graphics subsystem having a limited instruction set? Doesn't that just create an artificial subset, not really defined by purpose?
    – Raffzahn
    Commented Dec 12, 2019 at 23:25
  • Whether it's good or bad is somewhat beside the point, I'm just interested in what designs existed which have these properties. But presumably a simpler design would be cheaper to make, which I guess would be the rationale as opposed to just two general purpose CPUs.
    – junius
    Commented Dec 12, 2019 at 23:27
  • Maybe the wording wasn't as clear. So far it's hard to see where you want to draw the line and how do decide what's in or out. After all, Antics display list is pretty unique as it works directly on a screen line structure, while DEC's 338 is more of a general purpose CPU - albeit a simple one. Cost wise, having a secondary CPU is usually less expensive than specific designs - to example as used with the Superbrain with its double Z80 - or some graphics subsystems for the Apple II.
    – Raffzahn
    Commented Dec 12, 2019 at 23:36
  • Similar, where to draw the line between when it's put in a second box. After all, the DEC 338 is a separate terminal system - so would an X-Terminal qualify as well? On the other end, whats with Thomson's EF9365 series?
    – Raffzahn
    Commented Dec 12, 2019 at 23:44

4 Answers 4


The Imlac PDS-1 is exactly what you're looking for: A general purpose computer with two instruction sets - one instruction set was a "stretched" PDP-8 (16 bits instead of 12 bits, 2 registers instead of 1) and the other complete instruction set - with subroutine calls! - was for executing display lists on the built-in vector graphics console. The instructions were relative moves with beam on and off - which had multiple instruction formats for short and long moves - and the subroutine call. The CPU would switch between the instruction sets under program control - basically, you needed to switch to display list mode often enough that the lines glowing on the phosphor didn't fade away ... if you put too much stuff in your display list you'd get a really nasty (and headache causing) flicker.

I programmed this computer in the Harvey Mudd College computer "lab" between 1973 and 1977. Graphical programs I wrote included a terminal emulator, an "IDE" for creating/displaying/printing Mayan hieroglyphs, an implementation of the SIGGRAPH 2D and 3D "Core Graphics" API (though at that time I don't think the term "API" had been invented), and a solar system simulation (an "orrery"). All in assembly language, whoohoo!

(In 1976-77, working part time while still at HMC, I programmed, for the Imlac, an instructor's control console for a sonar system trainer developed at Honeywell's Marine System Division (West Covina, CA) - it was shipped to the Navy with a couple of copies of the multi-computer trainer. Got me my first programming job as an FTE, there at Honeywell!)

  • Great answer. Using this technique with a vector display system makes a lot of intuitive sense.
    – Brian H
    Commented Dec 18, 2019 at 17:07
  • Do you think any of that Imlac software could have survived? Commented Feb 25, 2020 at 7:12
  • @LarsBrinkhoff - gosh, I don't know. In those days we - or at least I - didn't have the sense that someday there'd be geeks geeking out over "retrocomputing" - and that we were going to be the "retro"... If only I'd saved all the gear I had over the years! (Of course, if I had, my wife would have divorced me long ago, she can only abide so much useless junk around the place ...)
    – davidbak
    Commented Feb 25, 2020 at 15:19

The Super Nintendo Entertainment System (called Super Famicom in Asia) is mostly TMS9918-like. However, the CPU's integrated memory controller has its own counterpart to Amiga COPPER, called HDMA (horizontal blanking direct memory access). HDMA can reprogram PPU registers during hblank based on up to eight lists stored in work RAM.

Each HDMA channel has these parameters:

  • B Bus destination address ($00 to $3F select various PPU registers, and $40 to $43 select the sound CPU's communication ports)
  • A Bus address of the list (usually within the console's work RAM at $7E0000 to $7FFFFF)
  • Write pattern (different PPU registers need single writes, double writes, or writes to consecutive addresses)

Each entry in an HDMA list consists of one byte for the height (number of lines to wait afterward) followed by one to four bytes to write depending on the write pattern configured for the channel.

Games use HDMA for several purposes:

  • Lots of platformers use HDMA to the color palette port or the auxiliary color (COLDATA) for sky gradients.
  • HDMA to scroll registers warps the screen for hot rooms, underwater, or at the water's surface in Donkey Kong Country series. It helps render abstract backgrounds in RPG battle scenes in EarthBound. It does limited parallax warping of the floor in NBA Jam and Street Fighter II.
  • When combined with vertical scrolling per column (offset-per-tile in modes 2, 4, and 6), HDMA to the horizontal scroll register allows rotating a background by up to 1/8 radian (7 degrees) without having to use mode 7. Star Fox uses this for its sky box in order to draw the Super FX-rendered playfield as another background in front.
  • Mode 7 by default offers only affine transformation (scrolling, scaling, rotation, and shearing) of the entire screen. HDMA to mode 7's affine matrix registers allows rewriting the matrix on each scanline, leading to the over-the-shoulder perspective popularized by F-Zero and Super Mario Kart.
  • Because of restrictions on mode 7's memory layout, games using mode 7 for the playfield (such as Cameltry/On the Ball) often use mode 1 for the sky box and status bar. If one of the HDMA channels is free, it can be set to change the mode instead of changing it with the CPU in an HV interrupt handler.
  • The window registers allow showing or hiding background layers or color blending effects between two pairs of left and right coordinates. To give this shadow a shape, games use HDMA to change the windows' coordinates per line. For example, HDMA outlines the keyhole in Super Mario World, the other vehicles' shadows in a few mode 7 racing games, the player's current place (e.g. "2" for second place) in Super Mario Kart, and the de-materialized form of Sting Chameleon in Mega Man X.
  • A handful of homebrew games, such as N-Warp Daisakusen, use HDMA to the sound CPU's communication ports to stream vocal samples without needing constant involvement from the main CPU.

The Nintendo 64 uses a completely different architecture. It has a main CPU, a Reality Signal Processor (DSP for vertex shading), and a Reality Drawing Processor (fixed-function triangle drawing unit with depth buffering). Do the lists sent from the main CPU to the RSP or from the RSP to the RDP count as display lists?


I don't think the list is very long. The history starts with the Atari 2600, which was firmly derived from older discrete logic but added a microprocessor primarily for raster racing: doing so is the only means to draw a 2d frame — it's not a clever way to get more from the system, it's the intended use of the system. That was consolidated as a dedicated coprocessor in the ANTIC, and extended by the Copper, but the members of the same design team who carried on working — primarily Mical and Needle — switched in both the Lynx and the 3DO to a plain frame buffer and doubling down on the blitter hardware.

If you won't count the PCW's roller RAM then the Enterprise 128's line parameter table is probably out — on that machine you provide a list defining individual blocks of video memory, each up to 256 lines in size, by their video mode, start address and partial palette.

As implied by Raffzahn, there are various terminals that might qualify, as there are two schools of thought on storing attributes, one in which they're 1:1 with characters and one in which they're modal — they take effect when the raster rolls over them and remain in effect until some other attribute is applied. So you've got something a bit like a Copper for seeing things like brightness, colour, inverse video, etc. No looping or branches, but raster-triggered modal changes.

You can see a similar idea in the teletext-type systems, except that the modal attributes are in the character stream. Each position can either contain a character or contain a modal change. On systems like the Oric the same approach is used for pixel modes, not only character modes.

  • 1
    Closed-captioning decoders in the USA apply the same modal-attribute concept.
    – supercat
    Commented Dec 13, 2019 at 17:21

The variant, which is vaguely similar to the display list, was used in a small-series Soviet personal computer of the PDP-11 line - Soyuz-Neon PK-11/16. Up to 576 32-bit line pointers - continuous areas in an arbitrary place of RAM with a length of 16 to 256 bytes, encoding a sequence of pixels in one of 16 possible interpretations.

  • 32-bit pointers? On a PDP-11? Commented Dec 13, 2019 at 13:01
  • Actually that computer is NOT a PDP-11 line -- it is more like home computer of 80ies. However, it used single-chip PDP-11 compatible processor. It had more that 64kbytes of memory -- hence the pointers for the hardware are greater than 16 bits.
    – lvd
    Commented Dec 13, 2019 at 14:53
  • Yes. On the one hand, the H1801BM2 processor was used in the computer, which supported the maximum 4 megabytes possible for the PDP-11 family memory manager. On the other hand, a video controller based on a matrix crystal from the k580 family used exactly 32-bit pointers. Commented Dec 13, 2019 at 14:54

You must log in to answer this question.

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