Was there ever a commercially available hobbyist/teaching computer with the ability to single-step the processor? Maybe a Z80-based machine?

  • Because it causes the CPU to wait only during read cycles, I think this might be exactly why the 6502 has its RDY line. Computers like the C64 that want to use it to disable CPU memory access for a certain period have to assert it two cycles early and have to be sure when they're releasing it that they're doing so for at least three cycles in order to make sure the CPU pauses before memory becomes unavailable, based on the observation that it never issues more than two consecutive writes.
    – Tommy
    Commented Sep 10, 2017 at 17:48
  • 1
    When you say "single step" do you mean at the hardware level? Lots of machines could single step at the instruction level.
    – user
    Commented Sep 11, 2017 at 13:36
  • In fact, in my one and only true electrical engineering class (as a comp-sci major), we had to use an 8085 trainer that stepped at the t-state level. And we had to write down the state of every bus line at each t-state. That's a minimum of 4 t-states per instruction. Made me glad I wasn't an engineering major...
    – jeffB
    Commented May 9, 2019 at 16:05

11 Answers 11


Next to every SBC/Kit computer, especially microprocessor systems could do so. Back then a system without this ability was something out of the norm.

For the 8080/Z80, already the grandpa of all hobby computers, the Altair 8800, included that feature. Single step could be issued from the front panel and all cards I've ever seen follow that (hardware) protocol - as, eventually, did the first Z80 card for the S100, the Ithaca Audio Z80 card (IA-1010).

Beside such hardware based solutions, which could even step thru ROM code, virtually every monitor program offered some way of single stepping through (RAM based) code. Like Commodores TIM, or the monitor Woz supplied for the Apple II. After all, what good would be a machine monitor if you couldn't use it for tracing?

  • I recall single-stepping with a debugger on a TRS-80, but that wasn't hardware single-stepping. Stopping the clock on that system would stop DRAM refresh. I didn't think standard dynamic RAM was that unusual at the time, annoying though it was.
    – jeffB
    Commented May 9, 2019 at 16:09
  • @jeffB Yes, of course a Z80 could as well be traced by software. Most notable with CP/M's DDT - but many other did the same.
    – Raffzahn
    Commented May 9, 2019 at 19:09

