(DU) MSCP UDA50(RAxx) disk: https://ak6dn.github.io/PDP-11/M9312/ https://ak6dn.github.io/PDP-11/M9312/23-767A9/23-767A9.mac https://ak6dn.github.io/PDP-11/M9312/23-767A9/23-767A9.lst On Mon, Oct 27, 2025, 4:48 PM Wayne S via cctalk <cctalk(a)classiccmp.org> 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. Below is the listing: 1 000000 .asect 2 014000 .=14000 3 014000 012706 002000 start: mov #2000,sp 4 014004 000240 loop: nop 5 014006 000776 br loop 6 .end I have a hardware 11/23 but for convenience I have been testing on a SIMH 11/23 by loading the binary from the simh prompt and then jumping to the start address. I have tested the same code on 11/23+ and 11/70 CPUs and it runs fine. I am working in Linux and am using the following Macro11 cross-assembler: macro11 - portable MACRO11 assembler for DEC PDP-11 Version 0.8 (07 Jul 2022) Copyright 2001 Richard Krehbiel, modified 2009 by Joerg Hoppe, modified 2015-2017,2020-2021 by Olaf 'Rhialto' Seibert. I then use the obj2bin.pl utility by Don North to convert from object format to binary load format. The following is what happens: PDP-11 simulator Open SIMH V4.1-0 Current git commit id: 29d39002 sim> set cpu 11/23 sim> load test.bin sim> g 14000 HALT instruction, PC: 005271 (HALT) sim> Am I missing some initialization parts or something? I have looked through various manuals and the processor handbook for the LSI-11 but if it is in there, I am missing it. Any pointers would be greatly appreciated. -Peter On Tue, Oct 28, 2025 at 3:38 PM Peter Ekstrom <epekstrom(a)gmail.com> wrote:

If I single-step, it doesn't seem to happen. But I have been playing around with my test program and I added a loop in the beginning that clears 0-377. That loop uses a bne instruction which seems to work fine. When I reach a br or jmp instruction, the program fails. I saw in the opcode test for macro11 in the simtools package, the br instruction is tested with 'br .' so I used that in my program and it failed too. Now I really need to try this on my hardware 11/23 tonight..... -Peter On Thu, Oct 30, 2025 at 1:03 PM Martin Bishop via cctalk < cctalk(a)classiccmp.org&gt; wrote:

This sure is strange. The CPU trace feature could be helpful here. Set it up to trace execution and run your program. Then dump the trace buffer to see what actually happened. paul

On Thu, Oct 30, 2025, 4:38 PM Peter Ekstrom via cctalk < cctalk(a)classiccmp.org&gt; wrote: Just a wild guess, could this possibly be an unhandled LTC interrupt issue?

More: "reset" should reset all devices. I don't remember the 11/23 well enough; it seems that it has a clock that keeps interrupting even if you do a reset. So raise the priority to 7 (mov #340, @#177776 which is 12737, 340, 177776). Or use the deposit command before you do the "go": "d psw 340". Most machines have clocks that do obey reset, for example "reset" then "go" will work correctly if your CPU type is 11/73. paul

