PC Engine CD BIOS Progress: Tested HuC6280 Routines and ADPCM DMA

I'm building oss-pce-cd-bios, an open-source project aiming for a redistributable replacement for the PC Engine / TurboGrafx-CD System Card BIOS.

In the previous update, I described reading sectors from a self-authored CD image and executing a small synthetic HuC6280 payload from RAM. Those were isolated diagnostic experiments—not CD game boot.

Since then, the focus has moved toward implementing original low-level routines and testing their actual effects in a pinned emulator core. The results are useful, but it's important to keep the boundary between a tested routine and a compatible BIOS service explicit.

Seven original routines exercised in the actual CPU core

One tangible change is a set of independent HuC6280 assembly routines. The current opt-in real-core test target covers seven:

• EX_BINBCD and EX_BCDBIN (numeric conversions)
• MA_MUL8S and MA_MUL8U (8-bit multiplication)
• MA_MUL16U (16-by-16-bit unsigned multiplication)
• MA_DIV16U and MA_DIV16S (16-bit division)

These aren't just Python models: the test harnesses execute original guest instructions with a pinned Geargrafx core and check outcomes and relevant CPU state. For example, the unsigned 16-bit division work exercises edge cases and 65,536 generated operand pairs while checking quotient/remainder invariants, register/stack behavior, and deliberately broken variants.

An additional EX_RND implementation provides an original 16-bit LFSR-based random-number routine with its own tests.

None of these standalone routines has been promoted to a caller-compatible System Card API. Their local contracts are not automatically the reference BIOS calling conventions. In particular, they are not connected to the development ROM's API jump table.

The real-core integration change records the seven-routine target; the division implementation is a concrete example.

Moving a synthetic CD sector through ADPCM DMA

The earlier CD read experiment transferred sector data into ordinary guest RAM. A newer experiment exercises a different hardware path.

A self-authored HuC6280 guest issues SCSI READ(6) through the emulated CD interface and arms ADPCM DMA via register $180B, moving data into ADPCM RAM starting at $0100. The host probe observes the resulting device state and memory; it does not perform the transfer by directly calling a host-side ADPCM write method.

The test includes both a successful transfer and a negative case where DMA is not armed. It also stores the raw observations, rechecks them against the source/build hashes and known toolchain/core versions, and verifies that twelve selected manipulations of the evidence are rejected.

That extra evidence work matters: if a result can't be reproduced or its recorded inputs can't be bound to what actually ran, a green status is much less informative.

The ADPCM DMA experiment was merged on October 21.

But the boundary remains clear: this is a device-layer transfer diagnostic. It does not implement the System Card AD_TRANS service, establish its ABI, or make the BIOS bootable.

Observing CD status and subcode-Q without claiming BIOS compatibility

Two more lines of investigation now have real-core observations.

For the CD status work, a test distinguishes a synthetic disc from no media and checks how cases such as an unrecognised disc and selection timeout are classified. For subcode-Q, the project decodes an observed $DD response and checks track/time/status information at a particular synthetic-disc location.

The real-core subcode-Q result is deliberately narrow: track 2 at LBA 66, with playing, paused, and stopped states. Other track boundaries have host-side synthetic tests, but those cases have not all been measured in the actual emulator core.

These investigations provide building blocks for future CD_STAT and CD_SUBQ work. They do not mean their reference System Card entry points have been executed or reproduced.

See the CD status diagnostic and subcode-Q diagnostic.

Making the test boundary harder to misunderstand

The default test workflow has also been clarified:

make test            # build and host-side checks
make test-real-core  # required Geargrafx integration checks
make routine-real-core  # opt-in standalone routine checks

The required CI path still runs the real-core checks; they weren't removed to make the host suite greener. The separate standalone-routine target remains opt-in rather than a required CI gate. Missing prerequisites and tests that haven't run must not be reported as passing observations.

Another diagnostic now checks all 8 KiB of working RAM around a synthetic ROM-to-RAM handoff, rejecting unexpected modifications. It does not read code from a CD or demonstrate the actual CD_EXEC API.

So how many BIOS APIs actually work?

The honest answer is still small.

The development ROM has 81 candidate API slots, and exactly one is callable as a development-only service: EX_GETVER. The other 80 slots remain nonreturning stubs. Adding independently tested arithmetic routines does not change that number.

The reference System Card ABI remains unverified. Callable CD_RESET, CD_READ, and CD_EXEC services, BIOS-mediated homebrew CD boot, commercial-game compatibility, and a releasable firmware image are still missing. The release gate remains blocked.

The distinction is the central point of this update:

A tested HuC6280 routine isn't necessarily a compatible BIOS API. A demonstrated DMA path isn't AD_TRANS. An observed CD status response isn't a finished CD_STAT service.

Still, these experiments move the project from preparing diagnostic scaffolding toward original, measured building blocks. That's the progress I want to report—without claiming a usable replacement BIOS before the evidence supports one.

If you're interested in HuC6280 assembly, firmware replacement, CD-ROM² devices, or emulator-driven verification, technical feedback is welcome.

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 data.