37

The "Basic Programming" cartridge for the Atari 2600 came out in 1980 and it supports all of those except the first one. It had windows for the program, stack, variables, and output which could individually switched on and off (the cartridge would vertically stack as many enabled windows as would fit, stopping when all enabled windows were shown or it ...


28

Without hardware support, there is no way for a debugger to protect itself from the program being debugged. A debugger needs to protect its code and working state, as well as any hooks it's set up for its debugging (e.g. single-stepping interrupts); but in typical "retro" systems (8-bit machines), a debugger would just insert itself into memory and hope for ...


20

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


19

A debugger that runs inside the debugged machine is a program, so it does need memory. Sometimes the debugger is loaded as a ROM cartridge, usually with its own RAM, so it doesn't need to take any RAM from the running program. This is the case with, for example, the Action Replay modules for the Amiga. Sometimes, it's a regular program that takes some RAM, ...


15

The earliest innovator I know of was Manx. Manx made 'C' programming environments for early, low-cost computers like Apple ][, CP/M-80, MS-DOS, and Motorola 68000. Manx Aztec C v1.06 had symbolic (source code) debugging support when released in early 1984. Manx provided a utility "SIDSYM", which was used along with their linker's ability to generate symbol ...


10

Note all your references to changing values are below the stack pointer, actually a free space. You are not expected to care about this area (stack grows towards lower addresses), as this is of no concern to your application. Even if your computer is sitting at a debugger prompt and apparently is inactive, it isn't. It constantly runs through interrupt ...


10

This is less of a definitive answer than a musing about some seemingly underlying assumptions within the question. For the question itself Supercat has already given a near perfect answer. While it is of the typical kind where everyone know it's wrong, it does tick all boxes. I seriously would love to give it double points :) Different Computer Classes The ...


10

Microsoft Codeview shipped in 1985 and has most of the features you're asking about (its been a while so I can't be certain it has everything e.g. call stack walking), when I was doing Turbo C support for Borland in 87/88 support for it was possibly the most requested feature. You could do source level stepping with Turbo C & symdeb but it wasn't as ...


10

I'm including this answer in response to a couple of suggestions, although it does not meet some of the criteria laid out in the question. DDT for the DEC PDP-1 has to be recalled as probably the very first interactive debugger, and most interactive debuggers that came later were indirectly inspired by DDT. (see DDT Writeup). DDT was built in late 1961 or ...


9

(This answers the question "Early architecture that distinguished code from data, here by having differing bank switching for code and data". I'm leaving this here because it's interesting, even if it doesn't meet the criteria of the modified question.) The PDP-1 had a Memory Field Control (Type 14) that was capable of distinguishing between an instruction ...


7

I developed Logo for the Commodore 64, based on work we did at MIT for the Apple ][ and TI 99/4. Apple debugging was done with the ROM, via assembled-in breakpoints. For the C64, Andy Finkelstein at Commodore ordered me a 6510 CPU with an extra pin that signalled the I/D line, and a clamp-on connector that led to a Nicolet-Paratronics logic analyzer, ...


7

Back in the day, MacNosy was the go to disassembler tool to attack things like that. He also wrote a debugger. I can't speak to its status today. Apparently the web site still exists: https://www.jasik.com (We are talking 68K code, right?)


7

THINK Pascal had an integrated debugger that meets all your criteria. You could mark stop points in the editor and then debug your compiled code using them. The debugger supported stepping, a meaningful call stack display, and a good list of the variables as structured typed information.


6

It is possible, but not simple. The ordinary boot process which brings a working machine up from cold to the prompt for a Workbench disk doesn't offer an opportunity to drop into the debugger. A dodgy and potentially hardware-damaging approach is to cause an unexpected CPU exception by e.g. wiggling the trapdoor memory in an A500 -- execbase disappearing is ...


6

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


6

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


6

The extremely popular BBC Micro (1981-1986, still in retro use today) had an exceptionally powerful debugger, "Beebmon" by Watford Electronics, capable of breakpoints, IRQ trapping, code stepping, and so on. From a summary: BEEBMON A ROM based machine code monitor for BBC Micro. It enables machine code programs to be debugged and altered easily ...


5

Db is a debugger for the Atari ST and TT series of 68000-family computers... Db can use any of the ST's character devices for its input and output, including the screen, the serial port, and the MIDI port... Db is capable of debugging programs running on one machine while the bulk of the debugger runs on another. It lets you view the state of the ...


5

For the condition "trap if data is accessed as code": I know of three ways to do that, (1) tagging memory words, (2) using base and limit registers, and (3) as part of the MMU for virtual memory. (3) came comparatively late, so we don't need to look at it. I think most architectural families gained (2) under various names (descriptor, segment, address space,...


4

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


4

The other answers to this question ignore the fact that the "separate program/data" architecture, aka the Harvard architecture, was described and implemented one year before the "shared program/data" architecture (aka Von Neumann architecture). The first example was the Harvard Mark I in 1944, while the EDVAC was written up in 1945. If you want to go back ...


4

You can still use the BRK instruction. But the reason you're not getting to BASIC is because the KERNAL is banked out. When the 6502 executes a BRK instruction, the processor jumps to a routine specified by an address stored inside the KERNAL ROM. If you look at addresses $FFFE-$FFFF, in the KERNAL ROM you'll find that these point to a routine. When BRK is ...


3

Another idea could be to dump some Kickstart ROM to a file, then either add a new Resident module if there is space available in the image, or overwrite a non-essential one (audio.device comes to mind, see below), with a custom module that calls Debug() on Exec (You could use the module's Init function to do this). Then you burn your new ROM to an EPROM and ...


3

On 8-bit machines any debugging support would just be a normal program in memory, and the application could accidentally overwrite the debugger. To single step through a program involved replacing some code in the application with a call or software interrupt that returned control to the debugger. It was all too easy to get a breakpoint in the wrong place ...


3

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


2

The Exidy_Sorcerer included a 4k ROM monitor which included debug capability and, IIRC, single step execution. I believe msDOS/pcDOS 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 ...


2

A debugger may be able to defend his integrity and memory space even in arcane architectures. Granted that in the most common implementations, where you want to save speed and memory, and simplify the debug code, you are dependent on hardware protections provided by more advanced architectures. The software can very well have anti-debug measures built-...


2

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


2

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


Only top voted, non community-wiki answers of a minimum length are eligible