RIP Z80

[nctnico]

Aha I did see that project but on a quick look didn't realise they actually put it in an FPGA.

The EP2C20F484C7 is GBP 102 and they are using 11% of it. The Spartan-6 6x1s16csg324-2 I could not find. The devkits all list as obsolete.

A Sipeed tang nano 9k (which uses a low cost FPGA from Gowin) should do it judging from the number of LEs / registers. These FPGAs are pretty cheap and have internal flash and memory so you can build a fully self-contained Z80 system with it. Actually, you can likely have a complete Z80 based home computer like the MSX-2 in a single FPGA..

[SiliconWizard]

A couple of rhetorical questions:

Can you fit the Z80 into a $5 (100+) FPGA?

Probably so yes. The T80 core is one of the most used for retro computing stuff, I have toyed with it a bit a few years ago, but it was on a Lattice ECP5 (which, while not expensive, isn't the cheapest FPGA around.) I don't remember how many LUTs it was taking up. But I can look it back up.

[peter-h]

I am familiar with FPGAs; in 1991-1996 I was doing lots of FPGA design consultancy, some where the FPGA was the end result and then some ASIC prototyping. I used XC3032, XC3064, XC3090, and then some big XC4000 chip (probably XC4062) which I can't remember and which was about £200 but the price didn't matter. The dev tools (Viewlogic/LCA and XACT5) came to £20k, including two dongles Today I have no need for using "FPGAs as FPGAs" since 168MHz+ ARM32 CPUs are so fast and the high level of integration avoids the traditional need for tons of logic. But obviously lots of applications remain otherwise these firms would be out of business.

I just wondered if someone could build a Z80 based system with an FPGA which is not ridiculously priced. It might run really fast, too, in the new devices.

[MarkL]

I thought this was an interesting board:

  http://www.s100computers.com/My%20System%20Pages/FPGA%20Z80%20SBC/FPGA%20Z80%20SBC.htm

Anyone have any experience with it?

[SiliconWizard]

Prices for FPGAs and their dev tools have obviously dropped dramatically since the 90's (except for the very high-end FPGAs which are absolute monsters).

I've looked back at my project, the T80 core was taking about 2700 LUT4s.
That would fit no problem in many entry-level FPGAs which cost just a few bucks.

https://opencores.org/projects/t80/

[PCB.Wiz]

Since you will still need an EPROM and an SRAM (for 64k address space you won't be using a 8GB DRAM module ) you still have a couple of tricky chips to source. EPROMs do exist, just about, FLASH chips definitely exist (but you need to design the PCB for in-circuit programming of a parallel FLASH chip - not trivial, lots of test points for a spring-loaded jig) and SRAMs also exist although only a few vendors nowadays.

That's the challenge, in all these FPGA variants : How far do you clone the original architectures ?
If you wanted to clone EPROM and SRAM, you likely also want 5V operation ?  That's even messier on modern FPGA's

If you just need 'binary compatible', does that need to be cycle precise, or is faster in a straight line ok ?


As you say, parallel memories are fading, but there are new QSPI SRAM parts that could work well with a FPGA core.
eg Microchip's recent QSPI 23LCV04M 4MBit can burst up to 143Mhz

[gnuarm]

DRAM refresh was built in, with a 7-bit counter output during the M1 cycles of an instruction read, but yeah, it was quite amazing what programmers could do with a few MHz in and 8-bit processor.

Yes, DRAM refresh was "built in" in that there was a counter and notification that it's safe to do a row refresh.

Not so great was that to get the timings into spec that the DRAM of the day required, a fair bit of fettling and empirical work with glue logic & RC networks was required to get the RAS/CAS and setup/hold timings to work within tolerances, particularly if you were doing a production run.

It became easier and cheaper to stick in static RAM as time proceeded, what with higher densities, substantially reduced glue logic, and dropping prices.

Controlling DRAM took quite a few chips in those days, yet the total logic involved was not that great. Zilog threw the refresh counter into the MPU, but left the rest out. I was always puzzled that nobody tried throwing the whole DRAM control thing into their MPU. Its not like getting the feature set right was a problem. From the earliest days practically all DRAMs were drop in replacements for each other, with a well defined path to the needs of future generations.

funny about the timing thing.  The machine cycle timing came originally from the 8008 in an 18 pin package.  Because of the small pin count, they muxed 8 pins as two clock cycles of upper and lower address and a third clock cycle for the data transfer.  This should have allowed a DRAM interface without any multiplexing logic (which is lots of pins). 

The 8080 used the same machine cycles, even though there were 24 pins for separate address and data buses.  I believe the Z80 also used the same machine cycles, if I'm not mistaken. 

I don't recall all that much compatibility between different brands of DRAM.  They mostly operated the same, but detail timings were often different as they tried to outperform each other.  Speed was a big deal at the time with both capacity and speed improving significantly each few months. 

Then they started using different interfaces, DDR and such.  One company got the standards organization to standardize their proprietary interface, RAMBUS, I think it was.  Then, everyone found RAMBUS wanted them to pay license fees!!!  The crap hit the fan, and everyone was held back until they could spin a new DDRx generation.  I think ultimately, RAMBUS didn't do so well. 

[gnuarm]

A couple of rhetorical questions:

Can you fit the Z80 into a $5 (100+) FPGA?

Probably so yes. The T80 core is one of the most used for retro computing stuff, I have toyed with it a bit a few years ago, but it was on a Lattice ECP5 (which, while not expensive, isn't the cheapest FPGA around.) I don't remember how many LUTs it was taking up. But I can look it back up.

The Lattice ICE stuff is much cheaper, but without some of the bells and whistles.  The BRAM is only x8 rather than x9 bits wide.  That ninth bit can be useful.  Heck, some of the Xilinx parts are pretty affordable too. 

I stopped using standard MCU cores some time back.  I roll my own, stack based CPUs.  They can be optimized to run pretty quickly, since the logic path is rather streamlined.  They are called MISC for Minimal Instruction Set Computers.  They can have opcodes as small as 4 bits.  This also helps to facilitate fast clock cycles, and use very low LUT counts.

[RoGeorge]

Classic Z80 was 40 pins DIL, with full 8 bit data bus and full 16 bit address bus, plus a few more lines for the control bus.


Has only a few registers, some of them doubled as an alternate set.


http://www.zilog.com/docs/z80/um0080.pdf

Less than 10 thousand transistors in total (8500).  No RAM and no EPROM internally, but could generate transparent refresh cycles in case the RAM was DRAM.  Otherwise, the CPU was entirely static.  Clock, at first was 2.5MHz, or 4MHz, sometimes 6MHz, but later it went faster.

The 4MHz ones were heaving some margin for overclocking. 
I've found a few 4MHz that were running stable at 7MHz, simply by binning the fastest one.  No extra cooling, though lowering the 5V for the entire system just a little, at about 4.7V, was helping with stability.

[peter-h]

The original Z80 was not static. The later CMOS versions were, starting the Nat Semi NSC800
https://www.cryptomuseum.com/spy/fs5000/files/NSC800.pdf

[Howardlong]

Less than 10 thousand transistors in total (8500).  No RAM and no EPROM internally, but could generate transparent refresh cycles in case the RAM was DRAM.

Transparent in terms of cycles. Not so "transparent" in terms of the glue logic and timing hacks required to satisfy the day's DRAM timings!

All it is is a counter that exposes itself on the address bus on the second half of an M1 cycle.

Of interest was that while the R register is exposed on the lower half of the address bus, the I register is exposed on A8-A15 when \RFSH is asserted. Despite not using DRAM, this undocumented feature was used by Sinclair in their ZX80 and/or ZX81 (I can't remember which one, it might have been both) as part of a crude CRTC: during the horizontal blanking period there was just enough time for a tiny bit of code to run that updated the I register appropriately. The auto-incrementing R register was used as the character count, and the I register as the character row scan count and the address in ROM of the character generator. The intricate details I've forgotten, but this was as a result of reverse engineering it when I was a spotty teenager. I remember calling Zilog to ask them if this was a supported feature, and the answer was "no".

[iMo]

Imho, the ice40up5k would be a nice target for a Z80 system (15kB bram and 128kB psram).
20MHz clock should be achievable..

[brucehoult]

Imho, the ice40up5k would be a nice target for a Z80 system (15kB bram and 128kB psram).
20MHz clock should be achievable..

20 MHz clock with original z80 4-20+ cycles per instruction? That's pretty awful.

There are RISC-V implementations that fit on ice40up5k and do single-cycle (32 bit!) execution at 24 MHz on straight line code, less than 2 CPI on typical branchy/loopy code e.g. 17 DMIPS (0.7/MHz, typical of result bypass but no branch prediction)

z80 does 0.042 DMIPS/MHz when compiled with modern SDCC.

[SiliconWizard]

Imho, the ice40up5k would be a nice target for a Z80 system (15kB bram and 128kB psram).
20MHz clock should be achievable..

Yeah. I've tried the T80 core on a Lattice ECP5 and timing was achieving over 50MHz. It's probably going to be lower on a iCE40UP. 20MHz should be achievable. I might test that when I get the time, just out of curiosity.
And it's probably possible to do better than the T80 in terms of implementation. It's just that it's a proven design.

[Picuino]

Z80 is the microcontroller of my first two computers (a CPM computer and a Spectrum), the first assembly language I learned and the first microprocessor I studied.
It has truly had a long life. This news makes those of my generation a little older.

[jzx]

Of interest was that while the R register is exposed on the lower half of the address bus, the I register is exposed on A8-A15 when \RFSH is asserted. Despite not using DRAM, this undocumented feature was used by Sinclair in their ZX80 and/or ZX81 (I can't remember which one, it might have been both) as part of a crude CRTC:

Both ZX80 and ZX81 use almost the same system, but the ZX81 uses also the NMI for "multitasking", that is, it can do at same time display and your program, the ZX80 only can do user program OR display.

They do not use the IR for adressring, they EXECUTE the video memory, literally, but the circuitry stoles the opcodes (characters actually) and subtitutes with NOPs, and while the refresh period, the external circuitry puts the character code (6 bits), and a scanline counter (3 bits) in the address bus, and the remaining high bits (7) are from the I register, and then a shift register load the video bits from the character generator in the ROM. Very convoluted.

But in the "new" High Resolution Graphics" mode, I and R are used as the bitmapped graphics address, because some people discovered that the address modification made by the ULA does not work on external memory, and allowed for something not oficially possible.

In the ZX80-ZX81 the R register is used as a sort of timer or watchdog. The A6 line is directly connected to INT, that seems very bizarre, but the Z80 checks INT while refreshing, this way in every line the video routines load R with an apropiate number and when the time has elapsed, cut the video routine.
You have in the ZX80/81 expansion slot both, A6 and INT, but they are shorted 

[jzx]

More details, (not by me )

https://web.archive.org/web/20201108114958/http://www.user.dccnet.com/wrigter/index_files/ZX%20Video%20Tutorial.htm

[obiwanjacobi]

C9

[iMo]

FYI

https://github.com/rejunity/z80-open-silicon

[iMo]

Imho, the ice40up5k would be a nice target for a Z80 system (15kB bram and 128kB psram).
20MHz clock should be achievable..

20 MHz clock with original z80 4-20+ cycles per instruction? That's pretty awful.

There are RISC-V implementations that fit on ice40up5k and do single-cycle (32 bit!) execution at 24 MHz on straight line code, less than 2 CPI on typical branchy/loopy code e.g. 17 DMIPS (0.7/MHz, typical of result bypass but no branch prediction)

z80 does 0.042 DMIPS/MHz when compiled with modern SDCC.

Yep, I ran here the "RudoIV" risc-v on the 40up5k/UPduino (the userland C bincode ran off the onchip 128kb spram loaded from the bitstream flash, yosys tools), and the max was 20-24MHz clock as I can remember.. The iCe40UP family is rather slow, a pity..

[bson]

FYI

https://github.com/rejunity/z80-open-silicon

That's really neat.  Especially if it can also run on 3.3V and be had as a naked QFN64!  That would allow for a SUPER compact little CP/M-80 SBC.

[Mike8080]

I wired up an S-100 Z-80 computer (Vector wiring pencil) WBW (way back when).  Memory was 4k x 1 dynamic RAM that I blowtorched off of some surplus boards that had their gold edge connectors sliced off to recycle the gold.  I could fit 32 of the chips on an S-100 board, so 16kbytes on each board.  Good times!

[SiliconWizard]

FYI

https://github.com/rejunity/z80-open-silicon

That's really neat.  Especially if it can also run on 3.3V and be had as a naked QFN64!  That would allow for a SUPER compact little CP/M-80 SBC.

Frankly, I still don't see much point, if you want to do that, compared to a soft core on a small FPGA.
And if you absolutely want a 'hard" core, then the Z180, which is largely compatible with the Z80, but improved, is still available, for instance at Digikey. It may not be a safe bet if you plan a high-volume series for years to come, as it's EOL, but there's still stock.

And if you just want to design a small CP/M 80 SBC just for the heck of it with no particular care for being 5V, nor being cycle-accurate, you can even just emulate it on a RP2040 for $1.
You have an example here (among a bunch actually): https://github.com/ExtremeElectronics/RC2040

[woofy]

The Z80 CPU - 1976 to 2024
https://youtu.be/cbMdq8Dsz6Y?si=Vs8dKGGsZVIWotgn

[bson]

Frankly, I still don't see much point, if you want to do that, compared to a soft core on a small FPGA.

It's just for fun, to remind myself of the bus timings, etc.  Any CMOS SMT version would work just as well.  I don't have any actual use for it.