I'm working on oss-pce-cd-bios, an effort to build an open-source replacement for the PC Engine / TurboGrafx-CD System Card BIOS.
My previous update focused on original HuC6280 routines and a synthetic CD-to-ADPCM DMA diagnostic. This update has a more visible milestone:
The development ROM now has eight implemented entry points out of 81 candidates, up from just one in the previous post.
That's genuine implementation progress. But it is not the same as eight compatible System Card services, and it doesn't mean any commercial CD game boots.
From standalone routines to actual DEV ROM entries
The current 256 KiB development-only image has project-owned implementations installed at these candidate jump-table slots:
| Slot | Routine | Purpose |
|---|---|---|
$1E |
EX_GETVER |
Development version response |
$3C |
EX_BINBCD |
Numeric conversion |
$3D |
EX_BCDBIN |
Numeric conversion |
$3F |
MA_MUL8U |
Unsigned 8-bit multiplication |
$40 |
MA_MUL8S |
Signed 8-bit multiplication |
$41 |
MA_MUL16U |
Unsigned 16-bit multiplication |
$42 |
MA_DIV16S |
Signed 16-bit division |
$43 |
MA_DIV16U |
Unsigned 16-bit division |
The remaining 73 slots are nonreturning stubs, not functional API implementations.
Previously, several math and conversion routines were tested only as independent components. They have now been wired into the development ROM's actual entry points and exercised under a project-defined calling convention with a pinned Geargrafx core.
The newest addition, MA_DIV16U in PR #480, checks quotient/remainder behavior, divide-by-zero handling, stack boundaries, caller interrupt/decimal flag combinations, and changes across the 8 KiB working RAM. Deliberately modified variants must be rejected for the expected reason rather than merely producing any failure.
The signed/unsigned arithmetic routines are original implementations, and their DEV-side contracts are being tested. They are not claims of compatibility with the proprietary reference System Card ABI.
Why 8/81 isn't a compatibility percentage
The project now tracks separate measurements instead of merging different kinds of evidence into one progress bar:
| Measurement | Current main |
|---|---|
| Project-defined DEV ROM entries implemented | 8/81 |
| Remaining nonreturning stubs | 73/81 |
| Reference BIOS ABIs independently VERIFIED | 0/81 |
| Owner-approved DEV_CALLABLE entries | 0 |
| Reference BIOS JSR executions permitted by the current gate | 0/81 |
| Verified BIOS-mediated CD program boots | 0 |
This distinction is important. An entry can execute and return according to our development contract without proving that a game can call it using the original System Card's parameters, registers, flags, memory layout, or error behavior.
In other words, the source code has advanced much faster than compatibility certification. The latter remains intentionally conservative.
The current status ledger documents these independent axes.
Learning about the reference BIOS without executing it
The static ABI investigation in PR #472 added a local-only auditor and evidence ledger for seven reference BIOS entry points.
Instead of jumping directly into proprietary firmware code, the audit records narrowly scoped static properties: control-flow shape, memory writes, bank-register operations, and hazards that would make an execution experiment unsafe.
One important observation is that some reference math entry points are dispatchers that change memory page registers. An apparently simple multiplication API can therefore carry hardware-visible side effects that an independent arithmetic routine does not reproduce.
A static safety classification is not permission to run the reference code. The project still blocks all 81 reference JSR entry points. No proprietary BIOS bytes, extracted code, or commercial game content were published with this work.
A guard can detect trouble too late
Another revealing experiment is PR #481, which tested a synthetic HuC6280 caller/stack contract on a pinned, unmodified Geargrafx core.
With the expected WRAM stack mapping, the test caller returned and its measured CPU state was preserved. With the stack mapped to I/O instead, the CPU's JSR and subsequent stack pushes changed VDC state before the guard detected the invalid mapping.
This demonstrates a subtle failure of the “check, then refuse” approach: checking after a side-effecting instruction cannot undo the side effect that already happened.
The result doesn't prove a production-safe guard exists. Nor is the experiment a complete I/O bus trace or a real-hardware result. It provides a reproducible counterexample that the eventual safety design must address.
What's next?
As of October 22, 2026, the goal is still a genuinely compatible and redistributable System Card implementation—not merely a development ROM with increasingly many working routines.
The immediate work is to verify caller-visible ABI contracts safely, establish testable CD services such as CD_RESET and CD_READ, and eventually boot a self-authored disc through actual BIOS services. Comparison against a second emulator and physical hardware will be needed before broader compatibility claims.
No retail game boot has been demonstrated. The reference ABI has zero VERIFIED entries. The release gate remains blocked (release_eligible: false).
Going from one to eight implemented DEV entries is meaningful progress. Keeping that separate from “eight compatible BIOS APIs” is just as important.
Repository: https://github.com/mao2009/oss-pce-cd-bios
This is an independent project, unaffiliated with NEC, Hudson Soft, Konami, or other rights holders. It does not distribute proprietary BIOS images, commercial game images, or game-derived content.
Top comments (0)