I'm working on oss-pce-cd-bios, an open-source effort to create a redistributable replacement for the PC Engine / TurboGrafx-CD System Card BIOS.
In my October 22 update, the project had eight project-defined implementations connected to its 81 candidate entry points.
As of October 29, the main branch (94ef337) has 14 DEV implementations and 67 nonreturning stubs. That's real progress in original firmware code, but it is not 14 verified System Card APIs.
There is also a new synthetic disc testbed, with an important distinction: the new media checks run on the host; they do not demonstrate successful BIOS-mediated CD boot.
Six more development ROM entries
The 256 KiB development-only ROM gained six entries since the previous article:
| Entry | DEV implementation | Scope |
|---|---|---|
EX_RND |
Random-number generation | Project-defined behavior |
MA_MUL16S |
Signed 16-bit multiplication | Original arithmetic routine and contract tests |
MA_SQRT |
Integer square root | Original integer routine |
MA_SIN |
Sine | Project-defined signed 16-bit Q15 representation |
MA_COS |
Cosine | Project-defined Q15 representation |
EX_SETWRT |
Set VDC MAWR | Development-only VRAM write-address setting |
These are entries in a project-owned implementation manifest. All 81 readiness states remain NOT_READY, regardless of whether the entry has implementation code.
The recent MA_SIN / MA_COS work in PR #527 is an example of why the details matter. The two functions use a development-specific numeric representation, with tests for input coverage, sign and rounding rules, register preservation, and unwanted memory effects. A correct sine value by itself would not establish the caller-visible reference ABI.
The latest EX_SETWRT work in PR #524 reaches beyond arithmetic. It connects slot $3A to original code that sets the Video Display Controller's MAWR (the VRAM write-address register). Its verification includes host checks, observations with a pinned Geargrafx core, and negative/mutation cases.
Those checks provide evidence about the DEV contract and the measured emulator behavior. They are not evidence that the proprietary System Card's EX_SETWRT calling convention and side effects have been reproduced in full, much less that physical hardware has been validated.
Building synthetic boot media without borrowing game data
Another merged change, PR #556, adds:
-
tools/synthetic_boot_media.py: a generator for self-authored CUE/BIN media. -
tools/synthetic_boot_oracle.py: an independent host-side parser and checker. -
tests/host/test_synthetic_boot_media.py: regression cases for supported layouts and malformed inputs.
The supported V1/V2 layouts exercise an audio track followed by a MODE1/2352 data track, including a V2 pregap. The host oracle parses the generated media independently instead of importing the generator's answers.
That separation matters. Testing only a generator against its own assumptions can miss a shared mistake; a separately implemented checker gives us a better chance of rejecting an invalid layout.
The multi-file V2M format is still unsupported. As clarified in the follow-up specification update in PR #559, these are host-side media validation results, not successful CD boot observations on the actual Geargrafx CPU core.
The project previously demonstrated guest-side SCSI READ(6) and execution of a self-authored payload copied from CD to RAM. That was a DEV diagnostic, not a callable System Card CD_READ, CD_EXEC, or full BIOS boot implementation. The new synthetic media work does not change that boundary.
Measuring firmware progress without a misleading percentage
Here is the current evidence split:
| Measurement | October 29 main |
|---|---|
| DEV ROM implementations | 14/81 |
| Remaining nonreturning stubs | 67/81 |
| Independently VERIFIED reference BIOS ABIs | 0/81 |
Owner-approved DEV_CALLABLE entries |
0 |
| Verified BIOS-mediated CD boots | 0 |
| Release eligibility | false |
The project explicitly keeps a reference-code execution gate closed. A development entry that runs under an original contract is not automatically compatible with an existing game, nor does static analysis authorize executing a proprietary reference ROM entry point.
The next work is to establish safely verified caller contracts, implement callable CD services such as CD_RESET and CD_READ, and boot a self-authored disc through actual BIOS services. Independent emulator comparison and physical-hardware verification remain future tasks.
There is no releasable replacement BIOS or demonstrated retail-game compatibility yet.
Going from eight to fourteen original entry points is useful. Keeping that progress separate from the zero verified reference ABIs is essential.
Repository: https://github.com/mao2009/oss-pce-cd-bios
Implementation status and evidence boundaries: https://github.com/mao2009/oss-pce-cd-bios/blob/main/docs/status.md
This project is independent of NEC, Hudson Soft, Konami, and other rights holders. It does not distribute proprietary BIOS images, commercial game images, or game-derived data.
Top comments (0)