Z80 Retro Computer (With Graphics)

Z80 Single board computer

Similar projects worth following
This project is a place holder for the final stages of this project.

The overall project will broken into several sub projects.

The objective is to make a Z80 based single board computer that is a step up from the old retro computers.

The general specifications which will change with design progress are -

1) Slightly higher screen resolution - perhaps 400x300 pixels and 16 to 256 colors.
2) More MIPS - based on a 20MHz Z80 (Z84C0020) a 5 to 10 increase in speed.
3) More memory as it's cheap now - in the range 128 - 512 KB
4) More modern I/O - PS2 keyboard and mouse, (S)VGA monitor, Audio and MIDI interfaces
5) Game inputs of course - Joysticks and buttons
6) Portable storage - SD Card (FAT32 to work with a normal PC)
7) In production chips - No hard to find stuff
8) 0.1 inch pin spacing for ease of soldering - where possible

Latest Status Update:

Sunday 24 April -

Project log added


  • Project overview (Start Here)
  • Periodic short updates
  • Pictures of development tools
  • Graphics hardware development
  • Graphics VHDL development
  • more to come

Most recent update (holdups)

I have put this on the back burner for now as I make a fuser for making PCB's with the Toner Transfer method as I need to make PCB's to prototype with. I am almost finished the fuser hardware and I will upload it a separate project soon.

I am now doing the VHDL with a Altera CPLD (EPM240) and I will order a lager version (EPM570). It took a bit to get used to the Altera IDE as there are no constraints files like in Xilinx.


What I currently have in mind is a Z80 @ 20MHz running the target code, an atMEGA (atMEGA1284 to start with) @20 or 25MHz doing all I/O interfacing and assisting with VGA generation and a CPLD clocking out the pixels to a VGA port @ 50 MHz. The SRAM will probably have to run at 100MHz to be shared between these functions.

To accomplish this, I need to learn the following skills -

  • VHDL programming for the CPLD (I have started this)
  • AVR assembly programming for the atMEGA
  • Z80 assembly programming for the CPU
  • Various hardware protocols for the hardware I/O
  • How to construct a basic multitasking Operating System
  • The FAT file system
  • MIDI standards
  • In house PCB Manufacture (Toner Transfer Method) - in progress
  • And signal timing to get all of this to work together

Proposed major parts are -

  • Z84C0020, Z80 CPU
  • atMEGA1284P-PU, AVR micro-controller
  • XC9572XL, CPLD
  • (unknown), SRAM

The problems I have encountered so far are -

Difficulty finding parts with 0.1 inch pin spacing. I am reverting to using SMD devices on breakout boards. This has created additional problems as I can't find the correct breakout boards for VQFP chips with different pinouts.

Difficulty finding suitable CPLD devices that will work with the 5 Volt Vcc of the CPU. I have so far settled for a 5 Volt 'tolerant' CPLD but it lacks GPIO pins and wont be suitable for the end design unless I use a number of them.

I have had many setbacks with the Toner Transfer Method of PCB manufacture. After buying another laser printer some of the issues have resolved but I am back to square one again. I am using the Pulsar Toner Transfer Sheets and Toner Reactive Foil. My fuser (laminator) has been modified to increase the temperature but the hysteresis of the thermostat is too wide and the feed motor is too fast to maintain temperature on larger boards. I expect I will put a micro-controller into it to regulate the speed and temperature.

Another problem I anticipate is that this circuit is not going to work on bread board because of the high frequency signals. I will probably have to make a modular system with PCB's much like the Arduino 'Shield' system to prototype it as I go, and hence the need for in house PCB manufacture.

The anticipated sub projects are -

  • Build a RAM-less (S)VGA generator in CPLD with VHDL to test as a proof of concept for the video generation. (Done)
  • Attempt to prototype the (S)VGA generator with RAM on a breadboard
  • Installing a micro-controller into a laminator for the Toner Transfer Method of PCB Manufacture
  • Build a solder station out of junk from the junk box.
  • Build the first modular parts for prototyping
  • More to be added

Here are some pics of the development tool I am working with -

