Texas Instruments 99/4A and TMS9918 History

A little break from displays today to go back into my deep dark history. For my first 20 years in the industry, I was an I.C. designer and led led the architecture a number of CPUs and graphics devices.

I got a “shout out” of sorts in an IEEE article on the 99/4 computer by Wally Rhines, CEO of Mentor, about my work on the TMS9918 graphics unit which was my first design (started in 1977). Contrary to what the article states, I was NOT the only designer, back then it took 7 “whole engineers” (quite a few less than today) to design a graphics chip and I was the youngest person on the program. I think the 9918 took less than 1 year from raw concept to chip. Wally gave things from his perspective as a high level manager and he may be off in some details.

The 9918 coined the word “Sprites” and was used in the TI 99/4A, Colecovision, and the MSX computer in Japan. It was the first consumer chip to directly interface to DRAMs (I came up with the drive scheme). Pete Macourek and I figured out how to make the make the sprites work and then I did all the Sprite logic and control design.

A “Z80-like” register file compatible superset clone of the 9918 was used in both the Nintendo (Nintendo was a software developer for Coleco) and Sega Game systems among others.

After working on the TMS9918, I led the architecture and early logic design of the TMS9995 (which resulted in my spending 6 months in Bedford England) which is also mentioned in Wally’s article. If the TI Home Computer was not cancelled, I would have had a major part in the design of both the CPU and the Graphics chip on the 99/8 and 99/2.

Back in 1992 in the I was interviewed about the home computer in the days of BBS Bulletin Boards. This was only about 10 years after the events so they were more fresh in my mind. At the time of the 1992 interview, I was working on the first fully programmable media processor (and alluded to it in the interview) that integrated 4 DSP CPUs and a RISC processor on a single device (call the TMS320C80 or MVP). Another “little thing” that came out of that program was the Synchronous DRAM. You see I had designed the DRAM interface on the 9918 and the TMS340 graphics processor family and had worked on the Video DRAM (predecessor of today’s Graphics DRAMs) and was tired of screwing with the analog interface of DRAMs; so in a nutshell, I worked with TI’s memory group to define the first SDRAM (one of the patents can be found here). The 320C80 was the first processor to directly interface with SDRAM because it was co-designed with them.

For anyone interest, I wrote some more about my TI Home Computer and 9918 history on this blog back in the early days of this blog in 2011.

