Revisiting the TGL-6502
My TGL-6502 project still gets a few hits - I haven’t had a chance to do any work on it for a long time but I recently read over some older design notes I made about a possible redesign. It seemed worthwhile to post them here and possibly get some feedback.
The original design was a challenge to myself to see if I could actually build a working emulator in the constraints imposed by the DIP version of the LPC810 - once it was running though it was actually kind of fun developing code for the emulated system. Alan Cox even ported Fuzix (a Unix like system for 8 bit processors) to it.
The notes I made on possible improvements have dropped a lot of those restrictions, about the only constraints I have left are that it must be relatively easy to hand solder and only use readily available parts. Here are some of the other design changes I was looking at:
While working with IO and memory constraints was a nice challenge it severely limit what could be done with the system. Moving to a 48 pin ARM chip in LQFP format would open up a lot of possibilities while still being cheap, easy to solder and readily available. Something like the STM32F030CCT6 with 256Kb of flash and 32K of RAM would make the system a lot more flexible. There are quite a few STM32 development boards available on eBay as well which would make prototyping easier.
The additional flash could allow for multiple emulation cores (Z80, 6809 and the 1802 for example) which could be selected at startup (or specified in the emulated ROM image). Having the extra RAM would speed up emulation speed considerably - far more of the target system memory could be kept on chip and it would be possible to have a ‘fast' mode that only uses the internal memory and avoids caching completely but limits the target memory to 16K.
Having more IO available means that the SPI bus multiplexing system I used in the original design can be removed which would speed up SPI access considerably. It also means I can extend the IO expansion capability of the emulated system as well which would allow for additional functionality to be added without redesigning the board again.
I also made some notes about switching from serial (SPI based) RAM to parallel RAM chips instead. This would use up a lot of the additional IO though, at least 27 digital IO pins would be required to support a 128K (17 address lines, 8 data as well as R/W and chip selection lines). SPI RAM chips are fairly interchangeable and an efficient caching algorithm would alleviate some of the access time issues.
Untethering the Board
The other improvements relate to allowing the board to operate without requiring a host system for communication.
The original design requires a USB serial connection to a PC to access the console and load programs into memory. The serial console would remain but the extra IO would allow a SD card interface to be added so the initial ROM image could be loaded from that. The SD card would be exposed to the emulated processor as simulated hardware (a simple block device interface) so the guest system could access data on the disk as well. This could allow a full Fuzix system to run (or CP/M on a Z80 core).
For full untethering the system needs it’s own input and output hardware - I initially considered a PS/2 keyboard interface and a software generated composite video or VGA output. To keep the load off the main processor this could be implemented on a secondary CPU - there are a number of AVR based projects out there that do this already.
The problem was that getting external hardware that supports these interfaces is getting more and more difficult - even VGA is no longer supported on newer monitors. Moving from PS/2 to USB would not be very difficult from a software point of view but there are very few, if any, 48 pin chips that have USB host support and I didn’t want to go to the larger (and far more difficult to solder) footprints. VGA to DVI adaptors are available and there are chips available to generate HDMI from a VGA signal but these would add to the complexity and cost of the design.
A small LCD screen and a D-Pad style keyboard setup would seem to be the better solution - much like this project. It wouldn’t be very good for a command line interface but it would at least allow applications to get some sort of input without requiring a host computer to be present. The serial console would still be available for development and command line interaction.
Finally the device would need some sort of power supply - either support for a LIPO battery with USB charging or just a set of alkaline batteries.
The final system would make an interesting project - I can see it as a portable 8 bit game platform (or even native ARM code) which would be fun. Keeping the component cost below $AU 30 would be difficult though, add the design and development time and you would be better off simply using a Raspberry Pi or equivalent to achieve the same purpose. In fact you could implement all the functionality in an Android application and get a very similar footprint.
Unfortunately building emulators (or even ‘real’ retro systems) isn’t very cost effective anymore given the wide availability of low cost Linux systems that can be used as the base for the hardware. It’s hard to decide if this is a project for retro enthusiasts or electronics enthusiasts (although there is a lot of crossover between the two groups).
So what does everyone think? Is it worth pursuing as a hardware project or would it be better off as a purely software such as an Android or desktop application? Have you done anything similar yourself?