I'm building oss-pce-cd-bios, an original, open-source replacement project for the PC Engine / TurboGrafx-CD System Card BIOS.
My previous update covered 14 development-only routines out of 81 candidate BIOS entry points, plus a synthetic CUE/BIN generator and an independent host-side oracle.
As of November 6, 2026, the number of DEV entry points is still 14/81. The meaningful progress this week is elsewhere: the project can load and execute a multi-sector, self-authored IPL through a separate 256 KiB development image on a pinned Geargrafx core.
This does not mean the firmware can boot commercial PC Engine CD games. The loader implements a project-specific development contract, not a verified System Card ABI.
From a one-sector payload to a multi-sector IPL
The first stage was PR #669. It added a DEV-only reset-to-execution path:
- Start from RESET.
- Read a selected synthetic CD sector with guest SCSI
READ(6). - Validate a project-defined
PCEXheader on the guest. - Copy the payload to RAM at
$3000and execute it.
The test can keep the ROM byte-identical while changing the payload on disc, and observe a different result. That helps distinguish actual CD-sourced execution from a payload accidentally embedded in the ROM.
But this path only handled a single-sector payload.
PR #681 moves to a multi-sector synthetic IPL. The loader reads an information sector, validates metadata before writing to the destination, and then streams sectors through a staging area into RAM.
It handles memory page register (MPR) changes across 8 KiB windows, including test cases that cross $3FFF/$4000 and $5FFF/$6000. After copying, it reads the destination back and checks a project-defined 16-bit additive checksum before transferring control to the loaded entry point.
Malformed metadata and read failures must result in refusal rather than accidental execution. The checksum is explicitly a DEV extension, not an established commercial IPL standard, and it cannot catch every possible corruption.
Moving the same loader into the BIOS loading path
An important distinction: PR #681 originally ran on an 8 KiB HuCARD + synthetic CUE test path. That proved the guest-side multi-sector loader worked on a real pinned emulator core, but it did not prove that the image could be loaded as a System Card BIOS.
The follow-up, PR #683, packages the same loader into a separate 262,144-byte DEV image and runs it using Geargrafx's LoadBiosFromBuffer plus LoadMedia path.
The image builder checks its ROM layout, reset vector, and expected regions. The integration test checks a loader-identification CAP record so that an unexpected fallback to the HuCARD path cannot silently pass.
According to the merged PR evidence:
| Test path | Synthetic scenarios | Cold/warm executions |
|---|---|---|
| 8 KiB HuCARD + CUE (#681) | 22 | 44 |
256 KiB DEV image via LoadBiosFromBuffer (#683) |
22 | 44 |
Each path reports passing results for four positive scenarios, 15 rejection scenarios, two copy/read-failure scenarios, and one deliberately mutated-ROM readback-failure scenario.
Those are scenario executions reported for the respective changes, not 88 distinct commercial games or an independent hardware compatibility test. The readback fault is injected by changing test ROM behavior, not by simulating a real failing CD bus.
Also, the 256 KiB loader image is not the ordinary make dev-rom output promoted to a completed BIOS. It is a purpose-built development artifact used to exercise a specific boot path.
Testing the edges of HuC6280 behavior
There has also been less visible work on the surrounding verification infrastructure.
PR #610 rechecks instruction boundaries after MPR remapping. PR #614 adds a 51-case pinned-core block-transfer matrix, including lengths, page boundaries, aliases, prohibited destinations, and checks that preflight inspection doesn't mutate the MPR state.
On the observability side, PR #620 separates measured output-ring loss from capacity merely reported by the core. A value that cannot be measured reliably remains labelled NOT_MEASURED, rather than being turned into a precise-looking number.
These tests improve the evidence available to the project. They do not constitute a production-safe generic interception system or establish proprietary firmware ABI parity.
What is actually verified?
The current public status remains deliberately conservative:
| Metric | November 6 status |
|---|---|
| Project-owned DEV entry implementations | 14/81 |
| Nonreturning stubs | 67/81 |
| Independently verified reference ABI contracts | 0/81 |
Owner-approved DEV_CALLABLE entries |
0 |
| Permitted reference BIOS JSR entries | 0/81 |
| Demonstrated commercial BIOS-mediated boots | 0 |
| Firmware release eligibility | false |
No callable System Card-compatible CD_RESET, CD_BASE, CD_READ, or CD_BOOT API has been independently verified. No retail game boot, second-emulator equivalence, or physical-hardware compatibility is established.
The next steps are to establish safe, independently checked reference calling contracts and build real caller-visible CD services on top of the now-testable loading path.
It's easy to make firmware progress sound impressive by counting routines or test cases. For this project, the more useful milestone is narrower: we can observe a multi-sector synthetic payload being read, mapped, checked, and executed along a specific development boot path—and describe precisely what that evidence does not prove.
Repository: https://github.com/mao2009/oss-pce-cd-bios
Dated implementation status: https://github.com/mao2009/oss-pce-cd-bios/blob/main/docs/status.md
DEV IPL boot notes: https://github.com/mao2009/oss-pce-cd-bios/blob/main/docs/dev-ipl-boot.md
This project is independent of NEC, Hudson Soft, Konami, and other rights holders. It does not distribute proprietary BIOS images, commercial game data, or extracted copyrighted code.
Top comments (0)