9 comments

  1. Hi, great article!
    I’m Alejandro from Argentina, and really like retrosystems. In fact, I have a TMS9918ANL that I have received from a friend, but wasn’t tested never. How do you think that I can test it easy? This VDP has a free run mode like other processors or something like that? I really want to use it but before I need to check if the chip is working.

    Thanks! Regards from Argentina!

    1. Thanks, I wish I could be more help but it is about 39 years since I brought up a 9918 on a board.

      I don’t think there is any “free run” mode per say. It is hardwired so I think it will start off doing DRAM refresh. I think even without a DRAM it will run generating memory signals. You could use a scope to see if the DRAM pins are wigging.

      Remember this was designed in 1977-78 and we could not afford extra transistors. It only has 40 pins so you need to get the DRAM interface connected (be careful the pin numbering is messed up — a lot of people get the address pins wired up wrong, it was designed a “little endian” I/F but at the last minute they renumbered the pins big endian. I’m not sure what DRAM you can get today that will work. Back when we used 4K and 16K by 1 Analog Timing DRAMs.

      Once you have the DRAM interface connected, the chip should take off. It will have garbage in the registers and in DRAM. You can dink data into the chip slowly through the CPU interface. BY today’s standards the 9918 is pretty simple and explained in the user’s guide http://map.grauw.nl/resources/video/texasinstruments_tms9918.pdf

      If you have more questions, please feel free to ask.

      1. Thanks very much for the response! My apologies for the delay, I haven’t received any alert in my mailbox with your answer and I had believed that you was very busy to answer. I will check with more frecuency your blog 🙂

        I have tried with your advice but I believe that the chip isn’t in good condition.
        Talking about the DRAM, I have tried with this approach https://retrobrewcomputers.org/n8vem-pbwiki-archive/0/35845334/48860720/33053543/SRAM%20Replacement%20for%20TMS99x8%20VRAM.pdf without success.
        I have tried with an external clock source, with a crystal too but all my attempts were unsuccessful.

        I will try with a chip that I have in a old colecovision, sadly in this case I have the same situation, I don’t know if the console works but I will try again with my fingers crossed.

        Regards!

        1. I know the chip was designed to work with a very specific crystal per the specs. The second crystal pin is to provide “feedback” to get the crystal to oscillate. The crystal inputs can be driven by and external clock but you have to drive both pins (I think they have to be the inverse of each other but I am not at all sure about this). Make sure you have removed the crystal if you are driving it.

          Using an SRAM with a latch to replace the DRAM makes sense. Thanks for the reference.

      2. “I’m not sure what DRAM you can get today that will work. Back when we used 4K and 16K by 1 Analog Timing DRAMs.”

        As a matter of fact, 4164 and 41256 type DRAMs are still manufactured (there’s a whole industry dedicated to keeping 70s and 80s arcade games and pinball tables running), so you should be able to use a set of those simply by connecting high numbered address pins to VCC or GND. 41256 chips are cheaper than 4164s.

        A question that hopefully you can help with: the sega retro wiki at https://segaretro.org/SG-1000 suggests the SG-1000’s TMS9918 has around 7MB/s memory bandwidth, which given that its DRAM chips have a cycle time of 320ns implies that the 9918 used page mode to access the DRAM, but I don’t see any mention of that in the datasheet (although I haven’t read it cover to cover). Is that true, or is that a mistake on the specs for the SG-1000?

        1. Thanks for the info on DRAMs.

          The TMS9918 family did not support page mode. We didn’t have the memory buffering and control complexity that it would have required. If it had had it, we might have been able to support a true bitmap mode but would have probably had to give up sprites.

          You have to go back to 1977 when we started and the amount of registers and logic we could afford for a game display device. We had a hard requirement from the Home Computer Group that the CPU had to have regular access.

          Then you had to consider that at best only 1 out of 4 cycles could have been a page mode. In all but the text mode, First you fetch the “name” (pointer to the pattern), then the color (which could have been page mode but only 1 cycle), then pattern (which was pointed to by the name plus the name table offset so it was essentially random), and then ether the sprite pre-processing (fetching the starting address of a sprite to see if it was visible) or a CPU access (1 out of every 4 sprite pre-processing slots was give to a CPU access). So out of a sequence of 4 accesses, only one could have been page mode.

          I tried to hack in Graphics mode 2 later to give something like a bitmap mode. The main issue was there were simply not enough memory cycles available to support a bitmap mode without a massive redesign. This issue led to my work on the Video DRAM (the forerunner of Graphic DRAM) and the Video RAM help lead to the Synchronous DRAM where instead of having a separate serial port the high speed data was routed over the same data pins.

  2. Can I ask a random question on the 9918’s colour burst? I’m pretty sure I read that if left to its own devices, it’s off-spec. It outputs a colour burst at approximately the right time, but outputs exactly the same waveform every line. So the chip’s colour encoding abruptly jumps in phase between each line and the next.

    Is that accurate? If so, how does that play against genlocking?

    I see that on your Arizona Technical Symposium Draft you seem to have an expectation that an external source will watch the 9918’s declared clock output and adjust its input clock to cover the discrepancy. So the expected setup — assuming a fully-conformant external source — effectively shifts the 9918’s output backwards or forwards by half a colour clock every other line?

    I might be way off, I’ve just started reading up on this, and it’s a personal curiosity only.

    1. Its been almost 40 years and I am working from memory but as I remember it:

      The problem with the 9918’s color burst is that it is 100% in-phase from line to line, there is no “jump.” The NTSC standard would have and extra 1/2 burst cycle in blanking so that if you drew a perfectly vertical line, the color burst would be out of phase from line to line and thus tend to cancel, which it does if something is static, but then the rainbows move when the object moves. The other issue is that the 9918 was NON-Interlaced which meant that when it refreshed it hit the same lines from frame to frame because there was not an extra 1/2 line at the end of the frame. With the NTSC method; this meant 1/2 the resolution but it eliminated flicker.

      When in external video mode, the VDP is digitally slaved to the video source and uses the external video’s color burst signal. But it only synchronizes to the pixel clock level and thus the pixels “crawl”. Note pixel clock was derived from the color burst by multiplying the burst by 3 and dividing by two. In external video mode there are a few “pad cycles” where it is waiting for a sync signal to reset the pixel counter. Below are links to two contemporary papers, one by Pete Macourek (who did most of the work on external video and this paper gives more details) and one where I summarized how it worked. I think Pete experimented with phase lock loops to try and cut down the amount of pixel crawl.

      https://www.kguttag.com/wp-content/uploads/2017/11/198x-External-Video-by-Pete-Macourek.pdf
      https://www.kguttag.com/wp-content/uploads/2017/11/198x-External-Video-by-KG.pdf

      Hopefully this helps clarify things but if you need more, let me know.

      1. Oh, got it, I see my foolish error: I assumed the chip, when not gen locking, was producing an on-spec line time but therefore an off-spec colour burst in the sense that phase is inconsistent from one line to the next. For some reason it hadn’t occurred to me that the converse was more likely: a half-cycle stretch of the line time so that all colour burst signals are consistent with one another. That was foolish as I think the latter was fairly common at the time? It also seems to be the approach of the contemporaneous Atari and Apple machines, at least.

        I’ll pore over those documents more fully, but I think you’ve resolved my confusion. Thanks!

Leave a Reply

Your email address will not be published. Required fields are marked *

%d bloggers like this: