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?

  • 4
    One important aspect about intercept and handle some codes specially is if the original system is using these instruction in a timed loop or not. In those days it was not uncommon to have loops that were carefully calibrated with extra or a bit strange instructions just so the loop time would be a specific number of micro seconds.
    – UncleBod
    Commented Feb 2, 2022 at 12:17
  • 2
    @UncleBod That was relatively common on mass-market systems - TRS-80, Apple ][. C64, etc. Not on most other (i.e., besides ZX80, TRS-80 I and III, etc.) 8080/8085/Z80 systems where speeds varied a lot by manufacturer and every machine was different (amount of RAM, CPU speed, type of floppy drive, terminal type, etc.) Commented Feb 2, 2022 at 13:24
  • 2
    Seems you would need to decode the control bus and the data bus, and when these instructions are received generate an external interrupt to catch this, handle this in software, then make sure that you can resume at the address following the trapped instructions. And you will need to make a choice: will you sacrifice two interrupts to handle this, or will you read the instruction into a register that can be read as an IO register in order to differentiate between the trapped instructions.
    – chthon
    Commented Feb 2, 2022 at 15:15
  • 3
    No time for a lengthy Answer, so short: Best way to decode taking M1 signal plus data bus then add a wait and issue an NMI whenever RIM/SIM comes along (if the system is int/nmi heavy additional complexity arises). Also keep in mind that these instructions are different assigned on the Z80 - not to mention the additional 8085 instructions that have been used back ten. Further issues to take into account is different timing of 16 bit operations, different flag handling and the additional interrupt pins of the 8085.
    – Raffzahn
    Commented Feb 2, 2022 at 17:09
  • 2
    I would normally use the term "emulating" for this approach, not "simulating" which I (and I think many people) would interpret as a non-realtime off-line operation. Commented Feb 2, 2022 at 18:44

2 Answers 2


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.

  • 2
    Couldn't have done it better. Especially teh poitn about inserting different instructions. It may be worth to add that some CP/M programs do check for Z80 present. Siliar, timing is in different in many more places, so one coudl go ahead and let the Z80 run at twice the systems speed and add one wait state to anymemory access, giving more time to react (or have the CPU run faster :))
    – Raffzahn
    Commented Feb 3, 2022 at 23:50
  • Good answer. Well worth adding that an internet search will show FPGA modules with 5 V-compatible DIL pins being available off the shelf, so OP knows you're not suggesting they have to make their own board. If you decide to edit that in, I'll delete this comment and upvote.
    – TonyM
    Commented Feb 4, 2022 at 2:09
  • 1
    @TonyM what do I search for to find one? Commented Feb 4, 2022 at 4:10
  • 1
    8085 also has some undocumented yet highly useful instructions like this: ee.iitb.ac.in/~sumantra/courses/up/undoc_8085.pdf One has no chance to emulate them on Z80, at least not in the simple way.
    – lvd
    Commented Feb 4, 2022 at 6:40
  • 1
    @lvd Has been topic on RC.SE as well: (Which undocumented 8085 instructions is Steven Morse referring to in "In The Beginning"? ) - givinga bit moredetail.
    – Raffzahn
    Commented Feb 4, 2022 at 22:55

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .