(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: