Syntakt core: OS 1.40/1.42 research and boot-probe core

[nrdsrfr]

What

Stage A — docs/SYNTAKT_OS_RESEARCH.md (a2a0403e, 280593d4): static research on the owner's Syntakt OS 1.40 and 1.42 files. Tooling route (REA 6.5.0 refuses m68k targets; Ghidra 12.1.4 headless with 68000:BE:32:Coldfire used instead), container and boot chain (section 2 is the bootstrap, section 4 the RAM stage, section 7 the second ColdFire, section 8 a UI/USB MCU image new in 1.42), memory ownership map with verdicts, hook sites with per-release guards, the exact +173,824-byte growth, hardware-enforcement analysis (MMU off, ACRs too coarse), safety argument, platform decision brief, risk register and verification plan. Addresses, lengths, hashes and structure notes only.

Stage B — Syntakt core, boot-probe stage (0f126ce5):

• ELE3_DEVICES.syntakt (section 3 at 0x40000400, stage 0x40200000, flash 0x80000, 2 MB container bound).
• src/engine/elektron/syntakt.ts: SYNTAKT_DEVICE (releases 1.40 and 1.42 by hash, area sram-tail only, no SDRAM, protected ranges), the stock map, the hand-assembled boot stub and buildSyntaktBootProbe. Not registered in LINK_DEVICES (see review items).
• src/engine/elektron/stock-writes.ts: the stock-write checker (changed bytes only inside declared, guard-verified, whole-instruction, non-PC-relative sites; no overlaps; no protected ranges; tail budget and tail hook), with negative tests for every refusal.
• sdk/syntakt/core/: probe.json (hook 0x400004b2, 8 bytes, same guard in both releases), stock-map.json, interface.json (0.1, no events), boot.s, README.
• sdk/machines/syntakt/: core: started, the analysed 1.40 file added as a release (hashes only), guide with budgets and recovery. Registry regenerated.
• scripts/verify-syntakt-core-probe.mjs (local evidence only) and the docs/VERIFICATION.md entry with the build hashes.

Platform decision

Reuse elemod: same container, load and stage addresses, same guarded-site linker. Syntakt-specific: the appended tail lies inside the BSS-clear range, so the core hooks the BSS-clear entry (before the clear), not a main-init call.

Stop conditions

None applied. One range is proven free in both releases (SRAM 0x8000733c–0x80008000, 3,268 bytes); the hook is in the main OS, outside every bootstrap region; the safety argument rests on two independent static proofs; no contradictory evidence. No SDRAM region is proven free, so the linker refuses every mod with .run, .bss or .fast until the owner decides below.

Owner-review items

1. Register the Syntakt in the shared LINK_DEVICES table. The shared core builder (scripts/build-elemod-cores.mjs) assumes the Digitakt hook shape (jsr at 0x40000538) for every registered machine, so registration needs a builder change for the Syntakt's entry-jmp hook.
2. Choose and qualify an SDRAM region for mods: candidate B, 0x47fe0000–0x48000000 above a lowered initial stack (4-byte data patch at 0x400004f4, identical guard in both releases), or candidate A, the first 64 KB heap block taken at initialisation (Synthack-OS's approach; stock allocates it). Both need a hardware stress run with every sample slot loaded. The report's L9 (Synthack issue Configure the production community Worker #4) shows runtime page writes above the BSS that no CPU1 constant explains.
3. Accept the 2 MB in-OS receive buffer as the flash limit until the flash geometry is read from a unit.
4. Keep the analysed 1.40 file as a supported release. The 1.40A and 1.41 files arrived later (53178fea, report §5.1): both are relinked builds (2.6–2.7 MB of the main image differ), so the 1.40 stock map does not transfer; the P1 guard and initial SP are identical in all four releases. They match no release and are refused until each gets its own analysis run — worth doing only if units on 1.40A/1.41 must be supported without updating to 1.42.
5. No sdk block in the machine profile: the repository reads an elemod SDK as "modules can be scaffolded and built", which is false at this stage; the budgets are in the guide.

Checks

npm run check -- --base origin/main (full suite) passed locally. Local probe builds on both stock files linked, passed the checker and the container verifier; hashes in docs/VERIFICATION.md. The repository's packer stores section 3 ~80 KB more densely than Elektron's, which narrows the in-place depack margin (16,679 B on the 1.42 probe); the tail budget is 16 KB and every build is checked exactly.

Not verified

Nothing ran on a unit or in an emulator: the hook, the SRAM signature, persistence, acceptance of a recompressed section 3 (public reports only), and the FUNC + TRIG 4 DIN recovery path on the owner's unit. Hardware steps are in the report's §10.

[nrdsrfr]

phase 1 done. will report when I run the hardware tests. happy if anyone else wants to have a go

[nrdsrfr]

see https://app.dev.fast/s/bab9a246-ab91-4ccd-9994-2efa89dbb491#_wxd5DB6RZ_UknHjx_VffdF_C-YNUtvQ0A_Ne_LYZFl for a Whiteboard