Graphics chips in 1980

Question

Suppose you were trying to build a computer with a color graphics display in 1980, you have limited engineering resources and time to market is critical, so you want to get as many of the parts off the shelf as possible. Was there an off-the-shelf video chip available at that time that could be used? Requirements:

• A bitmapped display, resolution as high as possible.

• Some form of color.

• It's for a workstation not a games machine, so there is no requirement for sprites or hardware scrolling.

If it makes a difference, the CPU is the 68000.

Answer 1

There were. A couple of examples are the Motorola MC6845 and the MC6847. These chips were flexible and allowed various resolutions and colors depending on how they were implemented.

The MC6845 was used in the Acorn BBC Micro, the Amstrad CPC and the IBM PC MDA and CGA video adapters.

The MC6847 was used in the Tandy TRS-80 [Model 1], the Acorn Atom, the Tandy Color Computer, the Dragon 32, and the V-Tech Laser 200.

Some companies made their own custom video chips and didn't allow anyone else use them. Examples would be Atari (TIA, ANTIC/GTIA, MARIA, Shifter), Commodore (VIC, VIC-II, TED, Agnus/Denise), Apple (with the IIgs), and Tandy (with the GIME in the CoCo3).

Other companies made video chips with fixed abilities, usually more powerful than the Motorola chips but with fixed resolutions, colors, and sprites, and sold them for other companies to use in their own systems.

Examples are General Instruments' AY-3-8900-1 (used in the Mattel Intellivision), Texas Instruments' TMS9918 (used in the MSX, TI-99/4(A), Coleco ADAM, and ColecoVision), and Yamaha's V9938 (used in various MSX2 systems), V9958 (used in various MSX2+ systems), and the V9990 (not sure where it was used).

Answer 2

I designed a color graphics card for the Z80 ECB bus back in 1984 or so, based on the 6845.

The 6845 was "just" a timing and addressing generator. It was meant for character-based displays. So it divided the display area in character cells. Each character cell could span some horizontal pixels (to be serialized outside of the 6845) and some vertical scan lines. So it had:

• the horizontal character number
• the vertical text line number
• the vertical pixel-in-character number.

This chip could easily be used for graphics as well as the necessary RAMs became available:

• A character was e.g. defined to be 8 pixels wide and 8 pixels high.
• The horizontal character number became the higher bits of the x pixel coordinate (the lower 3 bits generated by additional hardware clocked at 8 times the 6845 speed)
• The vertical pixel-in-character number made the lower 3 bits of the y pixel coordinate.
• The line number gave the higher bits of y.

My card was a 768*512 8-color RGB, memory-mapped occupying 384 KByte of address space (only the lower three bits of the byte used), with hardware zoom by 2 or 4 (reprogramming the 6845 and using a slower clock speed), resulting in 384*256 resp. 192*128, making it easier to see details on a "big" 14-inch CRT screen.

Answer 3

The Motorola MC6847, used in the TRS-80 Color Computer, or the Texas Instruments TMS9918 would be good candidates. Both were available in 1980, and could display 256x192 pixel colour images.

Answer 4

In 1980? Ouch. That timeframe is pretty limiting for a 'workstation' using commodity chips stuff. If you eschew the custom chip route, and you didn't do something like license someone else's design (in 1980? E&S if you have the $$$. PERQ, maybe? Apollo?), I think about all you have are:

• MC6845 (and numerous derivatives and second sources): CGA resolution, limited color graphics
• TMS9918: CGA-ish resolution, limited color graphics
• Dumb frame buffer: a la the Mac...some (v)ram and a video shift register (maybe something fun like the Fujitsu MB14241). Not that many chips, but without some pretty sophisticated tricks somewhere you won't get many color planes before you crushed a 68000 (1 almost did in the original Mac), so this is more in the realm of idle speculation.
• Smart frame buffer: As above, but use another processor to handle most of the drawing tasks (bitblt, mouse, etc.). Trade hardware for software. Could be another 68000, or one of the 8-bitters (the 6809 was introduced in 1978). More chips, but much less risk than rolling your own silicon.

N.B. - the MC6847 was around before 1980, but as I recall it was intended to drive a TV and have very limited resolution, so isn't really a workstation graphics chip.

Now, if you could wait just another two years or so, the whole world changes. In particular:

• 1982: NEC uPD7220, Up to 1k x 1k, 4-planes, fast and cascadeable for more colors. Second sourced by Intel and evolved into uPD72120 and uPD72220.
• 1982: Thomson EF936x, described above, chips in the series from 512 x 256 to 512 x 1024 with lots of extras. Nice chips.
• 1982: Various V-series derivatives of the TMS9918.
• 1982: faster 68000s & 68010 for better frame buffers (and better performance in general).
• 1983: the TI32010 DSP came out, which people did some very interesting graphics stuff with, but I don't think this really meets the OP's requirements :-)
• 1984: the HD63484 chipset, awesome 4k x 4k and up to 16-bit color
• 1984: the mc68020, frame buffers, again

Then in 1985 some folks started a company called ATI and things in the graphics world started to really change.

Answer 5

Well, beside building it from scratch with TTL components I guess that is. Right?

As already described you could go ahead and 'extend' some existing chips. But if you want an integrated graphics solution more like today's systems, the Thomson EF9365/66 would be the most appropriate selection.

Caveat: I'm not sure if they where already available in 1980, as the earliest data book I own, including them is from 1981.

