Simulating a 8085 using a Z80?

Question

I am studying the replacement of a 8085 with a Z80 (I am aware that they are not pin-compatible, the solution is to be made in a board of new design rather than on the old board). The sole reason is to reduce components whose production has ceased. Still, my goal is to be able to be compatible with hardware and software targetted at the old system.

Would it be feasible?

I imagine the extended interrupt shall be replicated externally, but I don't know how to proceed with instructions 0x20 and 0x30 (RIM, SIM). Is there a way in which I could "intercept" opcodes and conditonally fed them into the Z80?

Answer 1

my goal is to be able to be compatible with hardware and software targetted at the old system.

Would it be feasible?

Depends on the architecture of the target system and how compatible you want to be.

I don't know how to proceed with instructions 0x20 and 0x30 (RIM, SIM). Is there a way in which I could "intercept" opcodes and conditonally fed them into the Z80?

You could detect those opcodes by snooping the data bus while /M1 and /RD are active. When a RIM or SIM opcode is detected, switch the opcode to a different one using a mux between the data bus and Z80. This can't be done until the data bus stabilizes, but must be done before the end of the memory read operation (end of T2) or the Z80 will read and execute the original opcode (which is JR NZ for RIM and JR NC for SIM). If you need more time you could assert /WAIT to stretch the read cycle, but this must be done by the middle (trailing edge) of T2.

Your circuit could then feed more instruction bytes into the Z80 to make it do what you want (eg. JP to some code that emulates the RIM/SIM instruction) or send it a HALT instruction and then activate NMI to force a non-maskable interrupt.

This is bound to create some timing differences. Depending on the machine's architecture it might affect bus timing in a way that upsets other things such as the video display or DRAM refresh, or conflict with the existing interrupt system. The 8085 also has more hardware interrupt inputs that might need a different circuit and software for the Z80.

The emulated instructions will take much longer, which could be a problem for code that needs cycle accuracy (eg. tape read/write, bit-banged serial port) or execution within a maximum time frame (interrupt handlers etc.). The Z80 has different instruction timings and some flags are set differently, which could create more compatibility issues. Finally the 8085 has some undocumented instructions that some programs might be using, or they might have tricky code that relies on the CPU executing unimplemented instructions in a certain way (unlikely, but you never know...).

For these reasons I think that while handling RIM and SIM may be 'feasible', it probably won't be worth the effort unless the machine's hardware and software is unsophisticated and very tolerant of timing differences. 'Vanilla' CP/M code with only 8080 instructions would probably be fine, but for that you could just use the Z80 as is and patch the OS to handle the different instructions (perhaps by replacing RIM and SIM with RST instructions).

The sole reason is to reduce components whose production has ceased.

Doesn't seem like a very sensible reason. 'New Old Stock' and reclaimed 8085s are still available for those few boards that might need them. If you are thinking of producing new boards then you could use an FPGA with 8085 CPU core, which could be made 100% compatible as well as having enhancements. Programmable logic is the way forward for replacing out of production chips. On the other hand people who don't want their retro hardware 'sullied' by modern products probably want an original processor as well.

Answer 2

There are a bunch of problems you hit having gone the other way with an 8085 CPU board for a Z80 designed hardware bus.

• As well as RIM and SIM there are a bunch of originally undocumented 8085 instructions that many things used (even some compiler tools)

• The 8085 has multiple priority interrupt lines with a mix of edge and level triggers as well as the 8080 style INT. The Z80 has only the 8080 style interrupt, two modes of its own (IM1 and IM2) and NMI. Thus many 8085 systems would actually need a Z80 and a full on interrupt controller and a bunch of new interrupt code

• The 80C85 is 3v3 capable, the Z80 is not (some Z180 variants are)

• There are a bunch of signal level timing differences aside from the bus being multiplexed on the 8085 and not the Z80. Above that there are significant timing differences at the instruction level and interrupt service level.

• Various 8085 signals are simply missing or different on the Z80. If you happen to need S0/S1/IOM you'll have to synthesize them from IORQ/MREQ/M1 and the timings will differ there too. It's not just the two bitbang ports.

When you look at prices if you need to replace a board running 8085 software and the 8085 software replacement cost is too high you may well be better off emulating it on a modern two dollar or less part with a load of GPIO lines for the "bus". Your board will be dramatically smaller, your power consumption go way down and even with a few 5v shifters if needed your BOM is almost certain to be vastly lower.

In fact depending upon the rest of the system I would not be surprised if it was cheaper to throw out all the other legacy hardware and replace the lot with a few modern highly integrated parts

Also note that for low volume applications of this nature there are (or were) licensable FPGA 80C85 cores that are clock perfect.