New tech info from the creator of TMS VDP

There are actually some interesting documents in there, nice find

9918
----

Q: Can you describe the design goals when you set out working on the
9918? Were you able to start with a clean slate, or were there some
existing criteria that had to be considered, possibly for compatibility?

A: For the most part, the 9918 was a “clean slate.” I don’t even remember the home computer being that much of a consideration at first.

I was only at TI about 3 months when I was assigned to the 9918. I have already related about the fact that Pete Macourek had to find to put a parallel rather than a CRU interface on the 9918. In hindsight, that was the most important design decisions because if it had had the CRU serial interface nobody would have used it.

As I wrote earlier, even the CPU and DRAM interfaces were designed “little endian” (Intel bit ordering) to be more compatible with the 8-bit CPUs of the era. We only cosmetically renumbered them for documentation as being “big endian” 9900 family members.

Pete worked on the CPU interface with the people from Home Computer. Granville Ott is the person we mostly interfaced with. Granville was very involved later in the video interface (I will write more about that in answering your next question).

They had already decided to have “Sprites” (a term coined by Dave Ackley a TI manager that started the program but soon when on to do other things). There were only going to be 4 total when I joined the program, but Pete and I worked out the Sprite processing logic with a “sprite stack” and “sprite pre-processing” that let us support 4 sprites on a line with 32-sprites on a screen.

I came up with the DRAM interface timing (I still have the timing diagram I drew to convince the managers that it was the way to go). The problem was that the bus turnaround time to go from reads to writes was too slow. We were given a write requirement by the Home Computer folks that we had to have so many data write slots for the CPU interface per unit of time and there just would not be enough time to turn around the bus. That is when I came up with the idea of having multiplexing the DATA Out on the Address lines since DRAMs at the time all has separate Data-In and Data-Out pins. This allowed us to quickly go from CPU writes to display reads.

When we did the DRAM interface, we were really pushing the DRAM cycle performance. In fact at the time (1977) running the 9918 at 5.4MHz was considered very fast (most other chips were 3MHz or slower) and doing a DRAM cycle every two clocks was really pushing it.

The original 9918 was designed for 4K DRAMs because we figured that they would become cheap soon for Video game. Supporting 16K DRAMs was almost an afterthought. But what happened is that 4K DRAMs became so cheap that everyone stopped making them, so all the systems ended up using 16K. I don’t know/remember, but this may have influence the Home Computer designers to use the 9918’s RAM for main memory.

As a side note, my work on the DRAM interface for the 9918 in later years led to my helping define the Video RAM and later the Synchronous DRAM (SDRAM) commonly found in almost all computers today.

Using DRAM on the 9918 was pretty radical at the time. Other graphics chips (used in say Intellivision by Mattel and the older Atari chip sets) had a few hardware player graphics (similar in function to Sprites) and a very limited background that came from SRAM which was expensive and thus they could only afford simpler backgrounds.

Q: What were the limitations present when you were designing the 9918
that limited the resolution to 256x192?

A: In video we often talk about “magic numbers” that come from various multiplications of various numbers. Since the 9918 was going to drive the NTSC video directly (the 9928/9929 for Europe did it externally), we had to use the TI’s color burst (color clock) which is 3.58xxxx (out to about 10 digits). If you multiply 3.58 by 3 and divide by 2 you get our clock frequency of about 5.4MHz. By the way if you multiply the 3.58 by 4 and divide by 3 you get 4.77MHz which is the clock rate of the original IBM PC (originally it was going to drive a TV as well but they changed their mind before going to market).

If you run a US TV in non interlaced mode (video games ran non-interlaced to avoid flicker) you will find that 5.4MHz will give you about 256 visible pixels per line. It also turns out that the pixels will be “square.” Some companies (I think Commodore) in this era had 320 pixel per line by going to 2X 3.58 = 7.18MHz but the pixels will end up non-square.

We relied on the Home Computer group for our information on NTSC. It turns out that at 5.4MHz and 256 pixels per line while the pixels are all technically “visible,” most TV makers had about 10% overscan (done to give a wide tolerance to make sure the picture fills the screen) which in turn cut off about 8 pixels in each side. The Zenith built TV based monitor was “tweaked” to not have the usual TV overscan.

At the time running at 5.4MHz was a huge challenge and unlike CPUs that could have different speed grades, it was 5.4MHz or nothing for the 9918.

