From VCF Southwest
Karl M. Guttag discusses the history and design of the Texas Instruments TMS9918 VDP graphics processor.
Engineers made it little-endian on the inside, marketing insisted on it being big-endian on the outside. Lots of technical details within!
Slide deck here (pdf).
I really liked that talk. In 1981 I decided to build a computer with two coworkers using the Z80 processor, the 9918 video chip and the 5220 voice synthesis chip. We called it Einstein, which by coincidence was what Tatung called their Z80/9918 computer. We had the chips but the only documentation we had for the 9918 was Steve Ciarcia’s article in the August 1982 issue of Byte magazine where he used it for a video card for the Apple II.
Before that I had tried writing to Texas Instruments a few times, including using the official University of São Paulo (Brazil) stationary but didn’t have any reply. In July 1982 I was visiting my sisters who were spending a year in California and scribbled a note to TI giving their address. Soon after I got back they called and said a large package had arrived for me, which a friend who also visited them brought to me in January 1983. Though most of the material was about their new 320 DSP family, it did include a nice databook about the 9918. I skimmed through it but was no longer working on the Einstein since me and my friends have gone our separate ways.
A few months later Fabio Cunha, the friend who has brought me the databook, asked me to help him design a children’s computer. Though I had a 9918 chip handy I decided not to use it because I remembered that TI Logo on the TI99/4 would “run out of ink” because it didn’t have a bitmap and could only redefine 256 characters out of the 768 visible on the screen. And since I wanted to use the more powerful 6809 instead of a Z80 (a decision I was happy with when implementing Logo in assembly for both processors later on) it seemed obvious that the same chipset as the TRS-80 Color Computer would be a good option.
Had I read the 9918A databook more carefully I would have noticed the new Graphics 2 mode that did have 768 unique characters and so the “out of ink” problem would no longer apply. I only found out about this many years later.
An excellent article!
I think it’s safe to say this was the most advanced display chip of its era. The C64 had larger sprites, and the Atari had more colors but in pretty much every other way this was superior.
One of the interesting bits of the design was the video pass-through. This allowed it to be used for video overlay on top of a VCR, for instance. I have not actually seen this used though, does anyone know of any uses? The system did require the external video to synch to the computer clock, and maybe that was an issue in practical terms, I don’t know if it’s easier to make the computer synch to the source or vice-versa… any video experts chime in on that?
On the downside, the lack of collision detection on the sprites was a major drawback IMHO. The per-8 pixel colouring and the whole attribute collision issue is also an annoyance, but one you can work around in most cases.
It is also interesting that the TI-99, among the small number of machines that seem to have used this system, had (when I saw it at least) absolutely abysmal output. The image in this post seems to confirm it wasn’t just the machine I was using. I never saw an Adam in the wild, so I’m not sure if this was better in this regard? I am comparing to my 400, which had superb quality, so perhaps it’s just a high bar.
In the talk Karl mentioned that some captioning systems used the 9918 like this. The reset pin doubles as an external sync so that the VDP will match its timing to the external source (over which we have no control, normally).
The databook shows a pair of 9918s (or 9929s) with the output of the first becoming (after some voltage conversion) the external input of the second. This gives you 64 total sprites, with 8 per line and two independent tiled backgrounds. I am not aware of anyone actually using this.
Ahhh, that’s a detail I had missed. I thought you had to have the external source capture the chips clock. Doing the opposite is much easier of course.
Crucially the C64 had smooth scroll which the 9918 did not although the C64 video designer Al Charpentier, mentions be did miss on making it more efficient by not adding the allowance to move the start of the character screen by bytes to avoid an entire 40x25 chunky scroll every 8 scroll positions. Interestingly, a method of doing just that was found by abusing the hardware and was used to great effect in the later game Mayhem in Monsterland. However, it did come at some risk of corrupting RAM on certain models.
Smooth scroll was added by Japanese firms to the 9918 as they evolved it later.
The 9918 evolution was particularly evident at Sega who used it in all their systems up to and including the Mega Drive (Genesis).
I worked at Accolade during the early nineties and we took a gamble and clean room reverse engineered the Mega Drive rather than pay a fee to Sega - the 9918 documentation from Texas Instruments turned out to be very handy in that effort.
I think it’s fascinating with how much the Japanese riffed on American video game related chips during the eighties.
And lastly, a nod to my native Canadian NABU, developed in 1982 with that familiar recipe of Z80, 9918 and AY-3-8910. I purchased a new old stock unit several years ago and it’s still sitting in it’s box for a time when I clear all my other projects but I am looking forward to getting it up and running!
The TMS9918 was inferior to the C64’s VIC-II chip in almost every way that mattered, but the VIC-II chip was designed years later so it’s not exactly a fair comparison. And it’s also not really surprising given Tramiel’s extreme vindictive war on Texas Instruments.
The only thing the TMS9918 has over the VIC-II is built in sprite multiplexing capabilities, but this is more than counterbalanced by the excellent raster effect capabilities.
That said, the VIC-II’s capabilities were weird and the badlines meant raster routines could take a lot of tweaking to get quite right. In practice, this meant most software used more basic capabilities. But even the basic capabilities were really good.
As for the quality of the video output - the (NTSC) composite output was indeed atrocious, because the dot clock was aligned poorly with the chroma wavelength, and because unlike the VIC-20 and C64 video chips, it did NOT use field-to-field chroma phase inversion to eliminate the bad effects.
The Atari 400 pixel clock was half of a chroma wavelength, which meant the two pixel wide vertical lines used by the default font would be a chroma wavelength wide. This meant that the text would look fine.
The TMS9918 pixel clock was 2/3 of a chroma wavelength, and the single pixel wide lines used by the default font didn’t help. As a result, the visible width of the pixels would vary if they were colored or were against a color background. Also, in 32 column mode, the 8 pixel width of the characters meant that even the same character would look different depending on which of the 3 possible alignments it had. (8*3 = 24 pixels, which is divisible by 3 … the pattern of appearance would repeat each 3 columns.)