Also, while in capabilities beyond what contemporary homecomputers did, they're still roughly within the limits of TV alike screens. But that border was quite lower back en and they have have been used like in a professional CAD setup with the EF936x driving a high-res graphics screen while commands and parameters where edited on a separate text screen. Windowing early 1980s style :))

Features included

• Resolution 64x64, 128x128, 256x256 and 512x512 (last one only interlaced)
• additionally 512x256 non interlaced on the EF9366
• logical operation on a 4096x4096 space
• DRAM controller for 16 and 64 k chips
• lightpen support
• (interrupt) signals for Lightpen, VBLANK and READY
• (almost) unlimited number of bitplanes
• 1,2,4 or 8 Bit per plane per pixel
• on-chip character generator
• scalable and rotatable character set (1..16 times width and height separate)
• vector (line) drawing capabilities with 4 line types

Especially the last five points set it apart from any other controller at that time (I know). All syncing signals, timing and pixel clock is provided by the controller, bitplane selection, shift register(s) and colour generation (from the clocked data) is to be added. This makes the EF936x series extreme flexible. A 512x512 display in 24 Bit colour wouldn't be a big deal. Since the plane addressing was quite flexible, the signal generation could add many tricks like a layer for transparency (TV overlay) or other special function modes.

I always wanted to build a graphics system using that chip, as examples where like out of the world for back then. The chips are still somewhere, but I never went through.

Answer 6

Bitmap displays are easy. Basically, all they require is some address counters and multiplexing logic. The only difficult part is getting adequate memory bandwidth to achieve adequate performance, and that's a fairly straightforward cost vs. performance trade-off. Things like sprites are used to increase what can be done with a given amount of memory bandwidth, but otherwise there's really nothing about straight bitmap that would require custom circuitry.

Answer 7

A lot of the coin operated video games of 1980's and early 1990's used 6845 or 6545 CRTC, plus a lot of game video were design around TTL chips with built in hardware character sprites for the slow CPU's. You can search for schematic of the game boards on the inter-web to get some ideas on how they are implemented. My favorite is QIX by Taito it uses 6545 with 2x 6809 CPU's.

Answer 8

It likely was not the graphics chips (or for that matter complexity of a solution built from non application specific chips) that limited practical high resolutions at a price point - you still need a framebuffer memory for a raster display, and even to realize, for example, a 1024x1024 resolution without any color or grayscale capability you would need 1 megabit (128 Kilobyte) of RAM - which was more than what some computers had as system memory, and expensive. Offering a high number of colors made this even worse, and adds the problem of needing to ímplement a good DAC (precision isn't as much the issue here as speed! BTW, dirty secret of most VGA cards: "true color" is not 32/24-bit but 18 bit in hardware. Look up some RAMDAC datasheets...).

Mid 70s to early 80s high resolution graphics systems tended to use vector-oriented graphics generators, that either constantly redrew the vectors from a program (like the IBM 2250) or used inherently persistent displays (like the Tektronix 4016, which is listed with a 1979 price of almost $20k)...

Answer 9

If you really wanted to save money, you could use the CPU to generate the display. Many older machines did that, notably the Sinclair ZX80.

Essentially all you need is a memory mapped buffer chip and an R2R DAC made of passive resistors, and then some output buffer op-amps. Possibly some kind of encoder if you wanted to output composite video or similar. You could even forego the DAC if you could live with basic digital colour.

Such a system would have a low resolution, limited by the CPU clock rate. To increase it you could use dual port RAM, with the CPU enabling the video side outputs and simply stepping through addresses as fast as possible. The outputs would create digital colour or feed an R2R DAC as above.

An improved version of this could use an address generating counter to step the RAM through addresses for each scanline. The CPU then only needs to set up the starting scanline address and trigger the counter to begin (and perhaps end). Using dedicated RAM would obviate the need for dual port RAM in that configuration. Adjusting the frequency of the counter also allows for different resolutions.

Answer 10

Slightly bananas answer: MC68000.

Okay, I know, it's not a graphics chip. But, you can take some inspiration from the Xerox Alto, which would presumably have been a somewhat familiar source of inspiration to somebody working in graphical workstations in 1980. Since the Alto didn't have access to a modern off the shelf RAMDAC for displaying the contents of the framebuffer memory, it used the CPU to read the framebuffer in software. During intensive operations like compiling code, the screen would goo black for a moment while it wasn't doing framebuffer readout.

So, given the fabulous cost of enough RAM to have a high res color framebuffer and enough additional RAM for running programs efficiently enough to justify that framebuffer, a second 68000 CPU would probably not have been a huge cost. Too much for a cheap home computer. But not insane for a workstation. Since you already have experience writing 68000 assembly for writing the OS of this thing, and you've sourced the chips, etc. It would probably be the fastest way to get to market using what you already know and have access to. Even if a 68000 is crazy overkill for something basically just used as a RAM DAC.

You should have something like 7 MB/sec of memory bandwidth to work with. So, make a dedicated RAM pool that the application CPU is only allowed to write to while the graphics CPU is idle. (And probably a separate non-graphics memory area that the graphics CPU can't write too, but the application CPU can use at full speed.) You should be able to support something like the 512x384 resolution (Still pretty "high res" by the standards of color graphics in 1980.) with 8 bit color. You need actual DAC hardware attached to the graphics CPU to actually drive the analog RGB monitor it would presumably be connected to. Dunno if you can effectively do the color palette lookups in the CPU with the leftover CPU time while using basically all of the memory bandwidth at 100%. Maybe a 68k wizard would be able to work out some way to do it efficiently. If not, you'd need another circuit to go from the raw framebuffer data to the values feeding the three DACs.