The following is what happens: PDP-11 simulator Open SIMH V4.1-0 Current git commit id: 29d39002 sim> set cpu 11/23 sim> load test.bin sim> g 14000 HALT instruction, PC: 005271 (HALT) sim> << /extract>> the PC of 5271 is interesting in its own right … - it is illegal (an odd address instruction fetch), should trap to 4 and halt the machine - how simh presents and responds to this condition is beyond my ken .. Also, if there was an illegal address abort, there should be PC/PS info at 0/2 And, inspection of the SP and the bottom of the stack is always worthwhile If the SP is ~17776 then something has overwritten the vectors, the 11/45 and up have hardware bottom of stack protection (amber trap and red abort iirc) Additionally, does your instance of simh execute the basic (11/20) diagnostics correctly ? To recollection they are simple executables : start -> loop Utilities often have multiple executables concatenated on a single tape: eg zero memory, then load and go; or load bootstrap, load software iaw offset indicated by switches and then go. Note that early vintage utilities / MainDECs often read the console switches for "parameters" HtH Martin From: Peter Ekstrom &lt;epekstrom(a)gmail.com&gt; Sent: 30 October 2025 18:43 To: General Discussion: On-Topic and Off-Topic Posts &lt;cctalk(a)classiccmp.org&gt; Cc: Martin Bishop &lt;mjd.bishop(a)emeritus-solutions.com&gt; Subject: Re: [cctalk] Re: Looking for a bootloader If I single-step, it doesn't seem to happen. But I have been playing around with my test program and I added a loop in the beginning that clears 0-377. That loop uses a bne instruction which seems to work fine. When I reach a br or jmp instruction, the program fails. I saw in the opcode test for macro11 in the simtools package, the br instruction is tested with 'br .' so I used that in my program and it failed too. Now I really need to try this on my hardware 11/23 tonight..... -Peter On Thu, Oct 30, 2025 at 1:03 PM Martin Bishop via cctalk <cctalk@classiccmp.org<mailto:cctalk@classiccmp.org>> wrote: I would verify that what you intended to load has been correctly loaded, by displaying / dumping 1400 et seq. If that is good, I would then instruction step to observe where execution leads. It may also be necessary to clear the processor's state and maybe issue a bus init - however, the simulator startup probably obliges. Martin PS FWIW all the vectors and traps (0 to 400 in big handfulls) are uninitialised (by you), so any of those could take you to exciting places - eg 5271 -----Original Message----- From: Peter Ekstrom via cctalk <cctalk@classiccmp.org<mailto:cctalk@classiccmp.org>> Sent: 30 October 2025 14:40 To: General Discussion: On-Topic and Off-Topic Posts <cctalk@classiccmp.org<mailto:cctalk@classiccmp.org>> Cc: Peter Ekstrom <epekstrom@gmail.com<mailto:epekstrom@gmail.com>> Subject: [cctalk] Re: Looking for a bootloader 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. Below is the listing: 1 000000 .asect 2 014000 .=14000 3 014000 012706 002000 start: mov #2000,sp 4 014004 000240 loop: nop 5 014006 000776 br loop 6 .end I have a hardware 11/23 but for convenience I have been testing on a SIMH 11/23 by loading the binary from the simh prompt and then jumping to the start address. I have tested the same code on 11/23+ and 11/70 CPUs and it runs fine. I am working in Linux and am using the following Macro11 cross-assembler: macro11 - portable MACRO11 assembler for DEC PDP-11 Version 0.8 (07 Jul 2022) Copyright 2001 Richard Krehbiel, modified 2009 by Joerg Hoppe, modified 2015-2017,2020-2021 by Olaf 'Rhialto' Seibert. I then use the obj2bin.pl<http://obj2bin.pl> utility by Don North to convert from object format to binary load format. The following is what happens: PDP-11 simulator Open SIMH V4.1-0 Current git commit id: 29d39002 sim> set cpu 11/23 sim> load test.bin sim> g 14000 HALT instruction, PC: 005271 (HALT) sim> Am I missing some initialization parts or something? I have looked through various manuals and the processor handbook for the LSI-11 but if it is in there, I am missing it. Any pointers would be greatly appreciated. -Peter On Tue, Oct 28, 2025 at 3:38 PM Peter Ekstrom <epekstrom@gmail.com<mailto:epekstrom@gmail.com>> wrote:

On 10/30/25 18:29, Peter Ekstrom via cctalk wrote: It is NOT your Macro11,  It has to be an interrupt.  Nothing else could break that loop of instructions.  Scan low memory for a location that has 5266 in it.  Some interrupt is causing the machine to jump to a vector that points to 5266.  Glen suggests the line time clock vector.  The KW11-L LTC vector is at 100.(8). Jon

On 10/30/25 09:39, Peter Ekstrom via cctalk wrote: WOW, that code is insanely simple.  Is it possible there is a timer (or other) interrupt happening?  I can't see any reason the CPU will jump out of that do-nothing loop. Jon

I don't know why I hadn't thought of this before... I setup SIMH as before as an 11/23, started booting up RSX11M but aborted it after the RSX11M banner. Then I loaded my test program and jumped to 14000, and it runs! So this would point to interrupts I would guess? Meaning, I am not handling them properly? - Peter On Thu, Oct 30, 2025 at 8:15 PM Peter Ekstrom &lt;epekstrom(a)gmail.com&gt; wrote:

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 &lt;cctalk(a)classiccmp.org&gt; 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 -----Original Message----- From: Jos Fries via cctalk [mailto:cctalk@classiccmp.org] Sent: 01 November 2025 16:38 To: cctalk(a)classiccmp.org Cc: Jos Fries &lt;jos.fries(a)kpnmail.nl&gt; Subject: [cctalk] Re: Looking for a bootloader 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

CORRECTION : BPT not TRAP is used by debug tools, to set breakpoints -----Original Message----- From: Martin Bishop Sent: 01 November 2025 17:23 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 -----Original Message----- From: Jos Fries via cctalk [mailto:cctalk@classiccmp.org] Sent: 01 November 2025 16:38 To: cctalk(a)classiccmp.org Cc: Jos Fries &lt;jos.fries(a)kpnmail.nl&gt; Subject: [cctalk] Re: Looking for a bootloader 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

All, Thank you for all your help and suggestions! The test program and the bigger program I am working on both work reliably on an 11/23 CPU now. When I tried the bigger program on my hardware 11/23 I had problems. It randomly jumped to odd places and crashed. Because it is big, a little over 1KB, I use a modified vtserver to help me load it. Using ODT and a halted CPU to single-step, I found out that some of the words loaded by vtserver weren't the right ones. After looking at it some more, it seems vtserver has problems with the higher-value instruction words and ends up loading something completely different. So I'll have to look closer at vtserver and see why that is. I tried lowering the baud rate of the console but that made no difference. So it appears to be a problem with vtserver at this point. I manually went through the affected locations and corrected them. After that the program ran great and I was able to boot up RSX11M from an RD53. - Peter On Tue, Nov 4, 2025 at 11:03 AM Peter Ekstrom &lt;epekstrom(a)gmail.com&gt; wrote: