MAD-65

Firmware

The two OS ROMs · version V0.9, build 260911

A MAD-65 has two processors and each boots from its own 16 kB ROM. Together they are the console's operating system: everything a game can do without having to write its own drivers. Drawing, music and input routines are there to be called, and the protocol between the two processors is kept safely out of sight — a game never has to touch it.

Both ROMs are copied into RAM at boot and run from there at full speed, because an EPROM cannot keep up with a 14.318 MHz 65C02. The slow reads happen once and never again.

Download the firmware ROMs

ZIP archive, 21 kB · both images plus notes · V0.9, build 260911

You do not need this to play games — the madsim download and the C.E.T.A.S. download already contain it. This is for replacing the ROMs in an existing setup, or for burning them for real hardware.

What each ROM does

cpu_os.bin — the game side

The OS API jump table at $FF00 — 78 entries — and everything behind it: the builders that write drawing commands into the shared RAM, joystick reading, the SN76489 and YM2413 audio routines, the VGM module player, fixed-point maths and the 3-D vector library, cartridge loading and bank switching, LZ decompression for game data, and the frame loop a game hooks into.

The image is two 8 kB halves: the OS at $E000–$FFFF, and at $C000–$DFFF the built-in demo and nothing else. Once a cartridge boots the demo never runs, so those 8 kB become extra full-speed RAM for the game.

gpu_os.bin — the drawing side

The command interpreter that reads the shared RAM once a frame, and the renderers behind it: pixels, lines, circles, polygons, horizontal and vertical text, tiles, the sprite blitters at 8, 16, 32 and 64 pixels wide, solid or comb, and the background rectangle blitter with its RLE decoder — plus both fonts and the boot diagnostic.

With no cartridge fitted the pair boot into the diagnostic demo, which exercises sound, vector graphics, scrolling text and the joystick ports, and prints each ROM's build stamp on screen. Its music is an original theme by Maro Szczerski.

Using them

With the simulator. Drop both files into the roms\ folder next to madsim.exe, replacing what is there. They are picked up on the next run.

On real hardware. Burn each image to its own 16 kB device — a 27C256 EPROM or a 28C256 flash — and fit it in the ROM socket of the matching board: cpu_os.bin on PCB1, gpu_os.bin on PCB2. Both map to $C000–$FFFF on their own bus. The reset vector lives at $FFFC, which is file offset $3FFC.

The two ROMs are a matched pair. They talk to each other over the shared RAM with a protocol that has changed over time, so do not mix a CPU ROM from one release with a GPU ROM from another.

The three numbers

Firmware carries three numbers that are deliberately not the same thing, and knowing which is which saves confusion in a bug report.

Firmware versionV0.9 — maintained by hand, bumped when the firmware gains something worth announcing. Shown on the diagnostic screen as MAD-65 PROTOTYPE V0.9.
Build stamp260911YYMMDD, regenerated automatically at every assembly and drawn on the boot screen as GPU OS: and CPU OS:. This is the number to quote in a bug report.
OS API ABIv1, frozen — the jump table is append-only. Retired calls keep their slot as a no-op instead of being removed, so a cartridge built against any V0.x firmware keeps working. This number moves only on a breaking change.

What is planned

V0.9Current, and still open. Opened by the vertical (TATE) text opcodes, and now also carrying the comb sprite, the polygon family, CIRCLE16 and the transport block. The comb background arrived with that last one, so the rotate-90 asset script is the only thing still wanted under this number — specified in Future Features.
V1.0After a successful bring-up on real hardware. No boards have been built yet.

History

Short notes. The full changelog is in the download.

The GPU OS from nothing to a usable drawing engine: pixels, lines, circles, text, sprites.