[Zac-Kyoti]

• What was wrong or hard: a card build's DRAM code couldn't name a ROM unit's symbol in the configurator. The configurator links the DRAM runtime before the menus place the ROM units, so their addresses don't exist yet; natively such a reference made ld refuse the build. Mute Modes' answer to the card-build ev_trig_muted (SDK: a card-build counterpart of ev_trig_muted (#777) #1312) has to live in a DRAM unit and read KEYMASK in its ROM unit, so it needs this. As agreed on SDK: a card-build counterpart of ev_trig_muted (#777) #1312, this is the first option, in its own pull request.
• What this changes:
  • The rule, the same in both builders: a reference a DRAM unit makes that no DRAM unit, platform symbol, DRAM region or declared defsym defines resolves from the ROM units' global symbols. Weak references are included; a weak one with no ROM symbol stays 0. A DRAM unit's own definition and a declared value always win. A build that linked before has no such reference (ld refused it), so nothing else changes.
  • Native: sdk/octabam/tools/build/dram_rom_refs.py, which build_bus.py applies to its DRAM link's --defsym set from _exports (the ROM units' globals, as ROM units already get them). tools/remix/ is untouched, so the reviewed pins over it don't move.
  • Configurator: resolveRomReferences in coldfire-runtime.ts. planStaticOs links the runtime provisionally (an open strong reference held at the base), places the menus (composeModuleMenus now returns romSymbols: CLONE_<key> and the globals of the units it places), then relinks with them only when a DRAM unit left a reference open. It checks the layout didn't move, since only relocated values change, so the menus' writes that name runtime addresses stay valid.
• How I checked it:
  • Same bytes from both linkers: sdk/tests/test_dram_rom_symbols.py links a ROM unit and two DRAM units natively (a strong ROM byte, a weak ROM routine, a weak absent name, a name another DRAM unit defines, a declared region name) and writes src/engine/test-fixtures/dram-rom-symbols.json. src/engine/dram-rom-symbols.test.ts resolves the same references with the configurator's rule and links GNU's bytes. Both builders resolve exactly KEYMASK and fx_hook. Without the rule, ld refuses the open reference, and so does the configurator.
  • Nothing else changes: 86 selections (every module alone with and without stock FX2, and five large mixed sets) composed on main and on this branch: menu, DSP, platform and startup writes and the DRAM runtime are byte-identical, with only the logger's build-identity text masked.
  • Packages: rebuilt in the isolated toolchain and imported. Only provenance and the source-tree fingerprint change; every package byte is identical. Tape Echo's and Euclid's standalone recipes are re-pinned to the new asset files.
  • Analog BD proofs: re-exported natively (--suite analog-bd --static-stock --vendored-sdk, 8 shards, menus precomputed with defaultChoosers): all 212 proofs identical; only builderSources (build_bus.py) and moduleSourceTreeSha256 move.
  • Builder record: sdk/infrastructure-verification/dram-rom-symbols-builder.json, with its test in test_infrastructure_regressions.py and a chain entry. Two fresh native builds of the ptable2 record's 128 selections, with main's build_bus.py and with this one: every image (98) and every refusal (30) identical.
  • npm run pr:ready: Ready.
• What the guides lacked or got wrong, and where I fixed it: nothing new for a guide yet. The rule matters once Mute Modes answers ev_trig_muted; sdk/machines/octatrack/card/README.md can then say that an answer unit may read its module's ROM state. I'll add that with the Mute Modes change.

Related to #1312 and #777.

🤖 Generated with Claude Code

[Zac-Kyoti]

@repeat98 @timhastie The configurator fix from #1312, as agreed: the DRAM link now takes the ROM units' symbols, the same rule in both builders, with the same-bytes test. Nothing changes for any existing build. Next, after #1195: the joinRuntime extension for an answer unit.

[repeat98]

Thanks Zac, this is careful work, and the same-bytes fixture from both linkers is exactly what I hoped for.

One thing before I merge. In planStaticOs the relink only runs when at least one open reference is in menus.romSymbols. If none of them is (a typo, or the answer unit linked without its ROM unit), the provisional runtime stays, and a strong reference ships pointing at the runtime base instead of being refused. Natively ld still refuses that case, and before this PR the configurator did too. Could you relink whenever runtime.romRefs.length is non-zero, so the final link refuses a missing strong reference as before, and add a test for that through planStaticOs?

A smaller note for the Mute Modes change: romSymbols leaves out the Spectrum SHPE and Tape TIME units' globals. Nothing needs them today, but a native-vs-configurator check with the real answer unit would catch any gap in the set.

[Zac-Kyoti]

@repeat98 Thanks, good catch. Both are pushed (24b7af7a):

• Relink whenever a reference is open. planStaticOs now relinks whenever runtime.romRefs is non-empty, so the final link refuses a strong reference that no ROM unit defines, as ld does natively and as the configurator did before this PR.
• Test through planStaticOs. src/engine/static-compose-rom.test.ts drives it with the fixture's DRAM unit in place of Tape Echo's package, through the real DRAM link. The steps that need a stock OS are stubbed, and the menus report the ROM symbols they would place. Three cases:
  • the ROM addresses are applied (KEYMASK and fx_hook, a weak absent name at 0);
  • a missing strong reference is refused;
  • none placed at all is refused.
    With the old condition put back, the last case fails, so the test catches exactly the gap you described.
• romSymbols now takes the Spectrum SHPE and Tape TIME units' globals too. When Mute Modes' answer lands, I'll run the native-vs-configurator check on the real answer unit, as you suggest.

I also merged main (nothing it changed touches these files, so no regeneration was needed). pr:ready says Ready.