loach

Posted on Oct 16

Building an Open-Source PC Engine CD BIOS: From Reading Sectors to Running Code from RAM

#opensource #programming #softwaredevelopment

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.

The initial long-term target is behavior compatible with Super System Card 3.0, using original code and third-party OSS only where its licensing and suitability have been reviewed.

The project does not have a usable replacement BIOS yet. No commercial CD title has been shown booting with it. But the development experiments have progressed from building diagnostic ROMs to reading a synthetic CD sector and executing code loaded from it.

Here's what has been established so far—and what hasn't.

Getting useful evidence from the real emulator core

The PC Engine uses a HuC6280 CPU, bank-switched memory, and a separate CD-ROM interface. A replacement System Card needs more than a ROM file with the expected size: it needs correct startup behavior, bank mapping, calling conventions, and device interactions.

I'm using a pinned build of Geargrafx as the first instrumented execution environment.

The repository now builds original diagnostic ROMs and checks actual CPU execution, including program-counter transitions, MPR (memory page register) state, stack behavior, and working RAM. There are also deliberately broken ROM variants that must fail the same checks.

The 256 KiB development image includes a scaffold for 81 candidate System Card API slots. Those entries are placeholders that stop rather than return success. None of those 81 services is implemented as a compatible BIOS API yet.

Diagnostic API scaffold and its limits

Reading 2,048 bytes from a synthetic CD

The next step was an independent, development-only HuC6280 program that drives the emulated CD-ROM² controller.

It sends a SCSI READ(6) command through the CD interface registers and transfers a MODE1 data sector to guest RAM. The verifier checks all 2,048 user-data bytes against a separately generated reference. A three-sector, 6,144-byte case is covered too.

This runs through guest HuC6280 instructions in the actual Geargrafx core, rather than copying the expected data into RAM from the host side. Cold- and warm-reset cases are checked, along with negative scenarios such as invalid addresses, damaged disc data, and interrupted transfers.

This is an important low-level milestone, but it is not the System Card CD_READ API. Its calling convention, return behavior, interrupts, retries, and compatibility with real hardware remain separate work.

CD sector-read diagnostic

A new milestone: load code from CD and execute it in RAM

The most recent experiment connects a few of these pieces into one traceable sequence.

A small, independently assembled 28-byte HuC6280 program is embedded in sector 5 of an entirely synthetic CUE/BIN image. The development ROM then:

Synthetic CD sector (LBA 5)
             |
       SCSI READ(6)
             |
   2,048 bytes into RAM
             |
   Validate payload header
             |
     Copy code to $3000
             |
      Jump to RAM code
             |
   Write observable markers
             |
 Return to diagnostic ROM
             |
       Confirm halt

The test checks the order of the actual execution checkpoints, the bytes copied into RAM, and the marker values written by the downloaded code. It also confirms the return to the diagnostic ROM and the final halt over 64 instructions.

Corrupting the payload checksum, header, or entry offset must prevent execution. Other negative tests ensure that simply reaching an expected-looking result cannot substitute for the correct execution path.

This is a custom load-and-execute experiment, not CD game boot. It does not implement the System Card boot process or prove that any existing game can run.

Load-and-execute implementation and evidence

The less visible work matters too

A few supporting pieces have landed alongside the ROM experiments:

Disc inspection: CUE/BIN and TOC diagnostic tools check track boundaries, INDEX 00/01, pregaps, LBA/MSF calculations, and malformed inputs using synthetic fixtures.
Bus-reset observation: a separate Geargrafx experiment measures two reset pulses through $1804 and verifies the bus is free afterward. This is not proof of the System Card CD_RESET service.
Evidence and isolation: an isolated trace harness distinguishes PASS, FAIL, BLOCKED, and SKIP instead of treating missing prerequisites as success.
Source provenance: an automated guard checks for suspicious binary or proprietary material in changes. It reduces risk but is not a legal guarantee; adopting third-party code still requires human review.

The current main-branch diagnostic CI has passed for the latest load-and-execute work. Reproducing and checking the scope of those results is part of the project, not an afterthought.

Where this goes next

A useful homebrew-CD boot path is still ahead, followed by validated System Card entry points, error handling, interrupts, and comparison against an independent emulator and eventually real hardware.

I want to keep the evidence labels precise:

A ROM that loads is not a BIOS that boots. A sector that reads is not an implemented CD_READ service. A 28-byte test program running from RAM is not commercial game compatibility.

Still, being able to follow bytes from a self-authored disc, through the guest CD interface, into RAM, and then watch the guest CPU execute those bytes is genuine progress.

If you work on HuC6280 assembly, CD-ROM² emulation, firmware replacement, or reproducible compatibility tests, I'd welcome technical feedback.

GitHub: https://github.com/mao2009/oss-pce-cd-bios

This project is independent of NEC, Hudson Soft, Konami, and other rights holders. It does not distribute proprietary BIOS images, commercial games, or game-derived disc data.

DEV Community