Have to change my approach, perhaps using invariant (table of full instruction chrono versus reality), validate instruction timing before trying validating IO_ACK interrupts. Write one table from plustest.dsk's testbench launched on WinAPE, and table from original Z80 documentation, and deduce the table of latencies. I have to trust first in my instruction timing tables (and have to write them both completely...)
Prefixed instruction has seems having only one M1 ?: Z80 doc show that a prefixed instruction take 4T more time.
Is IO_ACK itself a separated instruction ? I think no, it's a hack of a current instruction, adding two autowait and making its business during this inserted times.
IO_ACK offset into INT (interrupt) should not implicated by WAIT_n generator, and it seems that a WAIT_n during T2 is ignored because of autowait already inserted at this moment... for synchronizing an IO_ACK, I have normaly to insert WAIT_n during T2+2. No way, instruction itself is synchronized, so IO_ACK is synchronized also, you don't have to insert WAIT_n during T2+2.
http://www.cpcwiki.eu/forum/emulators/cpc-z80-timing/ : ~ a WAIT_n does not use RAM access, so does not slow down a "CPC instruction" (hypothesis) - but what about an IO_ACK during NOP in this case ?
In doc, IO_ACK begin after T2, during the two autowait inserted. So no way to detect that an instruction is IO_WAITing before slowing it following "slow down" instruction timing table.
http://www.cpcwiki.eu/forum/programming/cpc-z80-commands-and-how-long-they-take/30/
So, it's more correct to not think of it stretching the M cycle, but instead not starting the next one that requires
a memory access until the 4th cycle.
If you think of it like this, it also explains the weird exception that happens for interrupt handling.
Normally, responding to an interrupt adds 1us on the CPC. That's because it actually just adds 2 T states for the interrupt
acknowledge before the next instruction fetch. However, in case where the last M cycle takes 6 T states, the interrupt
acknowledge doesn't delay the instruction prefetch and so the usual 1us delay doesn't occur.
"Simples!" - ralferoo
So you slow down instructions following a slowing down instruction table, slowing it the less you can, and then IO_ACK comes or not, and then you synchronize next M1 putting WAIT_n during T2 modulo 4. IO_ACK two autowaits are not prolongated.
=== Test of a real Zilog 80 ===