Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
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 developed the drive scheme). Pete Macourek and I figured out how to 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.
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 canceled, I would have had a major part in the design of the CPU and the Graphics chip on the 99/8 and 99/2.
Back in 1992, 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 (called the TMS320C80 or MVP). The Synchronous DRAM was another “little thing” that came out of that program. 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 interface with SDRAM because it was co-designed with them directly.
For anyone interested, I wrote more about my TI Home Computer and 9918 history on this blog back in the early days of this blog in 2011.
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!
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.
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!
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.
“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?
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.
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.
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.
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!
I was curious, as you mentioned that you were not the only team member, who else was on the TMS9918 team? Certainly it would be interesting to know if they have kept anything over the years.
I was also rather curious about the sprite system. You have mentioned in the past the similarities to Atari’s “player/missile” system, but was it drawn directly from that? How much did you look at the architecture of the Atari graphics hardware in designing the chip? I’m curious because I have heard some indication that there may be deeper links between the projects so I wanted to know if that was the case from your perspective.
Thanks for your great work!
The 9918 was the first consumer video chip to use DRAM. As a result, our architecture was very different from the older “player/missile” graphics. The older design had the shape of the “players” in a small ROM and some dedicated timing registers that counted down to decide when to put them out. The 9918 was more of a processor in that it made two passes at the sprites. It first looked to see what sprites would appear on a given line and then later went back during horizontal retrace and got the sprite shape and color information. This led to the 4 sprites on a line and 32 sprites on a screen with there being different size sprites. The number and size of sprites was limited as much by memory bandwidth as it was by hardware.
I don’t think anyone else has anything near as much as I have tried to archive. A while back I gave someone a bunch of scanned files: http://spatula-city.org/~im14u2c/vdp-99xx/
The other members of the team (most of which were listed on the patent – http://www.freepatentsonline.com/4243984.pdf):
Pete Macourek (went on the found Rose Electronics) – Pete and I did most of the overall architecture and the digital design.
David Ackley – He was a manager and came up with the early requirements but moved on pretty early on in the process
Gerald Rogers – He was the overall manager and did not do design work — he later founded Cyrix
Ki Suk (Richard) Chang – He was the design manager and did a lot of more complex circuit design. – He started at TI in the early days of calculators and worked on several of them. He eventually moved back to Korea and became a V.P. of a semiconductor company.
Joe Sexton – He did a lot of circuit design, particularly the part associated with the video output circuitry
Sergio Maggi – He developed the overall timing circuitry and design. The device was controlled by PLA followed by some very large buffers that had to run at very high speeds.
Clark (can’t remember if this was his first or last name) – He was on “lone” from Dallas to Houston to help with the design. He was an I2L designer that joined us to learn about NMOS design.
Hi, Karl. I’m David and I worked for a company who clean room reversed engineered the Sega Genesis / Master System in the early nineties. We of course noticed the similarity to the 9918 and the publicly available 9918 documents were quite helpful. We were sued by SEGA and it damaged our company even though they lost. I find it quite interesting that they were able to clone the 9918 and rev it for use in the Sega Genesis and elsewhere. You also mention Nintendo and others also doing same. Now in today’s world I’m sure this wouldn’t fly. How was this possible in the 80’s and 90’s? Why didn’t TI pursue all these unauthorized clones from big companies?
David,
I was not involved in TI’s Patent strategy in the early 1980’s. Later was on TI’s corporate patent committee and TI had a process to identify technology. We only filed the one patent on how the Sprites worked (http://www.freepatentsonline.com/4243984.pdf), the claims were narrow, and we didn’t follow up with divisionals applications to try and cover more. I suspect it never got on TI’s corporate patent radar and it could very well be they didn’t realize the value. The top ranks of the company didn’t seem to like video games. It could also be that there was existing cross licenses. By the time Nintendo and Sega (both of which wrote software for Colecovision that used the 9918) became big, I was off to work on CPUs and then the TMS340 Family.
The 9918 clones were pushed by ASCII Microsoft, a Japanese company that was originally affiliated with Microsoft (they jumped on the Microsoft bandwagon early https://en.wikipedia.org/wiki/ASCII_Corporation). It always seemed like a strange relationship between ASCII and Microsoft and they seemed to have autonomy in Asia for non-PC type projects. ASCII was behind the MSX computer in Asia that used the 9918 family. One of the super-set-clones was made by Yamaha Semiconductor (I think this one went into Sega and the 2nd Gen MSX Computers) at the request of ASCII.
Hey Karl,
I thought you might be interested in an ongoing retro project using the TMS9118:
http://github.com/calphool/TRS80GS (this was a prototype)
http://github.com/calphool/TRS80MXS (this is going to be the first “proper” version)
I’m actually wanting to evolve the video subsystem a bit to merge the TRS-80 video signal through the Ext-In line at some point, though that may be a V2 of the TRS80MXS. It looks like there will be a lot of analog stuff to get the composite out of the TRS-80 conditioned to be usable by the TMS9118…. I may have to split the sound card off to make room (which would
allow me to go even crazies on the sound card I suppose…. lots of era appropriate sound chips:
SN76489s, SIDs, AY-3-8910s.