11 May 2016
(This article first appeared on my Hackaday.io project page. I’ve since made some minor edits, and reposted it here.)
After stumbling upon a fairly sizable collection of design notes and interviews from the inventor of the Texas Instruments TMS9918A VDP (video display processor), I began to entertain the possibility that maybe the Kestrel-3 should use a VDP-like video core to replace the MGIA instead of my original CGIA (Configurable Graphics Interface Adapter) idea.
I’ve not disclosed details about the CGIA much anywhere because I never had a need to, but this is what I’ve been thinking. Take the MGIA logic as-is, and expose some of its guts to the programmer. In particular, retain the ping-pong scanline buffer, where a (now programmable) DMA engine fetches data into the ping buffer, while the CGIA refreshes the screen from the pong buffer. Every HSYNC, the CGIA simply swaps the roles of the ping and pong buffers.
The fetch logic would not make any attempt to interpret the meaning of the bits it stuffs into the ping buffer at all. Meanwhile, the contents of the pong buffer would be clocked out at a configurable rate (thus achieving a configurable horizontal resolution), with the bits routed to a palette register bank in a configurable manner. In this way, the programmer would have complete control over video bandwidth/CPU bandwidth tradeoffs.
The TMS9918A exposes only a minimal amount of configuration to its user; coming out of reset, it is basically configured in a 32x24 character display (what they call “pattern graphics”). The configuration it does offer is, for example, whether or not you’re using 4K or 16K dynamic RAMs, whether or not background video is genlocked, and where the various display tables will appear in video RAM. The number of colors supported and the monitor synchronization timing are all hard-wired to support NTSC television, not unlike the Kestrel-3’s MGIA being hardwired to support IBM VGA. A completely separate chip had to be made a few years later to address the PAL market.
Later generations of the VDP, such as the V9938, V9958, and V9990, all added higher bandwidth paths to memory when they became available, support for higher color depths, planar as well as patterned graphics, etc.; but, they otherwise retained their hardwired video timing parameters. An open source clone of the TMS9918A that borrows some V9938 features, and which drives a VGA display, is also available online.
Finally, there is the Gameduino 1.0 device, which is perhaps the first VDP-like video interface to actually drive SVGA monitors (800x600 72Hz, to be precise). It’s feature list is most impressive; however, it is limited in its resolution (400x300 visible pixels out of 512x512 addressible pixels) and available on-screen colors (globally on the screen, you can show lots of colors; but your palette selections for local details are limited and highly optimized for tile-based graphics, such as you’d find on NES-like gaming consoles). It fills its niche quite well, but I don’t think it’s appropriate for the Kestrel-3.
I think, if I were to go the VDP clone route, and it is indeed appealing for a number of reasons, I do not currently see a reason why I couldn’t add the programmable video timing parameters I’d like to see. Moreover, I can have it bootstrap into a planar graphics video mode that is backward compatible with the MGIA, thus allowing existing system software to work with it. No need to recompile any existing graphics drivers except where color, sprites, or different resolutions are needed.
Benefits of my original CGIA concept:
Detriments of my original CGIA concept:
Benefits of adopting a VDP-like architecture:
Detriments of adopting a VDP-like architecture:
I can’t think of any further disadvantages. I should point out that the horizontal smooth scrolling problem is caused by the same problems in both VDP and CGIA designs. They would be solved in the same way for both as well. While I list lack of horizontal smooth scrolling as a detriment for both, any solution I come up with for solving that issue would equally apply to both VDP and CGIA.
So I’m curious about your thoughts; should I try to go with a VDP architecture? Would this make the Kestrel-3 more appealing for others to use or program for? Should I stick with a simpler graphics architecture and rely on improving CPU performance to make up for sluggish frame rates in the future?
Software engineer by day. Amateur computer engineer by night. Founded the Kestrel Computer Project as a proof-of-concept back in 2007, with the Kestrel-1 computer built around the 65816 CPU. Since then, he's evolved the design to use a simple stack-architecture CPU with the Kestrel-2, and is now in the process of refining the design once more with a 64-bit RISC-V compatible engine in the Kestrel-3.
Samuel is or was:
Samuel seeks inspirations in many things, but is particularly moved by those things which moved or enabled him as a child. These include all things Commodore, Amiga, Atari, and all those old Radio-Electronics magazines he used to read as a kid.
Today, he lives in the San Francisco Bay Area with his beautiful wife, Steph, and four cats; 13, 6.5, Tabitha, and Panther.