Now begins the long slog of making the core cycle-exact.
You might think running the microcode successfully would give you a cycle-exact emulator, but not necessarily.
You still have to model the various cycle timing details in decoding, prefix handling, EA calculation, and potential bus-gated microcode operations.
The V20's read displacement timings are funky.
This is going to make for an interesting article contrasting the BIU timings between 8088 and V20.
The V20 appears to have some pipelining going on, which is fun. The EU can continue in some cases while a bus request is in progress, whereas on the 8088 it would always stall.
Here's a cool optimization on the V20 I'm calling write forwarding.
I can call it whatever I want. If you want to call microcode stuff something then decode your own microcode.
This is from the MOVSW instruction:
0A51: SI -> DP --- EC=MR
0A52: SIGMA -> SI DI -> tmpB --- ALU ADD, tmpC
0A53: DI -> DP --E EC=MW, SR=ES
The V20 has a register, OPR, which holds the results of bus operations. Duh. But notice here, there's no OPR. That's odd.
What's happening is that we can pipeline the bus requests. EC=MR requests a read operation from the BIU and before it even starts EC=MW requests a write.
So where the hell is OPR? Well the key is we don't actually need the value. MOVSW just copies it blindly.
So as best as I can tell, if you queue a read and a write back to back the result of the read just goes right back out the write, automatically.
write forwarding. fuck yeah.
This is the secret sauce for how the V20 keeps the bus full with string operations while the 8088 sits there peeing on its hands for 6 cycles per iteration. It's pipelining the address calculations.
NEC you freaky.
WR typically has to calculate an address for the write and that incurs a delay.
But if you've already resolved IND and OPR, it appears as if that resolves the pending write address and the V20 can just yeet it immediately.
the JCXZ instruction jumps if CX is 0.
my test set for JCXZ never sets CX to 0. Whoopsie.
Oct 12, 2026, 10:31 PM@gloriouscow Similar-in-spirit trick for Sentinel's microcode: https://codeberg.org/cr1901/sentinel/src/branch/main/src/sentinel_cpu/microcode.asm#L311-L314
I have the current shifted value at the output of the ALU and a shift count at the input of the ALU. I send the shift value to the ALU input as the decremented shift count reaches the ALU output. I repeat this in a loop until the shift count goes to zero. That way, I'm shifting and counting the number of shifts in lockstep using a single ALU resource :D.