Single-Step Anomalies in the Don Russ Video
- If like me, you've been tormented by the single-step portion of Don's popular video on YouTube, I now have closure!
At issue is where the computer is single-stepped through the .bin loader code after it was entered via the front panel. This starts at 2:30 into the video. What's confusing is that the status lights are stuck on the instruction-fetch pattern the entire time he steps through the code. The loop looking for serial data is doing an i/o input (IN) from the serial board -- this instruction should generate two non-opcode-fetch cycles, and the jump at the end of the loop should generate two non-opcode-fetch cycles. Yet the status lights always show opcode fetch as if the computer was single stepping full instructions instead of machine cycles.
After looking more closely at the video, I noticed the memory being single stepped is not at 0x3f80 where the program was just entered. Instead, memory starting at 0x3f00 is being executed. Instead of settling into the simple three instruction loop that is the core of the .bin loader, the single step operations execute code from 0x3f00 all the way through 0x3f40.
By "single-stepping" the video, you can see the computer is single stepping through just a small variety of different opcodes, every one of which happens to be a one byte opcode that does not generate any additional bus cycles -- lots of register to register moves, register to register math operations, etc. When single stepping these opcodes, you will only see the instruction fetch status light pattern. If the real code had been executed, then the port read instruction would have generated two additional bus cycle types and the loop's jump instruction would have generated two non-opcode-fetch cycles. These other bus cycle types, in turn, would have generated different status light combinations as would have been expected for this program.