So one difference between my board and a real Imsai 8080 is, well, I'm not using an 8080! I'm using a Z80, which is mostly code compatible. One difference though is that the Z80 designers re-purposed some unused opcodes to add a lot of new instructions to the Z80. They did this by using those opcodes as prefixes to multi-byte opcodes.

I didn't think this would affect anything, but it turns out the bus signals seem identical whether fetching the first or second byte of one of these instructions.

Why does this matter? Suppose you want to examine memory. This is done by forcing a JMP (0xC3) onto the data bus, followed by the desired address (which appear as operands to the JMP instruction). Obviously you don't want to do this in the middle of an instruction decode/execute, so I wait until M1, MREQ and RD are all active (meaning an opcode fetch is in progress). But this could well be the second byte of a multi-byte opcode fetch, which would be a problem.

Handling this has taken a few days of thinking, hit-and-miss, trial and error. It's slippery. Not only while stepping or ticking the clock, but also if the Z80 is free-running and then we stop it, we have no idea what just happened, and if a multi-byte opcode fetch may have been started.

My solution is to change the prompt -- from ">" to "(>)" -- whenever it can't be determined that it's safe to tinker with the bus.

--------------------------------------

LONG DETAILED EXAMPLE [comments in brackets]