Z80 Retro Musings

Finding my old MPF-1 Z80 trainer system has got me thinking again about the machines from that 8-bit era.

The Z80 and the 6502 were the “go to solution” for most of the home micros of the 1978-1984 time period.

I grew up with a RM-380Z, various Sinclair machines, a Jupiter Ace, and a Tatung Einstein (cp/m machine). Almost all were bought at the end of their life-cycle - because I was a poor student in those days.

The Z80 was sometimes used because it gave direct access to cp/m - but on the Sinclair and later Amstrad machines, it was popular because it allowed DRAM to be refreshed with almost no additional hardware - leading to very economical designs.

This makes me wonder if there is any unexplored territory in some of these Z80 designs.

In recent years there have been some recreations of early Z80 machines - Tynemouth Software produces a pcb and kit for a Sinclair ZX80 replicant - called the Minstrel.

Grant Searle has done a lot to popularise the Z80 with his 7-chip minimum solution, and Spencer Owen with his RC2014 kit is now the world’s leading supplier of Z80 based systems!

So this got me thinking about revisiting the Z80 hardware - and whether something new could be done.

Many of the early Sinclair machines used a lot of Z80 machine cycles to create the video display, in TTL with the ZX80, and then with various Ferranti ULAs in the ZX81 and Spectrum.

Decoupling the Z80 from the overhead of updating the display could make for quite a powerful machine.

(At least) Two ideas spring to mind:

Use a FT810 - as used in James Bowman’s Gameduino 3, and offload the video generation to it - so the Z80 can get on with real work. James and I experimented with a slightly overclocked FT810 that would produce a 1024 x 768 display, connected to a SH VGA display using resistor ladder networks (The FT810 was originally intended to drive a parallel RGB LCD). The Z80 just has to send a list of objects to display and the FT810 does all the pixel pushing. The only fly in the ointment is that the FT810 needs an SPI interface - but this could be bodged onto a Z80 with a couple of parallel to serial shift registers.

The second idea is to use a Propeller P1 for video and audio generation, and possibly even memory decoding too. A Propeller P1 could become a smart peripheral to a Z80 and provide a bunch of modern peripherals such as SD card interface, audio, video, PS/2 keyboard and mouse - and possibly some form of paged memory management. In theory you could have a Z80 colour computer in about 4 or 5 chips - all of them breadboard friendly DIL packages.

The third idea is to look at the eZ80 range of processors. These are an enhanced pipelined Z80 with modern peripherals and a 24 bit address range. They feature a pipeline that eliminates the 4 clock per instruction limitation of the original Z80, and they clock along at 50MHz. So a Z80 system with 16M bytes of RAM becomes a distinct possibility.

From there on there are Z80 soft cores running on FPGAs at hundreds of MHz, or emulated on an ARM M4 or M7 on a $20 devboard.

Richard Russell wrote and supports a BBC BASIC for the Z80 - which has been around for almost 40 years.

Plenty of ideas - and plenty of time to get on with some of them.


I thought that the ULA in the Spectrum didn’t take up any Z80 cycles like in the ZX81. It does slow down the processor’s access to the shared memory, of course.

Quite a few Z80 micros and videogames used a TMS9918 video chip (or something based on it). In that case the processor and video had separate memories.

Understood - but the cpu still has to push pixels to the display memory.

With the FT810, the cpu only has to send a display list of what it wants to display - and this can be very low bandwidth - approximately 10K baud. The FT810 handles all the pixel pushing - so the host cpu does not have to.

With the 32 sprites there are less pixels for the cpu to push around to get things to move on the screen.

Some of the most classic accelerated video controllers were:

Slightly less retro was the 34010 from Texas Instruments which was a full processor that had bit addressing.

1 Like

Is this the sort of idea you are thinking of?
PropIO V2 or

There’s also a Propeller based graphics card for RC2014 bus.

Mahjongg has been working on a similar idea the RhoCoCo.

Or possibly combine these ideas with a Propeller Z80 emulation?

1 Like

great and inspiring post and useful links, thanks! I want to build a Vectrex console from awhile, it’s inspiring to see other people find a way to do their “hardware dreams” came to the reality :smiley:


Your post mentions z80 FPGA soft cores, so I thought I’d take this chance to plug one that I wrote recently: https://github.com/scottlbaker/x820


Thanks for the link to your work Scott - I’m sure we can find a use for a 50MHz Z80 !

1 Like

My first post. I enjoyed the musing on Z80. It put into words my retrocomputer activities of last couple years. My efforts were indeed finding new ways to design the old computers. Some new ways are possible due to immensely cheaper PC boards and much better board design tools, some are from using CPLD of 1990’s, and some are just new insights and newly acquired knowledge in how to use the old computer.

My entire career was in embedded computers for hard real-time environments so I was not involved in designing for commercial desktop/operating systems of last 40 years. In my retirement I want to retrace some of the computer revolution that I’ve missed and re-invent retro computers with more modern tools and mindset. So yes, I am revisiting the Z80, Z280, 680x0 to see whether something new could be done.

Of course there are many new ways to do the old computers and I will not live long enough to explore a significant portion of the new ways. I have spent 2 years just working on different ways of bootstrapping old computers, designing with DRAM, finally get to play with CP/M, and start exploring video & keyboard.

I’ve found bootstrapping retro processors using CPLD full of interesting new possibilities.

  • Z280’s native serial bootstrap function is inspirational. I ported that function into a small CPLD (Altera EPM7064S & 7128S) and designed a generic platform to serially bootstrap 8-bit processors of 1970’s & 1980’s.
  • 68000 needs 2 EPROM to boot, but a DMA bootstrap scheme can load program from serial EEPROM into DRAM to boot 68000, thus enabling small formfactor 680x0 SBC.
  • CF flash disk can serve as bootstrap PROM if it can be initialized with a simple state machine.
  • CPLD can serve as a small bootstrap ROM, about 64 bytes, by programming the combinatorial logic fabric as lookup table. Enough to load program from serial port, compact flash, and other devices.

I don’t think I’ve explored significant fraction of the bootstrap ideas, but I do need to move on to other explorations.


Welcome, Bill! Some very nice thoughts there. The bootstrapping problem has long been a tricky one for retro-builders - programming an EPROM seems an extra step, an awkward one, and worth side-stepping if possible.

1 Like

64 bytes?
That would be in the range of a diode matrix as boot ROM which wouldn’t need a programmer for other foreign technology.


Even with the CPLD, you would need some banking tech, ostensibly, to bank out the 64 byte boot piece, unless you’re content with reloading it everytime you hit reset. The “always start at $0000” of the Z80 vs “start at vector located at $FFFC” of the 6502 is a nit. The 6502 way is simpler, I feel. While in theory it doesn’t matter, seems that it’s nicer to have RAM at $0000 than ROM or deal with a banking thing. CP/M requires some banking tech, since it expects RAM at $0000.

You are correct, CPM needs RAM at 0x0, so the 64-byte ROM needs to switch out by accessing an i/o location that changes the state of a flip flop which then disable the ROM.

A few day ago I was helping a user debugging a non-working Z280 board that has a EPM7128S CPLD as glue logic and 2 meg DRAM as memory. It turned out the DRAM data lines were not all hooked out, so the only working components are Z280 and CPLD. So I relied on programming various ROM programs in CPLD to debug the system. I have found I’m able to put 128 bytes ROM code plus DRAM controller plus random logic in a 128-macrocell CPLD that only used 77% of CPLD resource. Putting 128 bytes (or 1024 bits) in 128-macrocell CPLD is counter-intuitive, I wouldn’t have believed it until I’ve tried it.