(Note: I am referring to software that would run on an end-users' system, not special debugging computers)

Debuggers are programs that poke around at other programs' memory. In modern computers they rely on the ability for multiple programs to run at once, abundance of memory and, most importantly, dynamic allocation: an ordinary program only having access to memory it's reserved, which other programs can't simultaneously use for different purposes.

However, retro-computers didn't have these features: except using interrupts (passing control back and forth), programs couldn't run simultaneously. Programs had access to all the memory: there was no way to tell what memory was and wasn't used, therefore knowing where to load the debugger. And even if there was a way to know that, many programs used most or all of the memory in a computer, leaving no place for the debugger to run.

And yet debugging software did exist, such as the DDT series, the ODT series, OLIVER, SIMON, CA/EZTEST and much of the XPEDITER series. My question is: how did they work?

  • How did they load themselves into memory without conflict?
  • How did they implement single-stepping?
  • How did they ensure that they weren't overwritten?
  • 2
    This seems overly broad -- every retro system could have a different solution. The Apple II had in-memory debuggers that trapped BRK, the Apple IIgs had debugging boards with NMI buttons, the SNES had development hardware and ICEs, etc.
    – fadden
    May 20 '16 at 18:06
  • 1
    @fadden Couldn't there be an answer along the lines of "it depends" then describing how several systems would do it? (Although two of your examples are about extra hardware, which is not what I meant so I will clarify)
    – wizzwizz4
    May 20 '16 at 18:08
  • 2
    I mean just BKPT instruction, data/instruction address comparators, single-step exception - these can be fairly trivial in hardware, so exist in production hardware (at least for some processors). May 20 '16 at 18:38
  • 2
    To narrow the scope of the question, I'd suggest reading up on debuggers, and asking specific questions that come up then. For example, what's the use of a certain feature, how was a specific feature implemented... Even limiting this question to software debuggers is rather broad: there are system-level debuggers, interpreter-based debuggers, debuggers running on a second system... May 20 '16 at 18:55
  • 4
    Too bad that this question is way too general for SE, but how developers handled debugging on computers and consoles before the early / mid 90s would be very interesting to learn about. Coworker's response: "border color." Programmers these days have it easy with MMUs and protected memory environments.
    – rcntxtlztn
    May 21 '16 at 3:40

Browse other questions tagged or ask your own question.