Hi Jos, Thank you for pointing this out. I feel I should have known that. :) I must have glossed over that when I was looking through the manuals.
- Peter On Sat, Nov 1, 2025 at 2:28 PM Jos Fries via cctalk <[email protected]> wrote: > Peter, > > Single-stepping a PDP-11/23 is done by putting the HALT switch in the down > (Halt) position and then issuing the Proceed or Go command. See the KDF11-A > User’s Guide par. 3.4.7. > > Jos > > > Op 1 nov 2025 om 13:58 heeft Peter Ekstrom via cctalk < > [email protected]> het volgende geschreven: > > > > Hi Jay, > > > > Thank you for this information! I didn't think of trying that. Paul's > > suggestion to set PSW to 340 and a reset works as well. > > But it is good to have more options. :) Now to figure out why it won't > run > > on my hardware 11/23. Is there a stand-alone > > debugger for bare metal stuff? I'd like to be able to single-step but ODT > > doesn't have that ability. Got spoiled by SIMH. > > > > - Peter > > > >> On Sat, Nov 1, 2025 at 7:23 AM Jay Logue via cctalk < > [email protected]> > >> wrote: > >> > >> Classic stray LTC interrupt. You can disable LTC interrupts in simh by > >> setting the NOBEVENT option (11/23 and 11/03 only). This simulates > >> disabling the LTC via the front panel switch or a jumper on the CPU > >> board. E.g.: > >> > >> $ pdp11 > >> PDP-11 simulator V4.0-0 Current git commit id: 5cfa8662 > >> sim> SET CPU 11/23 > >> sim> SET CPU 32K > >> sim> SET NOBEVENT > >> sim> RESET > >> sim> load loop.bin > >> sim> g 14000 > >> ^E > >> > >> Simulation stopped, PC: 014006 (BR 14004) > >> > >> Note that a RESET is need after NOBEVENT is set in order for it to take > >> effect. This is because the NOBEVENT option effectively changes the > >> default value of the Interrupt Enable bit in the LTC control register > >> upon a system reset. > >> > >> --Jay > >> > >>> On 10/30/25 07:39, Peter Ekstrom via cctalk wrote: > >>> Anyone here familiar with programming the 11/23 (KDF11-A) in assembler, > >>> bare metal? > >>> I have been trying to get a very simple test program to run on it but > it > >>> keeps halting on > >>> an address outside of the program. Seems to always be the same address > >>> which is why > >>> I am thinking I must be missing something. The program runs fine on an > >>> 11/23+ or 11/70. > >>> [...] > >> > >
