Software-Generated Video
I’ve become interested in software generated video, after reading the book The Black Art of Video Game Console Design by André LaMothe. It’s a unique book, covering everything from atomic theory all the way up to building your own embedded computer system. Unfortunately it’s plagued by a million errors, but I was still fascinated by the idea of direct synthesis of video in software, which is part of the design of the game system discussed in the book.
Most computer systems (including BMOW) have dedicated video display hardware. The CPU writes data to video memory, and at the same time, the display hardware reads data from video memory and synthesizes the actual analog voltages that constitute the video signal for the monitor or TV. In BMOW the display hardware consists of fourteen separate chips, including the video memory itself, character generator, counters for the current row and column, shifter, oscillator, various registers and buffers, and a RAMDAC. It took a long time to design, but it’s pretty powerful.
In contrast, software-generated video creates the final video signal voltages directly from the CPU or microcontroller pins, with no intervening hardware at all except a handful of resistors to form a simple R2R DAC. You’ve got a MCU, some resistors, and that’s all. It generates the video signal in real time, on the fly, and there’s no need for any video memory or frame buffer. Fascinating stuff. The downside is that you need a fast MCU, and your code must be deterministic and per-clock-cycle exactly identical from scanline to scanline. Almost all the processing power is consumed by generating the video, so there’s little left for other logic, and logic code must be interleaved with the video code. I was vaguely aware of this technique before, but never really looked at it deeply because of all these problems with it. At least, that was the case until I saw some of the things the XGameStation from LaMothe’s book can do.
Check out the XGameStation Micro Edition web page. That’s some fairly impressive stuff from a little microcontroller and software-generated video. I decided I wanted to build one of these myself, as a short but interesting detour from work on 3D Graphics Thingy. Most of the XGameStation systems are prebuilt systems, which don’t interest me much, but there’s also the XGameStation Pico Edition that you can put together yourself. Perfect! Except it’s pretty expensive for what you get. I just can’t stomach paying $60 for a kit that contains a $3 microcontroller and a bunch of passive components that I mostly already own anyway. To make matters worse, a $50 SX-Key is also required to program the SX28 microcontroller, bringing the total cost to $110 for a simple little breadboard project.
I did some research, and found that I can get all the parts I need from the $60 Pico Edition kit for under $10 total, except one: the 78.75 MHz clock oscillator. In order to generate color video, you need a high-speed clock that’s an integer multiple of the base NTSC frequency of 3.579545 MHz. Sadly, these just don’t seem to exist anywhere that I’ve found. The only solution appears to be to buy a programmable oscillator, which is what the kit contains, I think. But programmable oscillators with the speed and precision needed are pretty expensive, and only sold in large quantities. Without that oscillator, it’s possible to generate black and white NTSC video only. Of course this still doesn’t change the need for the $50 SX-Key, for which I’ve found no alternative and no used ones for sale. Sigh.
As an alternative, I also looked into making a simple software-generated video system from a PIC24, which is at the heart of another XGameStation design. That’s a little more questionable, since there’s no specific “Pico” design using the PIC24 whose software I could use, but there is a wider selection of tools and software for the PIC series than the SX28. But the same oscillator requirements exist, and while the PicKit2 programmer is a little cheaper than the SX-Key, it’s still not cheap.
At the moment then I’m stuck, and not sure if I should pursue this idea any further. The microcontroller and other parts can be had for just a couple of bucks, so it’s a bit frustrating that the oscillator and programmer requirements are turning this into a $100+ project.
Read 21 comments and join the conversation21 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
To avoid the need for a colour subcarrier, why not generate RGB video? I think it’s been done with the AVR chip. And while on the subject of AVRs, have you seen this demo, “Craft”:
http://www.linusakesson.net/scene/craft/
There’s also a TV-output shield for the Arduino, made by Batsocks, called the Tellymate:
http://www.batsocks.co.uk/products/Other/TellyMate%20Shield.htm
It’s also AVR-based, but generates monochrome video for either US or European systems.
Ah, that AVR-based RGB colour system is the Uzebox:
http://belogic.com/uzebox/
Yow! That Uzebox is pretty damn impressive. Running at 28 MHz, it puts the 80 MHz XGameStation to shame. I need to look into the details to see how it gets such better results.
One possibility I’d considered is to output VGA, instead of NTSC or PAL as these systems do. That way you wouldn’t need an obscure NTSC*N oscillator, or an RGB to NTSC converter chip. It would require a faster microcontroller though, since VGA has more lines of resolution than a single field of NTSC.
I need to get clear in my head about my goals for this, since I don’t really want to bite off a big new project right now. I’d hoped the XGS Pico might be an interesting little weekend project I could build on a breadboard for a few dollars.
You might want to take a look at the silicon oscillators from Maxim/Dallas semiconductor, like the DS1085:
http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3491
They have a pretty generous sample policy.
It’s configured via I2C, but once configured it can be used stand-alone. Not sure if it’d be precise enough, but maybe you could design a sort of delay-locked-loop with a slower crystal and a counter.
That oscillator divides a 133 MHz master clock by some integer divisor, which I don’t think would be precise enough. I did find that DigiKey sells programmable oscillators with 1 Hz resolution, and you can order them pre-programmed for the frequency you want for $5 to $8. So now I’m down to the cost of the SX-Key being the only annoying thing about the XGS Pico. Since I’m unlikely to ever do any other SX development, I don’t really want to spend $50 on an SX-specific programmer. Maybe I can hand-build a Uzebox variant instead.
Take a look at the parallax propeller. I’ve never used it, but it does PAL/NTSC/VGA and even comes in hobby-friendly DIP package. It is a rather odd architecture, though.
Do you not have any way to get analog RGB directly into an NTSC TV? In Europe, we have the SCART connector, which will accept composite PAL video or separate RGB and Sync signals (and L+R audio). Is there any equivalent in the NTSC world? I’m just thinking of the Uzebox, which we could connect directly to a PAL TV (bypassing the PAL decoder), making it a rather simple setup.
Interesting… there’s nothing like that for NTSC that I’m aware of. Which is surprising, since NTSC and PAL are the same general design, and only differ in some of the timing parameters. They both encode color information in a phase-shifted color carrier that’s superimposed on the luminance signal. So I’m guessing the SCART connector must have some active components to create the PAL color signal from separate RGB inputs, rather than just being a passive adapter.
The DS1085 actually has a DAC connected to a VCO internally, so it can be programmed for any frequency from 66 to 133MHz with a resolution of 10KHz, and the output is fed to the programmable divider (allowing for frequencies below 66MHz). Maybe 10KHz is not precise enough though, and since it’s not crystal controlled, it probably doesn’t have as good frequency vs. temperature or voltage characteristics. Plus you’d still need some kind of I2C interface for programming, and it only comes in SOIC, so you’re probably better off with the programmable oscillator from digikey.
I’ve never used an SX microcontroller either, but I do have a PICkit 2, and I find it very nice. It will program pretty much any PIC and even a large number of dsPICs and serial EEPROMs. It also has a built-in low speed logic analyzer (only a few inputs) and UART tool for debugging.
Thanks, I totally missed that the base clock of the DS1085 was programmable separately from the divider.
After reading up on the SCART connector, I think I misunderstood what it does. In brief, any TV with a SCART connector can accept separate RGB and sync inputs. This ability is built in to the TV itself. It isn’t an adaptor that converts RGB to PAL composite video. Sounds pretty useful– I don’t know why there’s nothing comparable in the US.
You could generate the NTSC*n clock using a conventional NTSC crystal and a Phase Locked Loop (PLL) multiplier. See:
http://en.wikipedia.org/wiki/Phase-locked_loop and
http://www.uoguelph.ca/~antoon/gadgets/pll/pll.html
Essentially, you’d have an analogue oscillator set to run at roughly 80MHz with a divider down to the crystal frequency. The PLL circuit would then “tweak” the frequency and phase of the oscillator so the divided signal stays locked on the required 3.579545 MHz. Hence you’d have an accurate 78.75 MHz (or any other multiple you like) without having to find a wierd crystal.
There are lots of ICs apart from the one described that would help you here. It’s a common technique – your PC will contain several. In this application, it should be pretty easy as you only need a single frequency.
Of course, this doesn’t help with the programmer dongle! I was hoping to find you could program it via J-TAG or similar, but it appears to use some strange method using the oscillator pins. By the way, the parrallax site says the “SX Blitz” is $29.99, which is a bit more reasonable. See:
http://www.parallax.com/StoreSearchResults/tabid/768/txtSearch/sx-key/List/0/SortField/4/ProductID/368/Default.aspx
Have fun!
Merlin
I finally went ahead and ordered the parts to build a breadboard Uzebox. It was $18 in parts, plus $34 for an AVRISPMk2 ISP programmer. I don’t feel too bad spending for that programmer, since I’m pretty confident I’ll use it again for other projects. The Uzebox forums also seem populated with more knowledgeable hacker-types than the XGS forums.
The only tricky thing about the Uzebox is that it’s meant to use SNES controllers, and the matching connectors are tough to find. But since the source code is provided too, it theoretically shouldn’t be difficult to modify to use with another joypad, or just a bunch of pushbuttons for testing purposes.
The SNES controllers are just a pair of CD4021 shift registers and some buttons. Possibly some pull-up resistors, too. Could be home-made if you can’t find ’em elsewhere.
Shame there’s no equivalent of the SCART connector. I think they were introduced in Europe in the 1980s, and were required to be fitted to TVs by government regulations. We use them for satellite, cable TV, VCR and games.
Finding the SNES controllers is no problem. Finding the matching connector for the controller to plug into is the problem. Basically you need to buy some old SNES equipment or multitap adapter, and rip it apart to get the connectors.
I guess I could also just cut the existing connector off, and solder the wires to a standard header or something.
There’s plenty of free pins on the Uzebox basic design. If you’re aiming for a minimum hardware implementation, you can also use DB9 connectors since there’s lots of old and semi-recent joy pads use it (like the Genesis pads). You would not require 4021s in that case. It would be very easy to tweak the “kernel” to support this.
Huh?
I was under the impression that the SCART connector is the same as the oddball one found on the back of my DVR, but strangely enough not on my telly.
This is one of the reasons why I suggested the entire collection of Lancaster Books, Steve.
But you’re doing splendidly anyway.
AVGA is another AVR based minimalist game console to look at. It can be found here:
http://avga.prometheus4.com/index.php?p=2-0
I’ve compiled a list of similar projects on my blog here:
http://zuzebox.wordpress.com/2009/04/03/list-of-homebrew-video-games-consoles/
If anyone knows of any other projects let me know and I’ll update the list
The old XGS Micro is dated, check out the new XGS AVR and XGS PIC, both put the uzebox to shame. The AVR uses the same chip, but has a much better design and the PIC is 4-5x more powerful since its 16-bit. Also, the video hardware on the uzebox is fixed ad725 RGB to NTSC converter, but the XGS has custom video hardware that is more flexible, plus it has VGA out as well.
XGS AVR 8-bit
http://www.xgamestation.com/view_product.php?id=46
XGS AVR 16-bit
http://www.xgamestation.com/view_product.php?id=47
JP
The AVGA looks pretty nice! I like the VGA output, instead of composite video. It looks more like a spec than a specific hardware design, though. It also mentions some things that confused me, like PAL timings for VGA. What’s that? If the documentation were improved a little, and the author settled on a specific ATMega chip and published a complete schematic for it, I think it could take off.
I’m aware of the newer XGS AVR and Pic, and they’re nice, but not really what I’m looking for. They’re all closed systems, purchased as a finished unit. The schematics aren’t published (unless you count this unreadable version: http://www.xgamestation.com/view_media.php?path=products/xgsavr/xgs_avr_ss_12.png&title=XGS%20AVR%208-Bit%20Development%20System×tamp=&caption=XGS+AVR+8-Bit+system+design+schematic.) and you can’t build one yourself. It also includes more hardware outside of the ATMega644 itself than justify calling it a “minimal system”. If I were to buy a pre-built video game system with lots of hardware in it, I’d rather just buy a SNES or something.
I have a nice joke. Which of these things don’t belong: A tuna, a lobster, or a Chinese guy run over by a truck? The tuna. The other two are crustaceans.
___________________________
–/ viafra generic Michigan /–
Yesterday I put the presentation on YouTube on this matter, PIC24H generates VGA signal in text mode, with 25×60 characters. Video RAM is in internal data memory, character set is in program memory.
8 colours, background, blinking, 2 cursors supported. PS/2 keyboard also.
http://www.youtube.com/watch?v=0Ghb5m8NZb4&feature=channel