> On Nov 1, 2025, at 1:23 PM, Martin Bishop via cctalk <[email protected]>
> wrote:
>
> Peter
>
> I presume by ODT you mean the 11/23 Console ODT, there are ODT programs from
> the Paper Tape era which can be useful on bare metal.
> ODT's cousin DDT and family tree are sketched in
> https://en.wikipedia.org/wiki/Dynamic_Debugging_Technique
>
> If you wish a full fat ODT for bare metal, albeit expecting paper tape input
> (octets into the console terminal should serve), you could investigate
> DEC-11-XPTSA-B-O Paper tape Software handbook - section 5.3.4 pg 5-12 pdf pg
> 114 :: is a good starting point, the "tapes" you wish are ODT-11 and ODT11-X.
> Given the Halt + Proceed incantation, only the later / larger / more
> comprehensive ODT11-X has an instruction step capability.
>
> The DEC hardware mechanism for single step and breakpoints, is a combination
> of the Trace Trap bit in the PSW, its chum the TRAP OpCode, and as
> illustrated by Halt + P : microcode.
> I would leave interfacing with that to paper tape ODT or a more recent
> debugger; their greatest utility is to increase the size of the key hole you
> peer through (into the program / machine)
>
> Martin
I've always done PDP-11 debugging with ODT. That has been a standard tool
since the paper tape days, and later versions (from DEC that is, I don't know
others) are quite similar with only minor tweaks. The primary one I used is
the "monitor ODT" (kernel debugger) that has been part of RSTS since V4A (or
perhaps earlier). And for user mode debugging there always was an ODT.OBJ you
could link in with the program to be debugged.
All these ODTs are octal only, no symbol support of any kind. So you'd debug
with a link map and assembly listings, using the relocation registers so ODT
would show addresses within modules as offsets from the module start rather
than absolute addresses. All that works quite well. ODT doesn't do opcodes
either, which is not a big deal; after all few weeks you have the commonly used
opcodes all memorized.
Admittedly I like gdb now that I've been using it for a few decades. A gdb
port for pdp11 would be an awesome thing. :-) Or, for that matter, GDB stub
support in Open SIMH, that would actually be fairly easy.
Once in a while for hard problems I have used the data breakpoint feature in
Open SIMH. I've used MIPS chips that had such a thing in hardware. It isn't
needed often but when you need it, things are pretty desperate and any other
tool is just not a real option.
paul
