Making the most of the Micro - Brewing up a Z80

Discussions
1

Whilst this might sound like an early 1980s BBC TV computing programme, it’s actually a new retrocomputing project based around the Z80A.

I have spent 2 days tidying up my office/workroom and discovered that I am surrounded by dozens of microprocessor, microcontroller and FPGA dev-boards.

I have everything here from ARM to Z80 - with AVR, Gigatron, Lattice, MSP430, PIC, Propeller, STM32, Teensy and Xilinx in between.

The only thing I don’t have at hand is a real 6502, well not to my knowledge, only a simulation that runs on an ARM.

Enter the Z80.

My first exposure to microcomputers was in summer of 1978 when my high school acquired a Research Machines 380Z and part of a computers in schools educational grant. This was augmented in 1982 with a BBC Model B.

By 1981/82 several of the pupils had ZX81s and we held a computer club on Friday afternoons after school. I was hooked on Z80 and built an autonomous Turtle robot using the ZX81 pcb - powered by 4 C-size NiCads.

Skipping to my college days in 1984, a friend and I successfully built a wireless modem using an FM bug - and sent ZX81 program data about 30m (100ft) across the dorms courtyard.

So in this strange year, 37 years later, with some time on my hands, and craving for some mental gymnastics I thought I would have a go at another Z80 project.

At OSHCamp 2019, I picked up an RC2014 Micro kit.

Info here: RC2014 Micro « RC2014

This is a 4" x 2" double sided pcb that holds a cmos Z80, a 62256 RAM, a 27C512 ROM and a 68B50 UART.

It’s clocked at 7.3728 MHz and comes with BASIC, and a Small Computer Monitor (SCM) burned into the ROM. The SCM includes a line assembler and a disassembler.

Along edge of the board is a 40 way 0.1" SIL connector - which exposes most of the Z80 bus in a user friendly (breadboard and stripboard friendly) manner, inviting you to hack together some expansion board.

We have come a long way since my introduction to Z80 hand assembly in the summer of 1981. The logical thing to do would be to use modern technology to make this board easy to program, tethering it to a PC or other non-volatile stoage means for program development.

The CMOS Z80 has an 8-bit data bus and a 16 bit address bus - all at 5V logic levels. It should be possible to use a modern device to take over the Z80 bus and deposit code into its RAM. This used to be called a ROM Emulator - or ROMulator.

Unfortunately, as time progresses, there are a lot fewer 5V tolerant devices available:- AVR, early Teensy’s, some PICS and STM32 ARM devices.

I like the ATmega1284p because it comes in a chunky 40 pin DIL, it has four neatly arranged 8-bit ports, 128K bytes of ROM, 16K of RAM and is Arduino IDE compatible. As well as UART, SPI, ADC, I2C, GPIO and other modern peripherals, it could make an ideal ROMulator and peripheral support device for the venerable Z80.

Back in the 1980s, the Z80 home micros were often hampered with having to spend a lot of time servicing the video display, only computing during line and field blanking intervals. If you relieve them of this graphics generation burden and run them at 10MHz, then hopefully performance will be reasonable.

This will be an ongoing project, so expect updates in the near future.

5 Likes
2

The same could be said for modern CPU’s, Get rid of the 1024x780 32 bit display…
Had a nice S100 kit with a z80 but never got full memory or a floppy for it. Got a nice surplus keyboard, I don’t miss the z80 but I miss the keyboard. None of this 50 thousand hot keys for Windows XYZ crap, but with the CTRL ,SHIFT, ENTER keys in the correct places and ASCII output,
Ben,

3

Hijacking the bus…

There are already several projects similar to this, where a modern device has been used to takeover the microprocessor bus, manipulate the address and data buses and a few control lines, and force data into the RAM chip(s). I have recently seen examples for both the 65C02 and the Z80.

I would like my “ROMulator” to be 5V TTL compatible, and preferably make use of through-hole components - in keeping with the RC2014 ethos, so the low cost Atmel/Microchip ATmega1284p in 40 pin DIL package seems to be a reasonable choice. It’s Arduino compatible and readily available.

However, I am loathed to devote 16 GPIO output lines to servicing the address bus alone, so I am thinking of either a 16-bit counter made from four 74HCT161 counters or a pair of serial-in, parallel out, 8-bit shift registers - such as the ubiquitous 74HCT595 driven from the SPI interface, might be an alternative solution.

It’s a bit of a no-brainer actually… the 74HCT595 can be tristated from the address bus, and if I only want to write 256 bytes starting at some random address, I have full fexibilty in software to do that.

The data bus will be wired to the 8-bit Port A. A bidirectional buffer 74HCT245 could be used to ensure that the data bus can be isolated from the ROMulator port.

At the same time the ATmega1284p can be used to provide SPI, UART, I2C, GPIO, timer and memory peripherals for the Z80.

It would be nice to remove the old 68B50 UART from the design - those things must be getting obsolete these days.

