Z80 writes on the bus

[tms9918]

I am trying to develop a debugger that interrupts the program flow by inserting rst instructions on the bus. I want to do it at the beginning of an instruction, i.e. I do not want to modify later parts of multi-byte opcodes / parameters of the opcodes.  Unless I solder additional wires (which I'd like to avoid) I have no access to M1.
My idea is to detect writes, and replace the data on the bus on the fist read after a write.
This holds correct only if there is no instruction that performs a read after a write. If I am not mistaken such instruction does not exist, but I may have overlooked some atypical case.
Is there any (possibly undocumented) instruction that performs a memory read after a memory write, or can I be sure that no such instruction exists?

[ChildOfCv]

I don't know of any instructions off hand, but what about instructions that only read?  Or perform internal math?  Neither of those will do a write, so your debugger would let them slip by.

 

Also, remember that some cartridge games use the RST vectors for reduced-byte calls.  Donkey Kong is one example.  If you try to claim one for your debugger, you will end up interfering with normal operation.

 

Typically, an emulator is the best solution for debugging.

[tms9918]

Yes, I am totally ok with instructions with no writes. I want to be able to stop the system and inspect it,without particular focus on the precise moment I stop it. I just do not want to introduce garbage (i.e. operands with wrong values).

I already use emulators extensively, the hardware solution is for inspecting parts of the system which are not documented.

[nanochess]

The easiest way to disconnect the Z80 from the bus is to use BUSRQ to zero. It will tri-state the whole addressing/control lines.

[ChildOfCv]

4 hours ago, nanochess said:

The easiest way to disconnect the Z80 from the bus is to use BUSRQ to zero. It will tri-state the whole addressing/control lines.

Yeah, if you don't care about the register contents of the Z80 and so on, this is by far the easiest way to pause the system to examine state, without interfering with anything.  There is an occasional hang that probably comes from having the NMI fire during the BUSRQ cycle though, if the game was just getting into what it thought was vertical retrace time and wasn't prepared for that.

 

Also, now that I think about it, M1 is available on the expansion port.

[tms9918]

Thank you everybody. Indeed, M1 is available!

Just for curiosity, I wrote a program that tests all opcodes (including the undocumented ones) and records the execution on a  ‎Z84C0010AEG‎
All the observed patterns are the following

[('rd',),
 ('rd', 'rd'),
 ('rd', 'rd', 'rd'),
 ('rd', 'rd', 'rd', 'rd'),
 ('rd', 'rd', 'rd', 'rd', 'rd'),
 ('rd', 'rd', 'rd', 'rd', 'rd', 'rd'),
 ('rd', 'rd', 'rd', 'rd', 'rd', 'wr'),
 ('rd', 'rd', 'rd', 'rd', 'wr'),
 ('rd', 'rd', 'rd', 'rd', 'wr', 'wr'),
 ('rd', 'rd', 'rd', 'wr'),
 ('rd', 'rd', 'rd', 'wr', 'wr'),
 ('rd', 'rd', 'wr'),
 ('rd', 'rd', 'wr', 'wr'),
 ('rd', 'wr'),
 ('rd', 'wr', 'wr')]

I attach the list of the instructions associated to each pattern for posterity.

summary.zip