Perhaps the biggest limitation was not memory storage but bandwidth into the DRAM. With 16K bytes of memory while we had enough storage to do a full bit-map but there was not enough bandwidth. This is the reason for the much maligned graphics mode 2. We wanted to put in full bitmap, but there was just not enough bandwidth to do 4 bits per pixel over an 8 bit bus. If you consider it took us 2 cycles per DRAM access we would have just enough time to read 8 bits/2 pixels but we would have to lock out all the CPU writes except during horizontal blanking and we would not have any time to do Sprite “pre processing” (described more below). So you would have had a 4-bit per pixel bitmap with no sprites and it would be very slow to change (because the CPU could only make about 1 access per line during the horizontal retrace.

By the way, the limitation of 4 sprites per line was also a result of bandwidth. We didn’t have enough DRAM accesses to support a 5th Sprite without locking out the CPU for too long.

FYI, the basic processing scheme was that during the Horizontal retrace/blanking we would go though the list of 32 sprites and see which of 4 would be visible on a given line and as well as the 5th sprite and then fetch up to 4 sprite line segments that that would be displayed on a given line. During the active display, we fetched the background information and gave accesses to the CPU.

I remember one feature we debated adding was the scrolling background but did not do it because of the complexity of implementing it (it would also require one additional memory access).

Q: Are you aware of any hardware bugs, undocumented behaviors or
glitches in the 9918A that made it to production? (My thinking being,
maybe there's something we can try to take advantage of. Glitches
provide the most interesting opportunities to make hardware do new
things. They only figured out how to glitch the Atari 2600 video
circuitry for reliable interlaced video a few years ago, for example.)

A: I can’t think of anything off the top of my head.

Q: Do you remember offhand whether any data from VRAM is cached in the
chip? For example, we have docs from Paul Urbanus which note that the
first four active sprites on a line are cached, is anything else cached
or is it always fetched as needed?

A: Pretty much everything if fetch “just in time.”

During the active display a memory cycle was as long as 2 pixels. The graphics modes required a NAME fetch, a Pattern fetch, and a Color Fetch or a total of 3 Fetches that would give 8 pixels of background and leave 1 fetch every 8 pixels for either a CPU access times) or sprite preprocessing access. During the active display there were 256 pixels, and 128 memory cycles. Of these cycles 3/4th we used by the background leaving a total of 32 to be shared between the CPU and the sprite preprocessing. I think we gave a few of these 32 to the CPU and had a few preprocessing accesses to do during blacking to get to 32 sprites.

