Skip to content

ND-500 Bring-Up and Bus-Interface - Feedback for the Deep-Analysis / CPU-Connect Goal

Purpose: consolidate what THIS session established (from the monitor nd-500-mon-j04.prog, the swapper domain, and the SINTRAN MON 60 worker source) into a form the carve/CPU team can fold into the eventual deep validation of the ND-500 bus-interface document and the work of getting the ND-500 CPU connected and bootstrapped under the emulator.

Everything below is marked PROVEN (read from bytes/source this session), or INFERRED / OPEN (needs the bus-interface doc, the microcode, or a live trace to settle).

Repo home: SINTRAN/ND500/nd-500-mon/ (all repo paths below are relative to the repo root E:\Dev\Ronny\NDInsight). The ORIGINAL source package (disk image + the .prog original) remains outside the repo at the external path /mnt/d/ND/500/ND-500(0) System Package for SINTRAN IIIVSX L/.

Cross-references: - SINTRAN/ND500/nd-500-mon/nd-500-mon-j04.prog.md - the monitor, the single MON 60 gateway - SINTRAN/ND500/nd-500-mon/mon60-callers/INDEX.md, SINTRAN/ND500/nd-500-mon/mon60-callers/SUBFUNCTION-TABLE.md - every MON 60 subfunction - SINTRAN/ND500/swapper/swapper-k01.pseg.md, SINTRAN/ND500/swapper/swapper-k01.dseg.md - the swapper domain - SINTRAN/ND500/nd-500-mon/nd-500-control-store-debug-handoff.md - the RetroCore TAG-OUT/DMA crash - Bus-interface doc under review: SINTRAN/ND500/ND500-BUS-INTERFACE-REFERENCE.md - Worker source: SINTRAN/NPL-SOURCE/NPL/5P-P2-MON60.NPL

1. Layering - what talks to what (PROVEN)

operator (N500: prompt)
  -> ND-500 monitor  nd-500-mon-j04.prog  (ND-100 user program)
       - builds a parameter block, picks a MON 60 subfunction
       - ONE instruction crosses down: MON 60 at 146256B (no IOX of its own)
  -> SINTRAN resident MON 60 worker  (5P-P2-MON60.NPL)
       - 5IFUNC dispatch on the subfunction code
       - marshals params into the MON60 buffer, drives the interface
  -> 3022/5015 bus-interface IOX registers  (CONTROL/STATUS/MAR/DATA/TAG)
  -> ND-500 microcode (control store)  <-- THIS is the ND-500 "CPU logic"
       - reads the message buffer by DMA (through MAR), executes, DMAs answer back
  -> level-12 interrupt back to the ND-100

Key consequence for the emulator: the ND-100-side program never touches the bus registers. All 3022/5015 IOX traffic is generated by the SINTRAN resident worker and by the ND-500 microcode. So "connecting the CPU" is about the interface model + the microcode engine, not about the monitor program.

2. What actually runs on the ND-500 side (PROVEN / INFERRED)

