CPS3 C-BIOS modernises Capcom CPS-3 arcade hardware

Capcom’s CPS-3 hardware doesn’t make life easy. The platform combines an SH-2 processor, encrypted security hardware, flash-based game storage and a boot process that depends on several tightly linked components. Change one part without understanding the rest, and the machine simply won’t start. CPS3 C-BIOS takes a sensible route around that problem. Instead of replacing the entire Capcom BIOS, it keeps the original firmware and adds carefully targeted C code where extra control makes a real difference. That choice matters. A full BIOS rewrite would mean recreating every low-level routine, including plenty that already work perfectly well. This project avoids that trap. It patches selected instructions, redirects certain tasks and lets new C routines run alongside the original code. The result feels less like a replacement and more like a modern extension.

A practical hybrid approach

Most of the original Capcom BIOS stays intact. CPS3 C-BIOS changes specific function pointers, task entries and instructions so the system can jump into custom code, perform a new operation and then return to the normal BIOS flow. The two layers share the same image and cooperate during startup.

The existing scheduler still manages key jobs such as CD verification, flash writing and game launching. The custom layer handles its own initialisation, sets up a C runtime and introduces a new menu system. It’s a smart division of labour.

The project doesn’t waste time rebuilding early boot routines or hardware setup code unless there’s a clear reason to do so. Instead, it focuses on the parts that users and hardware operators actually interact with. That keeps the codebase manageable and reduces the risk of breaking working behaviour.

A menu designed for real CPS-3 hardware

The menu doesn’t force itself into every startup. When the SIMM banks contain a valid game, the machine can boot straight into it. Hold Start during power-on, though, and the maintenance menu appears. It also opens automatically when the system can’t recognise the installed SIMM data.

From there, users can launch a game with full CD checking, boot directly from the SIMMs, change the region, rewrite game data from disc or enter Capcom’s original security cassette utility. Direct boot is one of the more useful additions.

It relies on an internal BIOS task that already exists, which means the same firmware can run on machines with or without a working CD drive. There’s no need to maintain a separate no-CD version. That makes setup simpler. It also cuts down on duplicate builds and configuration mistakes.

Better control over SIMM rewriting

The rewrite tools go well beyond the original all-or-nothing process. Users can select individual SIMM banks before writing, so the system doesn’t have to touch all six banks every time. That saves time when only part of the game data needs replacing. It also reduces unnecessary erase cycles.

The firmware supports modern NOR flash replacements from Spansion and Micron, along with the flash devices used in original CPS-3 hardware. Replacement chips use a custom AMD-style write-buffer routine, while recognised original devices continue to use Capcom’s established procedures. This split makes good sense. New hardware gets the handling it needs, while original hardware keeps using routines that already have years of proven behaviour behind them.

The code also leaves room for extra JEDEC identification entries and additional flash-writing methods. Developers can add support for other compatible devices without rewriting the entire storage system.

For multi-slot NOR boards, the firmware can work with switching designs that place several games on different areas of one flash device. In practical terms, that means faster rewrites and less wear on sections that haven’t changed.

A cleaner development workflow

CPS3 C-BIOS uses GCC and binutils configured for the big-endian SH-2 architecture. The build process runs through a container-based toolchain, which helps keep compiler versions and dependencies consistent. A wrapper script handles compilation, linking, ROM patching and optional deployment into MAME.

Python scripts perform part of the binary modification work. The original proprietary BIOS still needs to be supplied separately, so the project doesn’t bundle Capcom’s firmware. Region selection happens during the build. Available settings include Euro, Japan, Asia and USA.

The process creates an unencrypted image for the standard MAME CPS-3 boot setup and an encrypted custom image for dead-cartridge systems. That gives developers a direct path from editing the source to testing it in an emulator or preparing it for compatible hardware. No elaborate manual patching. No collection of mystery tools.

Why this project stands out

The menu is useful, but the real strength lies underneath it. CPS3 C-BIOS shows how developers can extend difficult proprietary firmware without throwing everything away. It uses precise hooks, shared control flow and a compact C environment to add features while keeping the original BIOS in charge of the jobs it already handles well. That approach makes the project valuable for CPS-3 hardware testing, MAME development and custom arcade firmware work.

It brings together direct SIMM booting, selective flash rewriting, regional control, CD-optional operation and support for newer NOR devices. Each feature solves a practical problem. The project remains highly specialised. That’s part of its appeal. It doesn’t try to turn CPS-3 into a general-purpose development board. It simply makes the platform easier to test, modify and operate, using a method that respects the hardware’s limits without being trapped by them.

Spread the love

A practical hybrid approach

A menu designed for real CPS-3 hardware

Better control over SIMM rewriting

A cleaner development workflow

Why this project stands out

MORE AMIGA & RETRO NEWS