This is a development board that I bought on ebay. It is for an atMEGA664. The atMEGA1284 has the same pinout. I had to modify the Arduino IDE to use the 1284. I will use it with the Arduino IDE for low speed proof of concept work using sketch and the USB port. When I am ready to start the VGA side of things I will switch to AVR Studio and program it with the USBasp pictured. The files that came with it had a trojen in some files and changes to the core Arduino java file so started with a new copy of the IDE and made the changes needed. They're not hard to do, just text files, you don't even need to re-compile as the tool-chain already...

Read more »

  • Quick update

    Hacker40404/24/2016 at 05:15 0 comments

    Well my old computer died and i lost a lot of work. I am using a laptop now and it's only got 2 cores (the desktop had 4).

    So I am starting over a bit now. I switched to wire wrap because I have a similar project and I can use the same development bits to start with.

    So here's the board -

    And here is where I am up to with re-writing the VHDL -

    It's 50 x 37.5 character boxes of 8 x 8 pixels in 8 colors.

    I just love the retro look of only eight colors.

  • Made my first PCB

    Hacker40404/09/2015 at 12:00 0 comments

    I started designing a PCB in CAD. I realised that it's not so easy to deal with these chips on a single sided board. The routing is a challenge.

    After a little while I decided that instead I should start with something simple as I have never designed / made a PCB before.

    I designed a tiny adaptor board to mount a SOJ36 chip on a standard width (0.6") DIP.

    I chose the SOJ as that's about the hardest thing I am willing to try to solder. and I chose the 0.6" width to make is so cramped that trace widths and spacings are a challenge. I didn't expect it to work out but I did expect to find the limits.

    The pins aren't in the correct order as there simply isn't enough room on a single sided board. That doesn't matter that much when it connects to CPLD as I can just fix the ordering inside the CPLD.

    Here's the CAD -

    The traces are 10 mill and the spacing goes down to 15 mill.

    Here is the toner and TRF transferred to the board -

    The TRF didn't bond propperly in some places. I am not sure why.

    Here is the etched / drilled board -

    It has a few pits but I expected that for a first run. The fact that the TRF was missing in places didn't make any difference.

    I tinned it with a big blob of solder then cleaned it off with solder wick -

    I soldered the chip on and then the header pins. I then tested for shorts and that everything connects as it should ... all good -

    After taking this pic I realised how much flux is still under the chip. If I clean that out it may even work!

  • Preparing to use the Altera CPLD

    Hacker40404/09/2015 at 11:37 0 comments

    I started checking the Altera CPLD boards I bought on ebay.

    These are the boards -

    Both boards are identical. The only difference being that one has an EPM240 chip and the other has a EPM570 chip.

    Unfortunately they shouldn't be identical as the EPM570 has four less IO pins. This is because four extra pins are used for core Vcc (2 pins) and core ground (2 Pins).

    There are four 0 Ohm resistors (links) missing on the back of the board. I just used wire links to replace them. R2, R3, R4, R5

    C1 and R1 are for an asynchronous power up reset. I didn't bother with them as I wont be using them.

    I also noticed an error on the silk screen here -

    What is marked as pin 59 on the silk screen is actually pin 61 of the CPLD. Pin 59 is *not* an IO pin, pin 61 is an IO.

    I then made a PCB library component to represent the board -

    So now I am ready to go with making a PCB board (hopefully).

  • FLASH Chip Programmer

    Hacker40404/02/2015 at 02:45 0 comments

    I decided that at some stage I need to get some code into this project. I was previously thinking of using an atmega to load boot code to the CPU and then have the CPU boot to SD card.

    I am not so sure about using an atmega as a co-processor now that I have decide to use a larger Altera EPM570 CPLD (about 440 macro's).

    In any case I need something to get started without going to all the trouble of writing boot loaders.

    I decide to hunt around the house for some FLASH as I haven't purchased any.

    I found 3 x 32 pin PLCC FLASH chips. 2 were in old mother boards and one was in a CD ROM.

    The main board ones were 3.3 Volt only so they were no good to work with a 5 Volt CPU.

    The CD ROM one was 5 Volt but it was soldered in -

    So I put it (upside down) in an oven tray and heated it until it dropped off the circuit board.

    Then when I looked up the specs I found it has the worst of both worlds lol. It has write protection so you can't flash it like you would with older PROMS (just as if they were slow RAM) and also it has *no* Low Pin Count (LPC) interface so I have to use a full blow parallel interface to program it.

    I don't have a programmer so I started hunting around to something to expand pin count (like serial in parallel out shift registers) but no good. Then I though ... what about the old Xilinx XC9572XL development board. I could connect that to something ending in 'duino.

    As it turned out the the stupid adaptor (dam I hate strip board) that I made was perfect. When I made it, I added extra rows of connectors for different sized breakouts / adaptors. A ZIF socket fitted right in and I had a PLCC32 to DIP adaptor.

    The stack -

    The stack from bottom to top -

    • Xilinx XC9574XL development board (5 Volt tolerant 72 Macro's)
    • The stupid adaptor that I made to allow connecting CPLD to chips etc with jumper lnks.
    • ZIF Socket
    • PLCC32 to DIP adaptor
    • The target FLASH chip

    I though of perhaps making another adaptor to plug this whole contraption into an Arduino UNO but on second thoughts that could cause problems (Stack Overflow??).

    Just to see if I got all the connections right and the constraints file right I just quickly changed the old video-out VHDL to work with the FLASH.

    Here's what I got -

    The lines in the picture are because the FLASH chip is much smaller than the SRAM and doesn't have enough room for a full screen.

    Then I wrote some VHDL to use the CPLD board as a big shift register. The code is at the end of the log.

    It's actualy two shift registers. One is A0-A16 (128KB) + CE + OE + WE + Data out D0-D7.

    The second shift register is to read back data from D0-D7.

    It has 4 signals to go to the 'duino. Clock, Load, Data Out, Data In.

    I am only new to VHDL and I couldn't get LOAD to be asynchronous so it is synchronous to the rising edge of CLOCK. I also had trouble with the tri-state dat bus and I fixed that by using a dedicated 8 bit register.

    I am now writing the code for the 'duino to program it and I will update that when it works.

    VHDL -

    library IEEE;
    use IEEE.STD_LOGIC_1164.ALL;
    -- I couldn't get a asynchronious load to work so load ended up syncronised to the rising edge of S_CLOCK
    -- use process ...
    -- note shift register does NOT shift when S_LOAD is high
    -- S_CLOCK is rising edge triggered
    -- **read flash**
    -- serial input WE(1),OE(0),CE(0),-,-,-,A0-15
    -- raise S_LOAD, toggle S_CLOCK
    -- wait
    -- toggle S_CLOCK
    -- lower S_LOAD
    -- serial read D7 - D0
    -- **write flash**
    -- serial input WE(0),OE(1),CE(0),-,-,-,A0-15,D0-7
    -- raise S_LOAD, toggle S_CLOCK
    -- wait
    -- perhaps do a readback to confirm
    -- **erase flash** as above
    entity flash_prog is
        Port (
               -- FLASH pins
               CE      : out    STD_LOGIC; -- Chip Enable   output to FLASH, active low
                 OE      : out    STD_LOGIC; -- Output Enable output to FLASH, active low
                 WE      : out    STD_LOGIC; -- Write Enable  output to FLASH, active low
                 A       : out    STD_LOGIC_VECTOR (15 downto 0); -- Address bus output to FLASH
                 D       : inout  STD_LOGIC_VECTOR (7 downto 0); -- bi-directional Data bus to FLASH, controlled by OE
                 -- Serial...
    Read more »

View all 4 project logs

Enjoy this project?



Ricky Zhang wrote 06/06/2021 at 18:12 point

If you use 74166 Parallel-in, Serial-out bit shift chip, you can save a lot of pins in CPLD for accessing frame buffer from memory bus.

  Are you sure? yes | no

Eric Hertz wrote 05/17/2015 at 05:55 point

Wow, your documentation is impeccable. Nicely-done.

Recurring theme I noticed: 5V vs 3.3V... Not sure if you're aware of the 74AHC series logic-chips, but they handle 5V input when running on 3.3V... They call it "5V Tolerant Inputs." Output, on the 5V-side, on the other hand... that'll be 3.3V-TTL(CMOS?)-levels, but generally that's acceptable for 5V-TTL-level devices.

I've also heard of auto-directional-buffer-chips that have two separate power-supplies, but I can't give you a part-number. In General (MUCH DATED, here), these types of devices are slow due to their auto-directional nature...

You might also get away with voltage dividers ;)

  Are you sure? yes | no

Hacker404 wrote 05/17/2015 at 08:20 point

I thought my docs were rather slack. I have pics and code but I need to learn to drive some software for timing diagrams and graphs. ATM I am using javascript in a browser to make graphs. 

The CPLD's I have chosen are five volt tolerant but I am yet to see if they will work on home made PCB's as the noise margins from LVTTL to TTL are very small.

I have thought about using level translators but I am trying to keep the chip count down so I am hoping to avoid the extra chips.

The CPU is CMOS (the older versions was NMOS) but it has TTL level I/O. The HC/HCT/HCV is the same - the substrate is CMOS technology but the signal levels are TTL or LVTTL so they're a good match. There is a LVCMOS standard to but it is not often used as far as I know.

The CPLD I am using can work as a level translator but then I would have to connect it between the CPU and RAM/ROM and use a lot of pins on the CPLD. This may be the end result for a different reason. 

I have moved away from this project for a while and I am working on a TRS-80 clone. It has many of the same challenges but the CPU will be running at 2 MHz instead of the 20 MHz for this project, so I can bread board the TRS-80 project as a learning trial. 

One way to do this as far as the address and data buses are concerned:

RAM / ROM <=> Z80 <=> CPLD <=> Video RAM 

I am going to try this instead - 

z80 <=> CPLD <=> ROM / RAM (including video) so that I have only one RAM chip for both CPU and VGA. 

The problem is that the VGA (CPLD) will be accessing RAM at 25 or 50 MHz and the CPU will be accessing at 5 MHz so Video access will occur *during* the CPU access.

The TRS-80 has a very similar challenge, it needs a character ROM and I don't want to use two ROM chips so I will try to use some space in the boot FLASH for character ROM.

  Are you sure? yes | no

Eric Hertz wrote 05/18/2015 at 07:33 point

Sounds like you've done quite a bit already!

One thing I'm reminded of an old project I did using a (single-port) SRAM as display-memory... I had it running at the display-frequency, with a MUX on its address/data lines... on High-level clocks, the memory was used for the display-output, on low-level clocks reads/writes from the MCU occurred much slower... Since the MCU only actually accessed/wrote data on the edge of the clock, it was acceptable for the memory to be addressed *very* slowly (numerous MUX clock-cycles). This, of course, required multiplexing between the sequential display-output-address and the MCU's requested-R/W-address... so lots of MUXs... Also meant that sometimes the data-written would be invalid for a few clock-cycles as the MCU set up its data... but it worked :)

Lotsa muxing, and was one of my first TTL projects, so don't take this idea too seriously.

And if regular-RAM accesses occur during video-refresh, consider it "snow"... didn't IBM PC's have that issue? No biggie :)

Sounds like an interesting challenge, either way!

  Are you sure? yes | no

Hacker404 wrote 05/18/2015 at 08:20 point

I would be easier if the CPU was like a 6802 and had synchronised read and write cycles. Unfortunately the Z80 is completely asynchronous and on top of that it has variable length instructions. 

I have to find the 'windows' for the data bus for CPU read and write and latch the data so that the video can continue uninterrupted. 

The scheme you mentioned would work if the two buses were closer together in speed. The Z80 read cycle is 3 or 4 clocks as 20 MHz so it is effectively around 5 MHz. When the video is clocking as 25 MHz or 50 MHz there is bound to me an interruption to the data bus right when the Z80 is reading in the data so just MUXing wont work unless the Z80 has priority over the bus ie screen flicker. I hope to avoid this if I have enough pins on the CPLD.

I will be using a QFP100 CPLD and I don't want to go higher as the pin density increases and the chip becomes too hard to solder.

  Are you sure? yes | no

Eric Hertz wrote 05/18/2015 at 09:59 point

Sounds doable in the realm of logic. Never did get much into CPLDs. Curious to see how it turns out.

  Are you sure? yes | no

Michele Perla wrote 01/08/2015 at 11:47 point

Hey there, nice project and sweet features! I may suggest to switch to UV Exposure method for home PCB manufacturing, it gives better, reliable, and repeatable results. If you take a look at my project you can find an example of a UV exposure box made from scrap parts (except for the ballast and the lamps, of course). Cheers, Mick

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates