$FDB0 (the Pascal 1.1 callee) is a RET stub — driver init lives somewhere else

5 min read
z80cpmsoftcardreverse-engineeringretrocomputingcpm-videx-series

Detail for Part 6 — The BIOS Factory.

Following up on the cold-boot generator finding. The next concrete step was to disassemble $FDB0 — the routine 2.23’s generator calls when it sees device code 6 (Pascal 1.1) — and read what code it writes into the BIOS trap-marker pages.

The routine is one byte:

$FDB0: C9              RET

That’s it. A direct call from $FB62: CALL $FDB0 returns immediately with no observable side effect. HL = $0DD0 was set by the caller before the call, but $FDB0 doesn’t read or use it.

The bytes immediately after the stub look like another routine but it isn’t reached by the device-6 path:

$FDB1: ED 43 E1 FE     LD ($FEE1),BC
$FDB5: C9              RET

$FEE1 is a state byte inside the NOP slide of the BOOT vector area. So $FDB1 is a small utility that records BC into a state slot. It’s reachable only by CALL $FDB1 from somewhere I haven’t located yet — not by falling through from $FDB0.

So the generator’s device-code-6 branch is structurally present (the CP 02 / JR NZ / LD HL,$0DD0 / CALL $FDB0 sequence is real, and is the byte-level delta from 2.20’s generator) but the callee it dispatches to is currently a stub. There’s no Pascal 1.1 driver bytes being written into BIOS by this path.

A few possible explanations:

(a) Driver install happens elsewhere. The actual Pascal 1.1 handler bytes might be written by another mechanism — perhaps the 6502 boot loader installs them during PREP_HANDOFF, or they’re already in the staged BIOS bytes that get loaded into LC RAM, with $FDB0’s stub serving only as a dispatch hook that isn’t doing real work in this configuration.

(b) Lazy init on first device use. The driver might be installed lazily on the first CONIN/CONOUT call to that device, rather than at cold-boot time. The $FDB0 stub would then be a placeholder that future code-paths overwrite with real init logic.

(c) Mid-implementation state. Microsoft might have shipped 2.23 with the architecture in place but the device-6 handler not fully wired up — relying on the dispatch table entries being valid even when the cold-boot call is a no-op. In this reading, the generator’s branch is a placeholder for a feature that’s either incomplete or completed by a different code path.

(d) HL = $0DD0 is the actual install instruction. What if the device-6 branch’s real effect is just setting HL to a Pascal-1.1-relevant pointer ($0DD0)? That value gets clobbered by the next loop iteration’s LD HL,$F3B8, so it’s not preserved across iterations — but maybe the generator runs only once per cold-boot and the call to $FDB0 is expected to consume HL. With $FDB0 as RET, nothing consumes it. So this would imply the intended $FDB0 is a real routine that uses HL, but what we have on disk is a stub.

Without running the system, I can’t disambiguate (a)-(d). What I can confirm:

  • The cold-boot generator/dispatcher at $FB3A IS real and IS the byte-level location of the 2.23 fix’s Z-80 side.
  • The generator dispatches device-code-6 to $FDB0.
  • $FDB0 as it appears in the BIOS extract is one byte: RET.
  • The dispatch tables that the BIOS device-scan uses post-cold-boot point into trap-marker pages ($FC9A, $FBC4, $FBE2, $FBD0, $FFAC, $FFB8, $FFC4, $FFD0) — those targets must be populated somewhere, since $FDB0 doesn’t populate them.

So the architectural understanding is firmer: the BIOS factory is dispatch-by-runtime-populated-tables, not just dispatch-on-static-code. The static code calls into runtime-populated regions for actual handler execution. Where the population happens for device 6 specifically — that’s the open question.

The earlier prediction in the previous devlog (“disassembling $FDB0 will tell us what code 2.23 generates for a Pascal 1.1 card”) is not what disassembly showed. Adjusting the model: the population mechanism is somewhere else, possibly the 6502 loader staging. Worth verifying by re-examining the Apple-side staging bytes that end up at LC RAM addresses corresponding to the trap-marker pages.

Status: generator dispatch structure confirmed; the $FDB0 callee is a stub; the Pascal 1.1 driver-install path is elsewhere and not yet located. Will continue with: tracing what populates $FC9A, $FBC4, $FBE2, $FBD0 between disk-load and first BIOS routine call.