The eZ80 (like the Z380) is binary compatible with the Z80 and Z180, but almost three times as fast as the original Z80 chip at the same clock frequency. The eZ80 has a three-stage pipeline. Available at up to 50 MHz (2004), the performance is comparable to a Z80 clocked at 150 MHz if fast memory is used (i.e. no wait states for opcode fetches, for data, or for I/O) or even higher in some applications (a 16-bit addition is 11 times as fast as in the original).
Says Wikipedia.
If I read the articles on WIkipedia, it sounds like eZ80 is much more suitable to replace Z80 than the other variants.
The internal peripherals take most of the io space between 00-FF. We would have to hack the string of instructions to remap addresses on the fly. Not worth it, really. Easier to make a Z80 FPGA core and use instead.
You could take a look to non zilog z80 compatible chips
And Z380?
I looks to me as the best option if you are not interested in FPGA's.
It seems to be produced still. I saw some late 2016 parts in stock at distributors.
Multiplication is not R800 compatible, I believe. And when you switch to the expanded mode you cannot go back into Z80 mode without a reset. Which is a minor inconvenience.
It is expensive though. New parts run for about US$20. At that price point an FPGA starts to look attractive.
Zilog benchmarks make the Z380 look so fast that I started doubting the benchmarks. But I think a Z380@18MHz would perform better than a 20MHz 386SX. Zilog claims were way more aggressive than that.
It had a C compiler made by Zilog, but it seems they stopped selling it. Maybe it was too buggy and not worth the effor to maintain. I was not able to find it not even to buy. But htey still support its original assembler.
The work Zilog did on the Z380 has some interesting hints on how to extend the architecture to 32-bits. In case of a new CPU design in an FPGA it looks like a good stating point. But as there is not need for Z380 compatibility in the MSX, I would tweak it a little. It has 4 banks of registers that are duplicated as in the Z80. This makes more sense in an embedded application where the software just allocate those to fixed tasks and would take a lot of FPGA resources. Also the there are some more complicated instructions that are questionable. I say that because the Z80 is already considerable more complex than a low end 32-bit Risc. The Z380 is even more so.
Also those more pipelined processors may cause some issues with self modifying code and, more importantly, the SLOT mechanism in the MSX. When you write to SLTSL port and jump we need to make sure none of those CPUs has actually pre-fetched the destination for the jump at the wrong SLOT. I do not thing that the Z380 is that sophisticated but the eZ80 may be.
Any FPGA design that is aiming for higher performance needs to take the SLOT mechanism and mapper paging into the processor core like it was an MMU to avoid those sorts of issues.
After a quick re-glance at the Z380 docs:
- on board peripherals accessible via seperate IO instructions (like Z280)
- /M1 signal not compatible with Z80 (like Z280)
Maybe some glue logic is needed to connect to Z80 based boards.
It seems there are no CPU/BUS speed multiplication options. So we probably need to keep the frequency at the low side (and/or add waitstates).
Relative performance figures:
Relative performance
Would be nice to test with...a bit of a challengesoldering that QFP 100 pin package....
Relative performance figures:
Relative performance
Would you know where the relative performance numbers came from? I have the impression that he Z380 is faster than that. Zilog has an app note that claims significantly better results and include source code. But it may be due to the fact that it takes advantage of 32-bit features.
Maybe some glue logic is needed to connect to Z80 based boards.
It seems there are no CPU/BUS speed multiplication options. So we probably need to keep the frequency at the low side (and/or add waitstates).
This is for certain. I think that to take advantage of a Z380 you need to implement the all the memory/slot stuff around the Z380 and only use the Z80 bus as a bridge to slower peripherals and cartridge slots. A little like the Turbo-R does. I would even move bios/basic/dos2...
padial did the z380 msx
Relative performance wrote:
Here is a link to the Z380 benchmarks made by Zilog:
Z380™ Benchmarking - Zilog
If you google "Z380 benchmark -zen -asus" it is the first link that appears to me.
it would be possible to make the board have a z80 @ 7 and the z280 @ 10 ?, and to request that the z280 not access the system memory, but his own (2MB for example).
MSX-> card with z80 @ 7 + z280 @ 10 + RAM
2 switches:
z280 on / off
if z280 = off then z80 @ 3 or 7