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...

  • I have no clue here, but would be interested in some elaboration of your first point -- what are these design decisions enabling single-stepping in hardware? Jan 31, 2019 at 23:08
  • As a one time owner of an original production run Altair 8800 kit, there's a class of programs you can enter in from the front panel where single stepping is useful for debugging. altairclone.com/downloads/manuals/… Page 41, E. Operating Hints, 3. Debugging Programs.
    – user9041
    Jan 31, 2019 at 23:37
  • 1
    @FelixPalmen Simply the addition of a front panel allowing to read and set all registers, PC and machine status register, as well as read and write all memory (on word level) and finally single stepping on an instruction level. All of this done on a hardware level, so without the interferance of any software monitor program (as what is used on microcomputers). These panels were an integral part of the CPU itself.
    – Raffzahn
    Feb 1, 2019 at 2:19
  • I think this is quite a common thing, the 68000 requires a constant clock signal, but it allows for asynchronous bus communication: it waits for the addressed peripheral (e.g. RAM, DUART) to pull a line called DTACK low once the data to be access has been placed on the data bus. Single stepping therefore requires you to control the DTACK line, keeping it high until you want it to step, then use a one-shot circuit to pull it low for a clock cycle, allowing the CPU to continue on to the next instruction but no further.
    – Matt Lacey
    Feb 1, 2019 at 5:17
  • 2
    @MathematicalOrchid Erm yes and no. A front panel of a mainframe is direct wired into the CPU. it's part of the CPU and connected with hundrets of wires direct to each part it accesses. Not realy possible on a micro. Ofc, a boundary scan system, like the JTAG TAP in use nowadays, could have been implemented to export information from the CPU while halted, like a mainframe but with less wireing - except the TAP would have been as complex as the 8080 (or any other early CPU) itself. So micros went without and it continued that way until today.
    – Raffzahn
    Feb 1, 2019 at 13:19

3 Answers 3


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.

  • 1
    It's slightly frustrating that you can't see memory writes from the front-panel, only reads... But hey, that isn't your fault. :-) Feb 1, 2019 at 10:57

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.


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.)

  • The cost remark is about the Altair, not the 8080 CPU.
    – Raffzahn
    Aug 22, 2019 at 10:04
  • @Raffzahn I have difficulty with interpreting "cost-optimised Intel 8080 IC" as being "not [about] the 8080 CPU." (I am pretty sure that the "Intel 8080 IC" and the "8080 CPU" are the same thing.) Nonetheless, I look forward to your explication about how it would have been cheaper to design the 8800 to step through instructions rather than using the native "step through cycles" mode.
    – cjs
    Aug 24, 2019 at 11:15
  • Curt, I have absolutly no idea what you're talking about. Could it be that you attribute claims the OP does to me?
    – Raffzahn
    Aug 24, 2019 at 11:46
  • @Raffzahn No, I'm directly addressing your claim in your comment above that "The cost remark is about the Altair, not the 8080 CPU." I claim that "The cost remark is about the 8080 CPU, not the Altair, because the OP said "cost-optimized Intel 8080 IC."
    – cjs
    Aug 24, 2019 at 11:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .