If you were lucky enough to own one of the crop of 1980s 8-bit computers, did you ever pause to consider how its graphics worked? Maybe the really expensive ones had dedicated CRT controller subsystems akin to the graphics cards you’d have found on a PC a few years later, but most of the affordable models would have stopped what they were doing every TV line interval period to allow access to their memory for their graphical output to be created.
The RC2014 retrocomputer dodges all this, by using a serial port as an interface and expecting your serial terminal to handle the screen. But what if it could produce its graphics directly as the machines of old did? [Rob Dobson] set out to achieve this, and not only did he succeed but he also found a way to directly emulate some classic machines along the way.
His RC2014 card which he calls the Bus Raider started as an attempt to use a Raspberry Pi to commandeer the RC2014 memory and read it via its GPIO lines, interpreting the graphics for its own screen. But even with bare metal Pi programming he couldn’t achieve the complex timing required for that, so he took an alternative approach. He ended up with an ESP32 that emulates a custom part of the RC2014 memory map and generates a display from there. Having created a custom memory map and hardware emulator for his RC2014, he then had the revelation that he could emulate any memory map, and thus he could make the retrocomputer perform natively as though it were any of a selection of classic micros. So far as well as a straight serial terminal he has a Sinclair ZX Spectrum and a Radio Shack TRS-80 running, as well as his own custom Z80 environment. And since the ESP32 also has WiFi, he can even connect to it through that medium.
Retrocomputers are something in which you might think that everything possible would already have been done, but projects like this one never cease to amaze us with their ingenuity. If you’d like to read more about the RC2014, we reviewed an earlier model back in 2016.
I’ve always wondered why in all this time someone hasn’t actually made an addon board for the rc2014 that uses one of the display/crt controller chips of yore to directly output a composite video one can then plug a TV into to make these things feel even more retro. Sure the chips aren’t that readily available, but they aren’t unobtanium. Sure there is the “official” display board using a PI, but it just feels wrong to use something like this on a home brew retro computer. using something that is a million times more powerful than the rc2014 itself as it’s display adapter. Might as well just slap an emulator on the Pi.
Yes, an MC6845 (for monochrome applications) or MC6847 (for color) would be easy to interface to the bus, but the problem is that emulating different machines takes different logic and timing. The TRS-80 Model 1 and Apple ][ both used discrete counter chains to do their graphics, while the TRS-80 Color Computer used a 6847, the Commodores used ASICs, and the Sinclair ZX80 used the Z-80 itself to generate video signals, so while using a 6847 would make it relatively easy to emulate the CoCo, it would be more difficult to emulate machines that used either discrete logic or other controllers.
What might be more practical, though, is using a small FPGA for this, which is at least at the same level, logically, as the originals (with the exception of the ZX80, which is somewhat problematic). With an FPGA, it should be possible to just upload different code for each target machine being emulated, and with pixel doubling/tripling/whatever, the output can be compatible with standard HDMI TV timing specs.
Well I wasn’t particularly thinking of emulating an existing machine(s), but building from the ground up a period correct display controller for the RC2014. If that is emulation of an existing system’s display or rolling all new gathering the best parts of several systems display output, there is likely a lot of knowledge out there about how the display output could have been done better over the last 30ish years. Whereas all the existing system were stuck with whatever was developed from the get go for compatibility sake.
Good point – there are two separate things one might want to do in the way of a “period appropriate” graphics adapter, one being emulation of vintage systems, the other being the development of a graphics adapter using 1980s technology, for a Z-80 system.
The latter is what would actually be of interest to me. I’ve already designed and built several different graphics adapters that were intended to display text and graphics on a CRT, and more specifically, a CRT display with the timing and resolution of NTSC or PAL signals. The more interesting thing today, since CRT displays have definite disadvantages, would be to develop an adapter to connect directly to an HDMI or DVI-D monitor. In the spirit of 8-bit systems, this would be text and/or bitmapped, with the system’s CPU writing either to shared memory, or writing to I/O ports specifying the (x, y) location and a code representing the color of that pixel location.
I realize that the problem here isn’t generating data in a compatible format, it’s getting the display identification data. But since this is handled using I2C, it wouldn’t be unreasonable to use an 8-bit microcontroller to handle that, just as 8-bit systems sometimes used dedicated microcontrollers to communicate with disk drives, for example.
@david smith, Show us your attempts to solve this problem? Or was this just another thing you “wished” you had accomplished but never attempted?
The MC6845 isn’t limited to monochrome. The BBC computer, Amstrad CPC range and the IBM CGA adaptor for example all used them and were colour capable.
The MC6847 is a more complete implementation of video (the MC6845 requires a number of external chips to support the process) but is much less capable in terms of its output, being limited to 8 colours and 6K of video RAM.
The 6845 is not really a complete CRT controller. It’s more a timing generator and counter that still needs a lot of support logic before you get a video signal out of it.
There were better chips for this purpose. Like the VDC from the C128.
The better micros from the 80’s interlieved the memory access with the CPU so there was little or no reduction in CPU performance. The BBC Computer for example used the fact that a 6502 accesses memory every other clock cycle to allow both systems to run without interference. The Z80s memory timing made things more complicated, but adding a CPU wait-state when access requests clashed had only a minor performance impact.
Reading from the links, I get the picture that it is the RaspPi that’s doing all the work for the video + input emulation. He just needed a few support chips to make it workable. The ESP8266 is just used as a portal to download code to the Z80, and wasn’t necessary for the I/O emulation at all.
Sounds like it would be really interesting to make the ESP8266 or ESP32 emulate/shadow the graphics memory, as well as providing a web-based interface (websockets?) to actually interact with the retrocomputer via a browser. It surely has the horsepower to reliably sniff the bus, although perhaps not enough GPIO pins?
In case anyone is still looking at this article, I have now listed the BusRaider (actually a new version that supports singe-step debugging too) on Tindie – https://www.tindie.com/products/robdobson/busraider-graphics-debug-kit-for-rc2014/
I have now placed this card (actually an updated version that supports single-step debugging) on Tindie https://www.tindie.com/products/robdobson/busraider-graphics-debug-kit-for-rc2014/