Hardware single-stepping the Z80 is nice and simple: when the processor asserts the M1 line (meaning it's executing the first machine cycle of an instruction), pull WAIT low until you're ready for it to continue. You could easily build an add on board to do this for just about any Z80 machine with an exposed bus (although in many cases you'd also need to halt the display hardware too).

An alternative option (similar to the system described by Peter Camilleri above) is to wait for the M1 line to be asserted the number of times you want, then issue an interrupt or NMI to cause a jump back to your monitor program. An example of this is seen in the Nascom computers, which were ideal for assembly language development because their 2KiB monitor program and 1KiB video RAM left a very large amount of address space available for user programs, while the monitor itself was fully featured. Although its ability to handle break points was based on changing instruction memory to insert an RST instruction, its single-step function was hardware assisted, as shown in this schematic:

single step section of Nascom 2 schematic

The computer has a latch attached to I/O port 0; on the left side of the schematic bit 3 of this is connected to the clock of a flip-flop (IC14a), which becomes set whenever bit 3 goes high (edge triggered, not level triggered -- this will be relevant later). When this output goes high, two changes occur: the 'set' signal to flip-flops IC14b and IC15a is deasserted, allowing them to start changing (they'll initially both be '1'), and an input to IC10a goes high, which prevents IC15b's reset signal from being asserted while the IC14a state is high.

On the start of the next instruction (call it instruction 1), M1B goes low, then high again; this causes the output of IC14b to toggle from 1 to 0. Instruction 2 causes it to toggle from 0 to 1 again; this causes the clock signal to IC15a to go high, toggling that from 1 to 0. Instruction 3 again causes IC14b to go low; instruction 4 sends it high again, toggling IC15a back to high. This sends a clock signal to IC15b whose /Q output goes from high to low -- this has two effects: the original IC14a flip-flop is reset back to low (and because the input is level triggered it won't become high again until port 0 bit 3 is set low and then back to high again) and an NMI signal is generated until the start of the next instruction. This causes a jump back to the monitor program, which stores the program state, toggles the single step port signal back to low, shows the register contents and waits for a user command. The code in the monitor to issue a single step instruction is:

exec2:  pop bc
    pop de
    pop hl
    pop af
    ; restore user sp
    ld  sp,(rsp)
    ; put user pc on top of stack
    push    hl
    ld  hl,(rpc)
    ex  (sp),hl
    ; set bit 3 of p0, to
    ;  activate nmi
    push    af
    ld  a,8
    out (0),a
    pop af                         ; ** INSTRUCTION 1
    ; execute one step of program
    retn                           ; ** INSTRUCTION 2

Instruction 3 is therefore the executed user instruction, and the NMI occurs at the beginning of instruction 4.

  • 1
    I think the Z80 has static memory registers too, doesn't it? So you could stop the bus as an alternative to asserting the WAIT line if it were more convenient. I guess that'd only be more helpful if you wanted to single-step the clock cycles; otherwise it'd be more work.
    – Tommy
    Commented Sep 10, 2017 at 17:35
  • 3
    @Tommy - the original NMOS Z80 has a note in its datasheet that states it is "static by design but only guaranteed for 200 usec". The later CMOS versions have no such restriction.
    – Jules
    Commented Sep 10, 2017 at 18:44
  • ...and then you will "single-step" prefixed commands twice or even thrice!
    – lvd
    Commented Sep 11, 2017 at 5:09
  • 3
    Could doing this cause problems with dynamic RAM? (IIRC, the Z80 had internal register(s) so it could refresh RAM without (or with less) external hardware).
    – TripeHound
    Commented Sep 11, 2017 at 7:13
  • 2
    @TripeHound - yes, you'd need to put your own refresh mechanism in place if you're using DRAM and the board relies on the Z80's built in refresh.
    – Jules
    Commented Sep 11, 2017 at 22:36

I recall my old Z-80 based SD Systems Z80 Starter kit had single stepping in hardware.

A programmable timer had its output attached to the Non-Maskable Interrupt (NMI) pin. The debugger firmware would setup the timer to trigger that interrupt just as the instruction in question was fetching its first byte. This would fire off that interrupt when the instruction concluded or reached an interruptible point. Since the interrupt could not be masked, the processor had to respond.

The firmware was tricky in that the timer had to be very precisely programmed, but as a single stepper it was rock solid.

As a bonus, this method allows single stepping through ROMs and the firmware did not need to know how long the instruction was. Just where it started, which was typically the last saved PC value.

  • Well, an unusual and interesting design. Do you remember the exact name/model of that kit?
    – Raffzahn
    Commented Sep 10, 2017 at 22:56
  • 1
    Just Google SD Systems z80 Starter kit Commented Sep 10, 2017 at 23:20
  • Oh, that's a real neat one. Never seen before. Thanks.
    – Raffzahn
    Commented Sep 10, 2017 at 23:39
  • @Raffzahn - using a timer for it is a little odd, but I guess if you know what instructions are going to be executed and what the response time for the memory will be it should be reliable. Otherwise this is similar to the design of the Nascom machines (which had a counter for M1 cycles, rather than a timer), which I've added a detailed description of in my answer...
    – Jules
    Commented Nov 18, 2018 at 1:01
  • @Jules ??? I'm not entirely sure why you're addressing me here.
    – Raffzahn
    Commented Nov 18, 2018 at 1:14

The RCA 1802 microprocessor was implemented in fully static CMOS. You could stop and single step the clock to the processor. Perhaps using a debounced front panel switch, which could be done with a slight modification to a Cosmac Elf kit.

A debugger only pretends to single step a program by inserting breakpoints or copying instructions, but the debugger itself is still running.

  • 1
    If you mean a software debugger, sure, but there are plenty of hardware debuggers which use auxiliary logic to control (halt, singlestep, etc) the CPU core - today often hanging off the JTAG interface. Commented Sep 12, 2017 at 5:21
  • An example of such an 1802 system is shown here. It has no ROM, has toggle switches to enter a program, and fits in an Altoids tin. Instructions and some sample programs are here.
    – DrSheldon
    Commented Nov 15, 2020 at 17:02

Since the 8080 and Z80 don't do any memory protection, it's fairly easy to do single stepping with them.

The hardest part is that a debugger that wants to do debuggging has to figure out where one instruction ends, and the next one starts. It then (for example) inserts a ret immediately after the next instruction to execute1. Do a call to execute that instruction, and it executes the instruction and immediately returns to the caller (the debugger). The debugger then looks at register values (or whatever it wants to). When it's ready to execute the next instruction, it replaces the ret it inserted with the original content of that byte, finds the end of the next instruction, and inserts another ret immediately after it. Lather, rinse repeat.

Many newer processors (e.g., the 8086 and newer) have a single step flag (normally called the "trap flag" on x86) to do single stepping without having to modify the target instructions, which is certainly handy.

It can get more difficult with processors that have MMUs, so it's harder to write to the code to be executed. In such cases, either you need something like the 8086's trap flag, or else the debugger needs enough privileges to modify the target code (e.g., it may need to run as a privileged process).

  1. Another fairly popular possibility is to insert an rst instruction.
  • 2
    SID and DDT did simply use RST7 (RST38) - like basicly every other 8080/Z80 software based debugger/singlestep function did use a RST instruction. Using a single step strategy with call, as described, would leave the debbuged progamm with an altered stack, so any stack related instruction traced would utterly fail. I don't know of any debuger on any machine (especially not machines with a stack based subroutine call) I ever used to utilize a call based scheme. Mind to share any source links for this?
    – Raffzahn
    Commented Sep 9, 2017 at 23:03
  • @Raffzahn: The debugger does have to do a bit of stack fixup in some cases, yes. My experience with such things predates the Internet by quite some time, and I'm not at all sure I remember enough to find a link, but I'll at least take a quick glance around anyway. Commented Sep 9, 2017 at 23:09
  • programming for money since the 1970s and most of that time in Assembly, I'm always keen to learn new methods.
    – Raffzahn
    Commented Sep 9, 2017 at 23:21

In my time as an electronics student I worked with a trainer based on 6502 that allowed the execution step by step.

It had a hexadecimal keyboard and a 7-segment display with 8 digits (if I remember correctly).

Binging (not Googling) "6502 trainer" I found a couple of interesting names: KIM-1 and EMMA II

  • For KIM-1 there's a software emulator -> Soft6502 (KIM-1) looks cool! In eBay I see a few, but with expasinve Price ($599, $999, $4.995)
  • You can see ENMA II here EMMA II sold!
  • Searching "6502" on eBay you can found some trainers some at good Price ($120 -> Looks good)

The 6502 procesor is simplest than z80, and it's a good start too, but I prefer a z80 on a ZX Spectrum 48K :)

  • 2
    I wonder why this was downvoted. "Binging" isn't THAT bad, is it? Commented Sep 14, 2017 at 19:47
  • 3
    @manassehkatz I've noticed that there is a tendency on SE, or at least on RC.SE, to avoid unnecessary brand-dropping. Saying "searching for" does the job and doesn't annoy anyone. Personally, I don't care either way, but who knows, that could be the case. I've seen my questions or answers downvoted without explanations.
    – Leo B.
    Commented Sep 14, 2017 at 21:35
  • @LeoB The truth is out there, no matter how you find it! xxD
    – Duefectu
    Commented Sep 14, 2017 at 22:15
  • 2
    If memory serves, the KIM-I was the official evaluation board, released by MOS, carrying the earliest manufactured 6502s and supported by Chuck Peddle himself. That might explain the price. Just don't try to use one to learn about ROR.
    – Tommy
    Commented Sep 15, 2017 at 19:18
  • 1
    6502 is probably the very worst choice for a single-steppable machine - it is almost a DRAM with some logic wiring thrown in internally :) Commented Sep 16, 2017 at 20:25

The Nascom computers provided single-stepping. They did it by outputting a certain value to a port. Special circuitry then waited for enough M1 cycles (opcode fetches) to complete


and have another command start before triggering an NMI signal. A built-in debugger in the 2k of system monitor ROM then produced a register dump and put you back at the system prompt (where you could continue stepping or do other things).

There also was a 1kB debugger available (interesting since you could put it anywhere in RAM, not a mean feat on a Z80) that used the 3kB disassembler for displaying the actual opcodes if you were tired of reading hex codes. The usual setup of those computers had 8kB of ROM Basic (as delivered), 4kB of editor/assembler and the 3kB/1kB combination of debugger/disassembler (free sockets on the main board taking 1kB EPROMS). Oh, and of course the system ROM (2kB).


  • Nascom ruled! Has an N2 for years, learned a lot. Probably the most sucessful kit computer produced in UK.
    – Tim Ring
    Commented May 16, 2018 at 9:37
  • Have added a description in my answer of how the hardware on the Nascom 2 implemented this, which is quite interesting.
    – Jules
    Commented Nov 18, 2018 at 0:45

The DEC PDP-1 was a commercially available computer, launched in 1961. It was not a minicomputer, much less a microcomputer. It was only a "teaching machine" in the sense that about half of them were sold to universities, where they were used for both learning and research.

The PDP-1 had a hardware single step function, operated by a console switch. More importantly, it had a debugging program, written by Alan Kotok at MIT. You could set breakpoints in a program, and when it hit a breakpoint, you could examine and modify memory locations, including both variables and instructions.

Online searches say that DDT dates from 1964, but I have a distinct recollection of using it as early as the summer of 1963, and I believe it was already written by early 1962.

  • Not just the PDP-1. Loads of old mainframe and mini computers from the big-iron era allowed the operator to "run," "stop," and "single-step" from the front panel. Commented May 9, 2019 at 13:10
  • 1
    There are two reasons I focus on the PDP-1. First, it was built for interactive use. Second, it was the first computer I actually got my mitts on. The "operator" was a user. This was not typical for big iron. Commented May 9, 2019 at 14:04
  • "Operator" and "user" are roles (same goes for "programmer," and "data entry clerk," and various others). The same person can perform any or all of the above, and often did perform all of the above if the computer was located in a lab. And really, the "single-step" switch on the front panel belongs to the "programmer" role: The front panel's switches, lights, and single-step function comprised the programmer's debugger-of-last-resort. Commented May 9, 2019 at 14:17
  • 1
    I'm going to say that the single step switch belongs to the "debugger" role. If the bug is a software bug, there's a huge overlap between the programmer role and the debugger role. If the bug is a hardware bug, the debugger role overlaps with the field service engineer role. The hobbyist of 15-20 years later was his own field service engineer. But in the context I'm speaking of, they were different roles. Commented May 9, 2019 at 15:07
  • DDT listing from bitsavers -- title in code says Feb 1963. That is probably the "last change" date rather than original creation - another DDT listing has a 1966 date.
    – dave
    Commented May 9, 2019 at 23:29

Was there ever a commercially available hobbyist/teaching computer with the ability to single-step the processor?

The first Z80 hardware book by Steve Ciarcia describes a circuit to provide single step capability. This is discussed in section 4, and a circuit provided in Figure 4.5. Most of the Z80 computers could do single stepping if only to help with debugging.

Maybe a Z80-based machine?

At the moment, there are two machines, to my knowledge, that can do single stepping and are available for hobbyist / teaching purposes.

The RC2014 with the optional Scott Baker Single Stepper is the first option.

The other option is the YAZ180 for which printed circuit boards can be obtained on Tindie. The YAZ180 has TIL311 Hexadecimal LEDs which show address and data contents when single stepping. The schematic shows the circuit implemented.


In my homebrew Z180-based system I'm using the following SW mechanism:

  • the debugger has a specific "execution buffer", which is preced by an EI instruction
  • debugger recognizes EI and DI instructions and skips them
  • next 4 bytes (maximum lenght of instruction) are fetched into the execution buffer
  • interrupts are disable, highest possible interrupt request is activated to be pending
  • code enters the EI instruction, which enables interrupts after the NEXT instruction
  • interrupt happens, SW deactivates the interrupt, collects the corresponding data, computes address for next instruction after JR instructions, etc.

I have used this mechanism for more than 20 years, first with a Z80 based system, nowadays with a Z180 based board. My debugger combines the base mechanism with things like:

  • execute step by step until call of sub-program or return from sub-program
  • execute step by step until given address has been reached
  • execute step by step given condition happens. For e.g. until HL=0
  • execute (without stepping) a sub-program
  • execute (without stepping) a sub-program, and tell how many useconds it took to execute
  • execute (without stepping) up to given address. I.e. kind of breakpoint

In other words, the mechanism is pretty flexible. Also, the overhead is very low, so the multiuser operating system runs normally during debugging. I'm even able to use the debugger simultaneously for several user processes (little need for that, though).

The main part of the debugger is implemented in BASIC, the assembler part is pretty small (less than 0.5KB, including data areas) and is used as an external library.

The only needed HW is some interrupt source, which can be used to go active at demand. My latest boards use an otherwise unused UART port for that purpose, but any suitable mechanism should work. However, the debug interrupt must be the highest one, otherwise you'll find out that the debugged code has branched into some system code... Still, the actual interrupt line (like Z180 INTx) can be shared with other interrupt sources; in my current system the interrupt line is shared with an other UART port and timer on the same chip.

  • 3
    This is extremely interesting, but was it commercially available? (Also, tour.)
    – wizzwizz4
    Commented May 9, 2019 at 5:55

The Exidy Sorcerer included a 4K ROM monitor which included debug capability and, IIRC, single step execution.

I believe MS-DOS/PC DOS debug program could single step through the execution of other DOS programs. I just checked, and see that the CP/M operating system included ddt (dynamic debugging tool) program. I'm guessing it was likely the model from which debug was built.

So yes, the capability was not only available, but common.

You must log in to answer this question.

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