MON 422B (octal) - GetScratchSegment (GSWSP)¶

Connects an empty data segment to the caller's domain and reserves space for it on the swap file. The new segment gets the default name SCRATCH-SEGMENT:DSEG. It belongs to the ND-500 monitor-call family (410B-427B) dispatched through the S3SM5 numeric vector table - but its vector slot is empty, so no handler code exists in the carved 030-S3SM5 segment.

Status: the empty vector slot is byte-proven (slot 0x0284 = 0x0000); the actual servicing point is NOT LOCATED / UNVERIFIED. All addresses/values are octal unless a 0x prefix or (dec) marks them hex/decimal.

❌ REOPENED 2026-08-26 — THE "CLOSED" VERDICT BELOW IS REFUTED. READ THIS FIRST.¶

422B GSWSP IS SERVICED ON AN L PACK. Measured on the Gate5R lane (classic 3022, real SINTRAN III VSX/500 L, real 5MPM mailbox), CAT-CAT5-B06 with no command input, two calls:
#103  ret=0x0801E587  SizeInBytes=0x00020801  LogSegmentNo=0  ->  RetLogSegmentNo=0  K=0
#775  ret=0x0801DF2A  SizeInBytes=0x00020801  LogSegmentNo=0  ->  RetLogSegmentNo=2  K=0
Neither answers K=1 / 0x20B, and the second is a successful selection. So "nothing services this call in SINTRAN III VSX/500 L" is wrong. The empty S3SM5 slot 0x0284 is real — it is just not the whole route, and the struck-out "serviced elsewhere (ND-100 back-end, UNCONFIRMED)" hop below should come back.

The consequence is refuted too: "CPU-STAT cannot complete on an L-version pack" — CPU-STAT runs to a full report on this lane, and LED-FORTRAN-A01, LINKER-B01 and the PLANC compiler all run as well.

THE ANSWER CAME FROM REAL SINTRAN, verified rather than assumed. The round trip is the proof and a C#-emulated MON produces none of it — no monitor-call stop, no context switch, no restart record, no mask-driven write-back:
#103  MON 422B argc=3 ret=0x0801E587 | UCODE-ROLE=Forwarded   <- printed by the bridge
#104  CONTEXT SAVE X5CPU=1 P=0x0801E587 (monitor-call stop)
#105  CONTEXT SWITCH X5CPU=1 -> 0
#115  RESTART write-back: @0x08022CFC:=0x00000000
#116  RESTART K=0 FUNCV=0x00000000
⚠️ Do NOT rely on SINTRAN_EMULATION being compiled out to prove a MON reached SINTRAN. The symbol is defined (Emulated.HW.csproj:16), so the C# MON layer is compiled in. What actually guards it is a runtime precedence — CpuND500.IndirectSegments.cs:188 calls the mailbox sink FIRST and only falls through to the #if SINTRAN_EMULATION block if the sink declines. Comments in the harness claiming the bridge "disables it outright" describe an intent, not a check. Prove it from the round-trip records above.

STILL OPEN: call 1 answers K=0, FUNCV=0, write-back carrying 0. That matches neither the documented K=1/1013B for an unserviced call nor our own C# handler. RetLogSegmentNo=0 is not a selection a scratch grant can make (LogSegmentNo=0 on input means "you pick", so the input sentinel and the failure value are the same number). Whether SINTRAN genuinely reports success-selecting-nothing, or the answer is mistranslated somewhere, is unresolved — the next step is logging the RAW KFLIP/FUNCV/NUMPA halfwords off the wire rather than the derived values.

The refuted verdict is kept below, unedited, so it is not re-derived.

~~CLOSED BY LIVE MEASUREMENT, 2026-08-24 — it is NOT serviced anywhere~~ (REFUTED, see above)¶

The "serviced elsewhere (ND-100 back-end, UNCONFIRMED)" hop below can be struck out. On a live run of this exact image, a real ND-500 domain issued MON 422B and SINTRAN answered it with an ERROR:
CONTEXT SWITCH X5CPU=0 -> 1 (P=0x0800473A)
RESTART write-back: (empty)
RESTART K=1 FUNCV=0x0000020B
K=1 is the ND-500 error flag and 0x20B = 1013B = "Illegal monitor call number" (ND-05.017.01 Appendix A.13, "Error codes from monitor calls"). So the empty vector slot is the whole story: nothing services this call in SINTRAN III VSX/500 L.

The measurement is trustworthy because the same path succeeds for another call. In the same run MON 377B returned K=0 88 times over the identical mailbox/MCNO plumbing, so this is not a broken emulator forwarding a mangled call number. The caller was CPU-STAT, whose disassembly names MON 422B at two sites, so the CALLG decode is not inventing the number either.

Consequence: CPU-STAT cannot complete on an L-version pack. GSWSP is the FIRST call its runtime init makes, so it never reaches its own logic.