Three distinct things, often conflated - keep them separate:

  1. The control store (microcode) = the ND-500 CPU's instruction engine. This is what executes ND-500 machine instructions. It is loaded FROM the ND-100 across the interface. Until it is resident and its microclock runs, the ND-500 does nothing. (PROVEN: every MON 60 can return ECSLOAD "control store must be loaded" and the monitor auto-loads (SYSTEM)CONTROL-STORE:DATA; the microcode word is 144-bit for classic ND-500 / 128-bit for ND-5800-SAMSON, loaded as 16-bit parts through the interface.)

  2. The swapper domain (swapper-k01) = an ND-500 native two-segment domain the monitor PLACEs on top of the running CPU. It is NOT the CPU and NOT the microcode. It is a paging/swap worker domain (ND-500 process #0's server), a client of SINTRAN. (PROVEN: SINTRAN/ND500/swapper/swapper-k01.pseg.md - 151 routines, terminates via MON 0B LEAVE, requests services via MON 377B segment-31 traps.)

  3. User ND-500 programs / standard domains placed and started via the monitor.

So: "is the code running on the 500 the swapper?" - only once you PLACE + START it, and only as one domain among others. The thing that makes the CPU run at all is the control store microcode, loaded first.

3. How the ND-100 loads/sets things in the ND-500 (PROVEN - the MON 60 menu)

From SINTRAN/ND500/nd-500-mon/mon60-callers/SUBFUNCTION-TABLE.md (authoritative, 5P-P2-MON60.NPL). The load/set primitives - i.e. the options for putting code/data/microcode/config into the ND-500:

Subfn Purpose Use in bring-up
037 LOAD CONTROL STORE (load a file into CS) step 1 - microcode
024/157 WRITE CONTROL STORE (from user buffer) microcode, direct
023 READ CONTROL STORE verify/compare CS
040 DEFINE MEMORY CONFIGURATION map ND-500 phys addr 0 to an ND-100 page
060 LIST MEMORY CONFIGURATION read back the map
006/160 LOAD (PLACE) ONE SEGMENT [new-domain-format=160] place a domain's segments
055/056 START-PLACE / END-PLACE bracket a place operation
007 PLACE SWAPPER load the swapper domain
054 (start swapper) start it
004/005 WRITE LOGICAL PROGRAM / DATA MEMORY poke ND-500 memory
033 WRITE PHYSICAL DATA MEMORY absolute poke
110 WRITE INTO A PHYSICAL SEGMENT segment poke
001/011 WRITE REGISTER(S) set ND-500 CPU registers
025 MICRO-START start the microengine at an address
034/035 MICRO-STOP / MASTER-CLEAR stop / reset
012 START ND-500 PROGRAM run a placed program
136/143 ACTIVATE stopped process / activate program in ND-500 or ND-100

Read-back / status primitives you will need to model on the interface: 041 READ ND-500 INTERFACE STATUS, 051 READ COMMUNICATION (IODATUT) REGISTER, 057 READ MICRO PROGRAM VERSION, 170 READ ND-500 CPU-TYPE AND MIC.VERSION, 172 READ HW SCRATCH REGISTER FILE, 173 SET CPU STATUS.

4. The bootstrap sequence (INFERRED from the above, to be validated against the doc)

  1. Detect CPU - SINTRAN's CH5CPUPRESENT reads STATUS via a probe IOX; sets OLD500 vs SAMSON. (Bus-interface doc section 8.1.) Emulator must answer this probe correctly or the ND-500 is treated as absent.
  2. Define memory configuration (040) - map ND-500 physical address 0 to an ND-100 page. On this system MEM-CONF reports ND-500 addr 0 at ND-100 page 004100B = physical word 0x210000 (see the debug handoff). The ND-100 physical RAM must actually cover the ND-500 window and register block (pages 004100B-004252B).
  3. Load control store (037, or 024/157) - put the microcode in. Microclock starts. Verify with 023 COMPARE / 057 / 170.
  4. Micro-start (025) if required, then the interface reports the CPU alive (STATUS bit 5 5ILOC/running, bit 9 5CLOST clear).
  5. Place + start the swapper (007 then 054) so paging works.
  6. Place a domain (055 START-PLACE, 006/160 per segment, 056 END-PLACE) and start it (012).

The monitor already automates step 3 (auto-load (SYSTEM)CONTROL-STORE:DATA on ECSLOAD), which is why any ND-500 op fails with NO SUCH FILE NAME when that microcode file is absent.

5. The concrete emulator gap this session exposed (PROVEN)

Once a control store was supplied, STATUS reached a running microengine and the RetroCore emulator crashed in NDBusND500IF.WriteND100Memory with Unmapped memory. That is the ND-500 microcode doing a DMA into ND-100 memory via a TAG-OUT to an address the emulator has not mapped - the ND-500 window at ND-100 physical word 0x210000+. Full analysis, ranked hypotheses, and breakpoints are in SINTRAN/ND500/nd-500-mon/nd-500-control-store-debug-handoff.md.

This is the single most important thing to get right to "connect the CPU": the interface model's MAR two-step assembly and the TAG-OUT DMA read/write-ND-100-memory path, plus enough ND-100 physical RAM to back the ND-500 window. Getting DMA-through-MAR correct is the crux of the mailbox mechanism.

6. Suggested checks when validating the bus-interface document

When the extraction is done and the doc is re-analysed, these are the points this session touched that are worth confirming/extending in it:

  • Message-buffer / mailbox field layout - the doc has three conflicting field sets (its own reference vs the comprehensive guide vs the C# constants). The 5P-P2-MON60.NPL worker is the tie-breaker: it references the fields by name (5MBBANK, MESSBUFF, 5MSFL, 5PRDESCR, 5P1..5P5, 5DD1..5DD4, 55REP, etc.) - map those to offsets from the NPL, not from the C# model (the doc flags the C# constants as untrustworthy).
  • The 5NOPAR generic path - confirm how a "no special marshalling" subfunction still moves its message to the ND-500 (this is the common DMA path the emulator must service).
  • MAR two-step / TAG-OUT semantics - validate against the crash: which TAG-OUT code the microcode uses for the answer DMA, and the exact MAR->ND-100-address arithmetic.
  • STATUS bit meaning for "control store loaded / microclock running" - this is what makes SINTRAN stop returning ECSLOAD; get the bit the driver samples exactly right, or the emulator will either always demand a control-store load or never.
  • CPU-type field - 170 READ CPU-TYPE+MIC.VERSION and the CH5CPUPRESENT OLD500/SAMSON encoding (the doc corrected an earlier high-bit/low-bit error here; confirm which CPU the emulator should present, since it decides which microcode/control-store format is valid).
  • Table completeness - the monitor's MON 60 space runs to 177B; the NDInsight yaml stops at 142B. The new SINTRAN/ND500/nd-500-mon/mon60-callers/SUBFUNCTION-TABLE.md fills 143B-173B from the NPL. Fold those into the interface doc's function list.

7. Open questions this session could not settle (need the doc / microcode / live trace)

  • Exact operator-command -> subfunction mapping for a few commands (e.g. PLACE-DOMAIN vs the standard-domain family 127/130/131) - needs the monitor's command dispatch table.
  • The full trap-code / stop-reason table the ND-500 returns after activation.
  • Whether the supplied (SYSTEM)CONTROL-STORE:DATA is the CORRECT microcode for the target CPU - run COMPARE-CONTROL-STORE once STATUS survives; a 0-fault compare confirms it.
  • The precise MAR->ND-100 physical address arithmetic in the emulator (the crux of section 5).

This note is meant to be forwarded alongside the MON-call extraction so the bus-interface deep-analysis starts from the load/set/bootstrap primitives already pinned here, and aims straight at the DMA-through-MAR mailbox path that currently blocks CPU connection.