Single-stepping the Altair 8800

Question

I've just been watching a rather interesting series of videos about the MITS Altair 8800. It has a button on the front panel to single-step the CPU one instruction at a time... Except that, on closer inspection, that's not actually what it does. What it actually does is convince the CPU that there's bus contention, preventing it from executing the next bus cycle until you press the button. So an instruction might actually take multiple steps, or none at all. (Well, other than to fetch the opcode.)

That's a slightly strange way of doing things. I came away with the following hypothesis:

1. Big mainframes and minicomputers were explicitly designed from the start to allow instruction single-stepping, and made specific hardware design decisions to support this.

2. The cost-optimised Intel 8080 IC that powers the Altair was not designed to support single-stepping, so the people at MITS had to come up with a kludge to make a CPU "single step" when it wasn't really designed to support that.

Is that approximately right? It sounds plausible to me, but then, I'm just making stuff up, so maybe I'm completely mistaken...

Answer 1

It has a button on the front panel to single-step the CPU one instruction at a time... Except that, on closer inspection, that's not actually what it does.

Exactly, and it's not what the button is intended to do. The purpose is not to single step an instruction, but to single step a cycle.

That's a slightly strange way of doing things.

No, it's exactly what what is needed. For one, single stepping an instruction sounds nice for software developers, but less when it's about hardware, and that's what a CPU (and the Altair) is about. With cycle stepping the user is able to see every machine cycle and how the bus reacts displayed.

On a closer look, this is exactly what you want as well as a software developer. The Altair CPU is an extreme bare bone construction. Just the CPU itself, a clock generator, an 8 bit port and a bit of glue logic. These switches and LEDs are your interface to the machine. Your terminal and your debugger. And all debugging functions there are.

There is no monitor program

Looking close you won't find any button to read out a register (like on a mainframe) or modify them. All you can do is look at the content of a memory address, modify it, and single step the CPU. And that's exactly how you follow the execution of a program and examine its workings.

• First you see the address of the instruction fetched - go decode it from memory.

If the operation has parameters:

• You'll see address and value of all operands fetched (one byte per step) - remember it

If the instruction does some memory access:

• You'll see what address the CPU accesses and what values are read or stored.

If you remember all of this, your imagination will show you a debugger line of the instruction executed including all memory fetches and reads or writes. Cool, isn't it? And none of this would be visible if the button would be to single step on instruction level. All shown would be address and opcode of the next instruction to be executed.

Keep in mind, this computer operates at the lowest end possible. No software preloaded. Getting a PROM with some monitor program would have been an additional investment and another board to plug in - not to mention the need to buy a terminal of some sort.

Considering this it's amazing how much can be done by just looking at each cycle. And here also a major difference to mainframes is to be seen. Mainframes don't eat and execute instructions on a byte level, but fetch whole instructions and then execute them. In so far a mainframe works more like a RISC CPU than a classic microprocessor.

The cost-optimised Intel 8080 IC that powers the Altair was not designed to support single-stepping, so the people at MITS had to come up with a kludge to make a CPU "single step" when it wasn't really designed to support that.

No. As explained, MITS did use this to allow program development and debugging on a very low hardware level, without any software involvement and still be able to provide some information.

From the CPU's point of view it would have been no issue to implement single stepping on instruction level as well. All needed to provide this is using the M1 signal provided by the CPU instead of PSYNC (as the excerpt provided in manassehkatz' answer describes) to reset the single step flip-flop. Of course now, no useful information beside instruction address and opcode can be derived.

Answer 2

From the Altair 8800 Theory of Operation Manual & Schematics 1975:

The Single Step circuit consists of a dual single shot (IC M) for debounce and the SGL STP flip-flop (R-S type). When the machine is in a stopped mode, depressing the SS switch will set the SGL STP flip-flop. (The machine must be stopped for any of the front panel switches except RESET to be active.) This allows PRDY to go high. The machine will execute one machine cycle and PSYNC, on the next cycle, will reset the SGL STP flip-flop. This will pull PRDY low, stopping the machine.

I'm sure someone will come along with a far more detailed & complete explanation. But it looks to me like this was a useful side effect of other circuitry designed to tell the CPU to wait while DRAM refresh or other things were going on. End result - "cycle" rather than "instruction". But it works.

I suspect some of the confusion comes from the similar, but slightly different, operation of a software debugger. A software debugger can use any combination of virtualization, hardware assistance at some level (whether CPU-based or additional hardware) or even a simulator, or just some well-written software (i.e., that causes a return to the debugger program following each and every "real" instruction) to single-step through a program. A debugger, by its nature, works on full CPU instructions. It can't split them up because it is operating at a higher level (unless it is an extremely sophisticated simulation). But a hardware-level single-step process, like in the Altair, can function on machine cycles rather than CPU instructions. I think that could be extremely useful when debugging hardware problems, which in the new-at-the-time ecosystem of 8-bit microprocessors, probably happened quite a bit.

Answer 3

It seems unlikely to me that doing cycle-stepping rather than instruction-stepping was cost-related or a kludge. First, the logic to complete an instruction before doing something else is required anyway in order to handle interrupts since interrupts must always occur between instructions, not cycles. Second, the Motorola 6800, a CPU of the same generation and slightly lower transistor count (~5000 as opposed ~6000 for the 8080) did offer instruction-stepping (as seen in "Figure 13 - H̅A̅L̅T̅ and Single-instruction Execution for System Debug" in the data sheet); it did not offer cycle-steppping.

Nor does this seem a strange way of doing things; in fact it seems a more reasonable way of doing things. Raffzahn points out that this is more useful for hardware debugging (I can see how this would be better for checking that, e.g., address decoding logic is accessing the right device), but even leaving that aside it seems to me also to make software debugging easier when working from the front panel.

Playing around with this simulator I noticed that one of my more frequent errors was entering the wrong value into a location when loading a program. For example, at 0003h I might have meant to enter IN 33h (CB 33) but instead say I entered IN 32h (DB 32)

That simulator (incorrectly) single-steps instructions, rather than cycles, and so my debugging sequence ends up looking like:

Address     Data
0003        (previous value)        Before stepping into that instr
0005        (data read from port)   After stepping the IN 33h

The mistake isn't at all obvious here, though I might wonder why the port returned the "wrong" value. But if we were using a real 8800 (or a better simulator), stepping through in cycles would clearly show the problem:

Address     Data
0003        (previous value)        Before stepping into that instr
0004        DB                      Read of IN
0005        32                      Ah! Wrong port value!
3232        (data read from port)   What was read and whence, should I decide to continue.

Additional status lights provide further help showing what's going on as well. The MEMR (memory read), INP (input from port), M1 (instruction read cycle) and WO (read/write) indicators would all change during the above and would provide further confirmation that my code is (or is not) executing as I expect it to.

(There may actually be some errors in the details above, since I don't have handy an Altair 8800 or simulator that does stepping correctly. But I think this still gets the idea across.)