I guess my FPGA idea didn't sit all that well with you
?
Not so much that as the fact that I had already built the microcontroller version at that point. I still mean to get into FPGAs at some point, perhaps for eventually doing something similar with a 286.
How sure are you that the prefetch queue will be in the same exact state each time?
I halt the CPU (which stops prefetching) and wait for the timer interrupt (jumps, calls, returns and interrupts all clear out the queue). The trickier part is getting the same refresh DMAs to happen at the same times, which involves completely resetting timer 1 and DMA channel 0. In order to avoid DRAM decay during this process, I need to increase the timer 1 frequency temporarily to refresh all DRAM rows before halting and after restarting.
I'm currently not doing anything special to get the CPU into a known state with respect to the CGA clock - I think I can do this just by ensuring that timer channel 0 runs for a multiple of 4 timer cycles each iteration (there are 3 CGA clock cycles per 16 CPU cycles).
I'm guessing you could model your XT server program as three different basic blocks:
A- Whatever was executing before custom code was loaded
B- Reset the DMAC, PIT, etc
C- Your custom code, jumps back to B.
Yes, that's about right.
Given that C jumps back to B, can you prove that when we get back to the beginning of C, that the prefetch queue state (number of bytes filled and byte contents) and the execution unit state (current opcode/operand of an instruction being parsed, and the current cycle number within the current instruction being executed*) are the same every loop?
Yes, I think so (and it seems to be giving sensible results). There are a couple of ways of doing this - one is to empty the prefetch queue (with a control flow instruction) and the other is to fill it (with a long-running instruction like a MUL). I'm using the former method here as it kills two birds with one stone (the other being to get the CPU into a known state with respect to the PIT).
I would personally like to know when the EU decides to start grabbing bytes from the queue. Does it wait for a full instruction and grab one byte each cycle?
We can tell without sniffing that it can't wait for the full instruction to be in the prefetch queue, because the queue is only 4 bytes long and some instructions (even discounting prefixes) can be 6 bytes.
Looking at traces, it seems that the EU is capable of grabbing a byte from the queue each cycle, but does not always do so. For example, in the three-byte instruction "add ax,9999", the EU grabs the instruction byte on cycle 0 and the two immediate bytes on cycles 2 and 3. Looks like a mod/rm byte (if there is one) will be grabbed on cycle 1, though.
Does the EU take a byte immediately on the first cycle of the BIU starting to fetch the next byte?
Looking at a JMP instruction, we see a "queue is emptied" signal from the CPU. Let's call the cycle that happens on cycle 0. Immediately afterwards, the bus starts doing the prefetch for the destination address. That takes cycles 1 through 4 inclusive (bus states T1-T4). Then the bus starts prefetching the second code byte (i.e. destination+1), which takes cycles 5-8. The EU doesn't grab a byte from the prefetch queue until cycle 7 (the T3 state of the second prefetch). I'm not sure why it takes so long.
The BIU usually starts a new prefetch 1 cycle after a byte is grabbed from the queue (if the queue is full and a byte is grabbed on cycle 0 then cycle 1 will usually be a T1 state for the next prefetch). Exceptions I've seen so far: "POP rw", "POP segreg", "POPF" and "RET" (start bus cycle for the stack fetch on cycle 3), "IN AL, DX" and "IN AX, DX" (start bus cycle for port IO on cycle 3). In all these cases, the CPU knows from the opcode that it's going to need a fetch, has the address in a register, and knows which register from the opcode.