Setup: Nd500_CpuStat_UnderRealSintran_RealCpu_Capture in RetroCore Emulated.Tests\ND100\Nd100SintranNd500BootHarnessTests.cs, pack D:\BIGDISK0-L-CPUSTAT.IMG, real SINTRAN over the 3022 (the C# MON emulation layer answered nothing - asserted).

No code body: this call has no worker in any carved segment - there is no .ASM and no .pseudo.c here on purpose. Fabricating one would be wrong; the table below documents the absence instead. The manual short name is GSWSP; no such symbol appears in any carved segment's symbol table.
Bytes live once in the canonical segment layer: ../../segments-ref/ (segment 030-S3SM5, load base 40000B).

Dispatch path¶

flowchart LR
    A["ND-500 program<br/>CALLG GetScratchSegment,3,...<br/>(37B9 + 422B)"] --> B["ND-500 monitor entry<br/>MCNO = 422B"]
    B --> C["S3SM5 0x60 vector table<br/>slot 0x0284 = 40502B"]
    C -.slot = 0x0000, no handler.-> D["serviced elsewhere<br/>(ND-100 back-end, UNCONFIRMED)"]
    class A blue
    class B,C teal
    class D green
    classDef blue fill:#E3F2FD,stroke:#0D47A1,color:#0D47A1
    classDef teal fill:#E0F7FA,stroke:#00838F,color:#00838F
    classDef green fill:#E8F5E9,stroke:#2E7D32,color:#2E7D32

The dashed hop (C -> D) is where a real call would jump to its handler word. For MON 422B that word is 0x0000, so no jump target exists inside 030-S3SM5. Where the call is actually serviced is not carved here (see Honest caveats).

Code location (dispatch path)¶

030-S3SM5 holds a numeric MON-dispatch vector table based at byte offset 0x60. The slot for MON number N is at byte 0x60 + 2*N (with N the decimal value of the octal MON number). Byte offset -> segment word address = load base 40000B + (offset / 2) words.

Role	Segment (full disasm)	Addr / slot (octal)	Byte offset (dec)	Symbol	Verdict
ND-500 monitor entry (numeric dispatch, `MCNO=422B`)	- (uncarved ND-500 resident)	n/a	n/a	ND-500 MON entry	UNVERIFIED
S3SM5 `0x60` vector slot for 422B	030-S3SM5.asm - .hex	word `40502B` (slot `0x0284`)	644	(empty)	VERIFIED empty (`0x0000`)
Worker body	none in `030-S3SM5`	n/a	n/a	expected ND-100 back-end (`GSWSP`, not located)	UNVERIFIED

Slot byte offset = 0x60 + 2*422B = 96 + 548 = 644 (dec) = 0x0284. Canonical binary: ../../../segments/030-S3SM5.bin.

Verify by hand: grep '^644 ' ../../segments-ref/030-S3SM5/030-S3SM5.hex -> byte 644 000 (and 645 000); then dd if=../../../segments/030-S3SM5.bin bs=1 skip=644 count=2 2>/dev/null | od -An -tx1 -> 00 00 (the empty slot). For contrast, the populated MON 410B slot at byte 624 reads ba e1.

Instruction walkthrough¶

There are no instructions to walk - the vector slot is data (0x0000), not a jump target, so no worker body was carved and there is no .ASM.

What the dispatch would do for a populated neighbour: the ND-500 monitor takes the MON number, indexes the 0x60 table, and transfers to the 16-bit handler word found there. Slots 410B-421B hold real handler words (e.g. 410B -> ba e1, 421B -> bf cf); slots 422B-427B are all 0x0000, i.e. no S3SM5 handler for the GetScratchSegment / CopyCapability / process family. MON 422B is the first of those empty slots.

Vector-table dump (byte offsets, 16-bit words) for the fix/process family:

410B off 624 = ba e1     420B off 640 = be 0f
411B off 626 = bb 38     421B off 642 = bf cf
412B off 628 = 98 dd     422B off 644 = 00 00   <-- GetScratchSegment
413B off 630 = bb 73     423B off 646 = 00 00
414B off 632 = bb 9e     424B off 648 = 00 00
415B off 634 = bc 20     425B off 650 = 00 00
416B off 636 = bd 70     426B off 652 = 00 00
417B off 638 = bd f6     427B off 654 = 00 00

Parameter / register contract¶

From the manual (ND-860228.2 EN, p.462) and Developer/MON/calls/422B_GetScratchSegment.yaml; not byte-proven here because no handler was located.

Field	Dir	Meaning	Verdict
call form	in	ND-500 `CALLG GetScratchSegment, 3, ...` (`37B9 + 422B`)	manual (inferred)
`SizeInBytes`	in	`INTEGER` - segment size in bytes	manual (inferred)
`LogSegmentNo`	in	`INTEGER` - logical segment number to use; `0` = system picks first free	manual (inferred)
`RetLogSegmentNo`	out	`INTEGER` - logical segment number actually selected (when `0` was passed)	manual (inferred)
availability	-	user + RT programs (per manual); not ND-100 / system programs	manual (inferred)
handler slot	-	S3SM5 vector `0x0284` = `0x0000` (no ND-500 handler)	VERIFIED (bytes)

Full YAML contract: ../../../../../../../Developer/MON/calls/422B_GetScratchSegment.yaml.

Honest caveats¶

What is byte-proven: the S3SM5 0x60 vector slot for MON 422B, at byte offset 644 (segment word 40502B, slot 0x0284), reads 0x0000 in the real SINTRAN L bytes of 030-S3SM5.bin. The whole 422B-427B slot run is 0x0000, while 410B-421B hold non-zero handler words - so the empty slot is a genuine "no S3SM5 handler", not a carve artefact.

What is NOT proven: where MON 422B is actually serviced. A 0x0000 slot means "not routed to S3SM5"; the expected back-end (documented short name GSWSP) has not been located or carved - no GSWSP symbol exists in any carved segment's symbol table. Confirming the real dispatch needs a live trace of a GetScratchSegment call, or locating the ND-100 back-end that consumes it. Until then this folder correctly holds no code.

This is consistent, not contradictory: the slot is verified empty, and the worker is unverified/absent.

Method: ../../../../../EXTRACTING-RESIDENT-CODE.md - dispatch reality: ../../TASK-05-mismatches.md - master map: ../../MON-CALL-INDEX.md.