The RZX engine is based on recording the input information at the end of the frame together with the number of CPU instruction fetches that have been performed in that frame. When replaying, the emulator will read both the number of fetches to perform in the frame to be executed and the keyboard/joystick input, which will be valid for that number of instructions, and then will force an interrupt when the limit is reached. In very simple words, the RZX algorithm will say that the input data you read will be valid for a given number of instruction fetches; note that the fetch counter stepping is the same as the R register, i.e. it is incremented by 1 for single-opcode instructions and by 2 for double-opcode ones. The interrupt acknowledge cycle is NOT considered a regular instruction fetch, and thus it does not increment the fetch counter. This method ensures absolute compatibility between emulators, no matter how accurate they are. Besides, no rules are imposed concerning the way the emulator which records the RZX acquires and updates the keyboard and joystick data, since the RZX logic guarantees that the same input sequence will be perceived also by the playback application - and that's the only thing that actually matters.
The following diagrams show what the emulator should do in order to take advantage of the new recording format:
The actual input data recording is achieved by logging the result of all the I/O port reads performed by the CPU in a frame. During input recording, the RZX system records the values returned by the IN instructions executed by the CPU; when the RZX file is replayed, these values are given back to the CPU so that the port reads will return the same results as occurred during recording. The RZX design ensures that each IN instruction gets exactly the right value as expected.
This technique not only achieves input recording functionality, but it also solves many problems arising from the differences between emulators. The most important of these issues is the floating bus, i.e. the values fetched from the bus when a non-existent I/O port is read by the CPU. Other situations covered are tape and disk loading (e.g. with multiload games) and accesses to I/O devices in general. For example, any emulator can correctly replay an RZX file where the Kempston mouse and the lightgun have been used - no matter if it doesn't emulate these devices at all!
Critical rules
A faithful emulation of the Z80 is a basic requirement for the RZX engine to work properly. As you might imagine, the timings aspect is not important: we said that the RZX format doesn't care about that, neither contention nor exact instruction duration. A "proper" emulation must instead cover all known CPU aspects, both documented and undocumented: a missing flag alteration can result in a different branch of a program on some cases, thus leading to different behaviours when replaying a file on different emulators. A famous example is the rhino's behaviour in Sabre Wulf, as reported even in the Z80 emulator documentation - quoting:
"The rhino in Sabre Wulf walks backward or keeps running in little circles in a corner, if the (in this case undocumented) behaviour of the sign flag in the BIT instruction isn't right. I quote:
AD86 DD CB 06 7E BIT 7,(IX+6) AD8A F2 8F AD JP P,#AD8FAn amazing piece of code!"
This is a quite rare event: it usually happens when the handling routine enables interrupts immediately (or a few t-states) after it has been called. The INT retriggering probability varies between the various Spectrum models and clones depending on the INT signal duration and might hardly affect correct playback; a possible solution to avoid ambiguities could be to store the INT signal duration in the recording block header so that the emulator can handle it on its own. Unfortunately this is not enough when working on machines that have a different contention mechanism, for example the ZS Scorpion: in this case memory contention is applied at anytime and not only when building the video output, so delay can occur even around the frame-cross instant altering the retrigger probability. The only way to have a perfect trace of what has happened at record time is to insert a frame record even when a retrigger occurs.
Example: the Z80 is set on IM2, interrupts are enabled and emulator sets INT low for 48 T; the interrupt handler routine is a simple EI - RET.
T-STATES Instruction Cycle
=============================
- 70906: NOP (t0)
- 70907: * (t1)
INT signal goes LOW -> - 0: * (t2)
- 1: * (t3) <- INT is sampled here
- 2: INT acknowledgment: IFFs are reset
... (19 T-states for IM2)
- 21: EI (t0) <- the INT handler
- 22: * (t1) sets IFFs immediately
- 23: * (t2)
- 24: * (t3) <- INT is not sampled!
- 25: RET (t0)
- 26: * (t1)
...
- 34: * (t8)
- 35: * (t9) <- INT is resampled here!
- 37: INT acknowledgment IFFs are reset
... (again 19 T-states)
INT signal goes HIGH -> - 48: * <- 11th T-state of INTACK
...
- 56: EI (t0) <- INT handler restarts
- 57: * (t1)
- 58: * (t2)
- 59: * (t3) <- INT is not sampled!
- 60: RET (t0)
- 61: * (t1)
...
- 68: * (t8)
- 69: * (t9) <- INT is resampled here!
... Program continues normally
In this case the interrupt routine is called 2 times in a frame; it's obvious
that if the INT signal is low for 69 T-states or longer, the routine will be
triggered 3 times or more.
The RZX algorithm covers this particular case without any problem, and there's no need to include any information about the INT signal as every INT trigger will cause another record write in the file: for each possible branch in the program caused by an INT the algorithm will provide full information so that the emulator will reproduce the exact instruction sequence. If needed, emulators can detect INT-retriggered frames by checking whether the instruction counter is too small for a regular frame; for the Spectrum computers, we suggest to check for a counter value less or equal to 4.