1 Like
4

A generic text video display chip, would nice too, for VGA.

1 Like
5

Missing a big trick here…

No need to drive the address bus externally with tristate shift registers.

Put a NOP on the data bus, toggle the clock and the Z80s PC will force the address bus to the next address in memory. Write the data to the memory, rinse and repeat.

Without this need to drive the address bus externally, it would allow a smaller pin-count AVR to be used in the Romulator.

1 Like
6

In the last couple of posts, I have perhaps incorrectly used the term “ROM Emulator”.

A ROM emulator, is an external device, often with a flying ribbon cable and DIL format plug, that plugs into the ROM socket of a target machine. It takes the place of the ROM, and can emulate its operation at full bus speed, with the memory contents being supplied from static RAM.

This approach made it possible to independently change the memory contents of the target system, for program development, and once the code was finalised and correct, it could be blown into an EPROM.

One of the very popular ROM emulators from about 20 years ago was the Softy S4 by Dataman Designs.

https://www.dataman.com/mwdownloads/download/link/id/36/

One advantage of a ROM emulator is that can be easily re-plugged from one design to another and makes a useful programming and debug tool.

As far as the target cpu is concerned, it looks just like a ROM.

There are other techniques which can be more hardware efficient, but these rely on the external device taking control of the cpu bus and memory control signals.

Using /RESET

On the Z80, this can be done by asserting the RESET line low, which puts the address bus, data bus and control signals into a high impedance state for the duration of the reset pulse. With the buses at high impedance they can be externally manipulated allowing the system RAM to be loaded with a new code image. Once RESET is released, the target cpu will start executing code from the reset vector address, which is location 0 on the Z80.

To do this effectively, the microcontroller will need close to 30 GPIO lines to control the buses and load the RAM. As well as address and data buses, it will need connections to /RES, /RD, /WR and /MREQ.

Using a NOP Generator

The second approach is subtley different, but ultimately it serves the same purpose, of independently being able to load new code images into the memory of the target device.

Instead of using the reset signal to force the buses into high-impedance mode, it uses a trick to get the target cpu to increment the address bus by forcing a NOP instruction onto the bus. This method was used in the ZX80 video generation circuit - explained here by Grant Searle.

http://searle.x10host.com/zx80/zx80.html

ROM Emulator versus RAM Loader

Here are the main differences between ROM Emulation and RAM Loading:

  1. The target system has no conventional ROM chip. The memory map is populated by static RAM, which has to be loaded from the external means on powerup.

  2. The external “RAM Loader” copies the contents of the microcontroller flash ROM, into the target’s RAM. This is done by external manipulation of the data bus, the cpu control signals, and forcing the cpu to sequentialy advance it’s address bus so that the data can be written to the RAM.

  3. Once the RAM has been loaded, the cpu can be reset and begin normal code execution from RAM.

  4. The external microcontroller is then free to be redeployed as a set of programmable system peripherals, including GPIO, UART, Timers, SPI, I2C and uSDCard interface.

This approach can be extremely efficient in hardware allowing a complete Z80 system to be completed in as few as 4 chips.

Of course a similar approach could be applied to any of the other classic microprocessors including 6502, 6809 etc.

1 Like
7

Yes, there are several options here.

  1. Parallax Propeller
  2. BT815 “EVE” chip as used on the Gameduino series of products
  3. VGA generation using STM32 ARM M4 or M7
  4. Video generation using Raspery Pi zero or PICO
  5. Use a small FPGA

Most of these will require some degree of voltage level shifting to handle the 5V signal levels of the cmos Z80.

However, the Z84C00 cmos Z80 is available in a 20MHz version. This makes it 5 times the speed of the old Z80A. We also have the advantage of much larger and much faster access time RAM, compared to 30 years ago.

It might be possible to exploit the NOP instruction to increment the PC, and the address bus at a 5MHz rate - as a NOP takes 4 clock cycles. This could be used to access the video RAM and with an 8 bit-shift register could put up to 128 characters along the video line.

1 Like
8

The dominant operating system for Z80 is CP/M, so Z80 computers almost always have a mass storage device such as CF disk. For RAM-only system, system software can be stored in first track of the CF disk; a small ROM embedded in CPLD can copy it into RAM and execute. Thus a compact 4-chip solution consists of Z80+RAM+CPLD+CFdisk, ZRCC.

Edit, Alternative to embedded ROM in CPLD but still using CF disk for bootstrapping is a state machine that initializes the CF disk to read the master boot record and execute the 512-byte data as they stream out of the CF disk. This is a truly ROM-less system.
https://www.retrobrewcomputers.org/doku.php?id=builderpages:plasmo:z280rc

9

CP/M lacks directories, which were emulated with disk juggling in the CP/M era. I miss that a lot in emulators or modern builds which put all drives on one big medium.

Maybe someday I’ll try to use one removable SPI flash per drive.
But my to do list is long, probably has ™dark energy inside™. SIGH!