RunCPM 6.9: single shared core, N:CPM telnet console (:8677), RSX bar commands

[peterkaczorowski]

Summary

• RunCPM 6.9 refactoring — consolidate the three duplicate RunCPM engines (SIO 'G', N:CPM://, telnet) into ONE shared core. runcpm_core.cpp is now the only TU that compiles the Z80/CP/M chain (external linkage); the transports are thin console back-ends that plug into it through runcpm_session.h's runcpm_console_ops, guarded by a g_busy single-instance interlock. abstraction_fujinet_core.h holds the shared disk/SD section. preTables moves the ~11 KB Z80 flag tables to flash and the consolidation reclaims ~22 KB, fixing the ESP32 dram0_0_seg overflow.
• N:CPM telnet console on port 8677 — new vm_telnet.cpp exposes a loopback TELNET server (127.0.0.1:8677) bridged through libtelnet to the shared core, so an Atari reaches CP/M via N:TELNET://127.0.0.1:8677. It is started from fn_service_loop only after lwIP is up (esp_netif_init inside fnWiFi.start); the acceptor waits for an IP and is pinned to core 0 so the priority-17 SIO loop on core 1 cannot starve it.
• RSX bar commands — new vm_bar.cpp/.h implement the VM-generic bar-command gate (|ftp, |wget, |fn, |apt, |help) wired into ccp.h via vm_bar_io trampolines built from the core's _getch/_putch/_puts, so the bar talks to whichever transport is active. Named vm_ (not cpm_) so future non-CP/M VMs can reuse the same telnet console + bar plumbing.

ESP32 hardware bring-up fixes

Found and fixed on real Atari FujiNet (fujinet-atari-v1) hardware:

• Boot loop (assert tcpip_send_msg_wait_sem ... Invalid mbox): the telnet acceptor opened a socket before lwIP existed. Moved vm_telnet_start() out of main_setup into fn_service_loop, after the WiFi/BT block, gated on the network stack being up.
• Listen-before-IP: acceptor now waits for fnWiFi.connected() before bind()/listen().
• "Port open but no CP/M banner": the priority-10 acceptor pinned to core 1 was permanently starved by the priority-17 SIO loop. Pinned the acceptor to core 0.

Test plan

• FujiNet-PC: cmake --build build --target dist links clean; nm shows a single copy of the Z80 tables (cbitsZ80Table/cbitsTable/cbits2Table).
• FujiNet-PC: telnet 127.0.0.1 8677 → CP/M banner, DIR, run a .COM, |help, clean exit.
• ESP32: ./build.sh -b links (RAM 36.7%, no dram0_0_seg overflow).
• ESP32 on hardware: boots without loop; N:TELNET://127.0.0.1:8677 reaches CP/M (banner + session); bind restored to loopback 127.0.0.1:8677.
• SIO 'G' CP/M and N:CPM:// regression on hardware.

🤖 Generated with Claude Code

[peterkaczorowski]

Closing in favour of a focused, individually-buildable stack of 3 PRs off master (per @FozzTexx's request to split this into one topic per branch):

1. RunCPM: upgrade to 6.9 and consolidate transports onto one shared core #1391 — RunCPM 6.9 + single shared stateless core
2. RunCPM: loopback TELNET console on 127.0.0.1:8677 #1392 — loopback TELNET console (127.0.0.1:8677) — stacked on RunCPM: upgrade to 6.9 and consolidate transports onto one shared core #1391
3. RunCPM: RSX-style bar-command gate for the CCP #1393 — RSX-style bar-command gate for the CCP — stacked on RunCPM: loopback TELNET console on 127.0.0.1:8677 #1392

Suggested review/merge order: #1391 → #1392 → #1393.

One note on why #1391 is two topics in one PR rather than separate "6.9 bump" and "shared-core refactor" PRs: they are inseparable. RunCPM 6.9 carries substantially more static global state than 6.5, and each CP/M transport TU keeps its own private copy via internal linkage. Five copies of 6.9's larger state overflow the ESP32 DRAM .dram0.bss by ~58 KB, so a standalone "6.9 bump" PR does not link. The shared-core consolidation is what makes 6.9 fit (back to RAM 36.8%), so the two must land together.

Each PR builds clean on fujinet-atari-v1 (RAM 36.8%) and the three together reconstruct exactly the change set from this PR.