During the active display we did sprite preprocessing where we went though the 32 sprites looking ONLY at the line number and the size (which was the same for all sprites because we didn’t have the memory cycles to fetch the information). These sprite preprocessing access were done every 4th memory cycle (with some of these given to the CPU). This would determine if the sprite was active on the next line. If a Sprite was “active” we would save the sprite number and on a first in first out (FIFO) stack which was 5 entries long (4 active and the 5th sprite number.

When we hit blanking, we use the sprite number stack to go back and fetch the 4 bytes information for each sprite. We then used the size and starting line of the sprite and current line of the display to compute which the address of the line of the sprite.

Q: Can video memory be externally accessed during a scanline or do
access periods occur only during hblank and vblank?

A: As stated above, we gave read and write access to the CPU during the active display. I would have to go back and look at the design note which I have boxed up some place, but I think we gave the CPU an access about 1 out of 16 cycle (with 12 of the 16 going to the background and 3 of the remaining 4 going to sprite preprocessing). The CPU also got a few accessed during horizontal blacking between the sprite processing and it of course got a lot of accesses during vertical blanking.

Q: Personally, I think multicolor mode (64x48) is great, and reminds me
of the Apple2 lo-res mode. We know the Apple lo-res mode is there to
play Breakout, similarly can you discuss why the 9918 has multicolor
mode? (Is there a story there?)

A: We had the luxury of DRAM and thus a lot of storage relative to previous graphics chips. Unfortunately, as stated above we did not have enough bandwidth to support full bit map graphics. So the other modes were a way to give a compromise between resolution and numbers of colors.

Q: Are you aware of any systems that used the 9918's genlock/external
video functionality? Were there any "gotcha"s to using it?

A: I know lots of people tried and I think there were a few products but. This was a much desired feature and was a pet project of Pete Macourek. When Pete left TI not long after the 9918, I took over supporting it in my “spare time.”

The big problem originally was the relationship between our pixel clock and the 3.58MHz and the fact that they were tied together on the 9918. With the 9918, you could either LOCK to the dot clock OR lock to the color clock but not both at the same time. So you either got the colors flashing if you locked on the pixel, or you got wiggly pixels if you locked on the color. With the 9928 and 9929 you could get it to work and several people did because the color burst was separate.

Q: Is there a story behind where the idea of sprites came from and what
it took to implement them in the 9918?

A: Atari and some earlier graphics chips had hardware player graphics. The idea with sprites was to give more of these players. A big difference with the 9918 is rather than have a dedicated set of hardware for each sprite, we had sprite pre- and post-processing with hardware that was shared with all the sprites.

Pete and I worked out the sprite processing. I’m pretty sure I’m the one that came up with the “sprite pre-processing stack” but I couldn’t swear to it.

Q: Why was the 9918 designed with an 8-bit bus to the host system vs. a
16-bit bus? (It seems that TI had already moved on to 16-bit systems by
that time.)

A: We were really thinking in terms of the 8-bit CPUs that were used for games. Also remember that the home computer was going to originally use a 9985 that was going to have an 8-bit memory interface. Back then, 16-bit busses were expensive to support. Note that even IBM when with a 8-bit interfaced 8088 for their first PC.

Q: Why don't you see features of the old VDP's in new modern designs?
(It seems that no matter how fast a system becomes, off-loading work to
co-processors can always help.)

A: Basically everything went to Bit Mapped graphics with a thing called BitBlts. These are bit/pixel aligned transfers. In 1984 after working on the 9995 and 99000 I got back into computer graphics with the TMS340 family which included the 34010 and 34020. At first we called BitBlt’ing “bit mapped sprites” or “software sprites” as in may ways they behave like sprites on top of a background. During the design of the 34010 we learned about the work of Zerox Parc and they called them “bitblts” because they were black and white but because we were doing color pixels, we call them PixBlts.

The problem with hardware sprites is that you are always limited by the amount of hardware for processing each sprite. With BitBLIs you are only limited by the processor speed and your access rate to memory. You could also be totally flexible in terms of size and shape of the “sprites.”

Almost all the hardware accelerators support color bitblt’s so in a way they all are supporting software sprites in hardware. The last vestige of hardware sprites is cursors and I guess for compatibility reasons the graphics accelerator chips still support hardware cursors.

Q: If you could change anything about the 9918, what would it be?

A: You have to look at these kinds of questions in the historical context. We had started on AVDP that was going to add more sprites and bitmapped graphics and even got a chip out, but TI was behind in having CMOS process and the design used a very trick NMOS one that had a lot of bugs and they cancelled the program. At the same time Yamaha did a register level clone and superset that was similar to the AVDP. Yamaha was apparently doing the chip for Nintendo and being in Japan they had the inside track on that design (I don’t know why TI never sued Yamaha based on our sprite patent, maybe we had a cross license, I don’t know). I’m that their chip was register level compatible with the 9918 and suspect that Nintendo, which developed Donkey Kong for Colecovision, use the 9918 in there early game system development.

There certainly were some things we could have implemented more cleanly. We certainly wished we had put hardware background scrolling in the 9918. We wanted more sprites but we didn’t have the memory bandwidth to support them (we used just about every memory cycle we had).

We were pushing the DRAM bandwidth as much as was practical at the time. We were pretty advanced for our day when you consider we had first silicon in mid 1978 and the big volumes for the chip came in 1981 and beyond. In fact they though of cancelling the chip several times before the 99/4A and Colocovision happened.

I guess we could have gone with a 16-bit interface to the DRAM in order to support true bit maps, but that would have seemed ridiculously expensive when we started the 9918 in 1977. We were pretty walled in by the technology of the day. We could certainly see we wanted a simple bitmap but we couldn’t see a way to get there cost effectively.

If things had taken off a bit sooner, we would have probably done the AVDP earlier fixing all the obvious things like more sprites and a full bitmap background mode. But so much time passed between finishing the 9918 (and it small variation of the 9118/9128/9129 that supported the by-4 DRAMS) that is was like starting over. None of the original designers worked on the AVDP and I had moved on to work on the 340 Family of Bitmapped graphics processors.

I have just downloaded the entire page, including all links and attachments.
It is a 12 Mb zipped file.
How can i upload it to MRC? Anyone?

mohai: downloads@msx.org, but that's only meant for freeware, not for complete webpages for which we don't have the exploitation rights, I estimate.. :P So, if you don't have the exploitation rights, ignore this post. I guess hosting these PDF files en doc files could be done at MRC, just make sure it's freeware or at least that we are allowed to do so, e.g. contact the owner.

Yamaha did a register level clone and superset that was similar to the AVDP. Yamaha was apparently doing the chip for Nintendo and being in Japan they had the inside track on that design

So, Yamaha had the power to improve this chip as they did with Nintendo VDP.
Why did they do V9938 VDP that way, i mean, limited scroll features, poor sprites, no bitmap patterned mode?

Anyway, i am glad that our MSX'es did not included NES-like VDPs.

P.S.: I am not gettin answer from that page owner, so ...