The **Akiko** chip is a custom ASIC unique to the Amiga CD32 game console (1993). It sits alongside the standard AGA chipset (Alice + Lisa + Paula) and provides three subsystems that exist in no other Amiga model:
1.**Chunky-to-Planar (C2P) conversion** — hardware-accelerated pixel format conversion
2.**CD-ROM controller** — drives the internal double-speed CD-ROM
3.**NVRAM interface** — I²C controller for the onboard serial EEPROM
Akiko is mapped at base address **`$B80000`** and occupies a 32 KB window (`$B80000`–`$B87FFE`).
## Chip Identification
Reading a longword from `$B80000` returns the Akiko ID:
```asm
move.l $B80000, d0 ; d0 = $C0CACAFE if Akiko present
cmp.l #$C0CACAFE, d0
beq .has_akiko
```
> [!NOTE]
> On non-CD32 machines, reading `$B80000` will return bus noise or trigger a bus error. Always wrap Akiko detection in an exception handler or use `graphics.library` v40+ `WriteChunkyPixels()` which auto-detects Akiko internally.
## Register Map
| Offset | Name | R/W | Description |
|---|---|---|---|
| `$B80000` | `AKIKO_ID` | R | Chip ID — returns `$C0CACAFE` |
| `$B80002` | `AKIKO_REV` | R | Silicon revision |
> The register map above is reverse-engineered from WinUAE (`akiko.cpp`) and community hardware testing. Commodore never published an official Akiko datasheet.
---
## Chunky-to-Planar (C2P) Conversion
### The Problem
The AGA chipset uses **planar** graphics — each bitplane is a separate contiguous block of memory. But most game engines (especially PC ports) render in **chunky** format — one byte per pixel in a linear framebuffer. Converting between these formats is computationally expensive on the 68020.
### How Akiko C2P Works
Akiko converts **32 chunky pixels** (8-bit each) into **8 bitplane longwords** in hardware. The CPU must feed data in and read results out — Akiko has **no DMA**; it is a register-based pipeline.
#### Conversion Protocol
```
Input: 8 longwords of chunky data (4 pixels × 8 = 32 pixels)
Output: 8 longwords of planar data (1 longword per bitplane × 8 planes)
movem.l (a1), d0-d7 ; read 8 planar longwords from Akiko
movem.l d0-d7, (a2) ; store to bitplane memory
lea 32(a2), a2 ; advance planar pointer
```
> [!WARNING]
> MOVEM to a fixed address writes all registers to the **same** address (FIFO-style), which is exactly what Akiko expects. This only works because `$B80030` is a hardware register, not normal RAM.
| CD32 + SX-32 with 68030 + Fast RAM | Benchmark both — software C2P may match Akiko |
| CD32 + 68040/060 accelerator | **Use software C2P** — CPU is 5–10× faster than Akiko's throughput |
### AmigaOS Interface
OS-compliant applications use `WriteChunkyPixels()` from `graphics.library` v40+:
```c
#include <graphics/gfx.h>
/* graphics.library auto-detects Akiko and uses it if present */
WriteChunkyPixels(
rp, /* RastPort */
xstart, ystart, /* top-left corner */
xstop, ystop, /* bottom-right corner */
chunky_array, /* source chunky pixel data */
bytes_per_row /* chunky buffer pitch */
);
```
---
## CD-ROM Controller
### Hardware
The CD32 contains a **Philips/Sony double-speed (2×) CD-ROM** drive. Unlike the CDTV (which uses a SCSI-based controller via DMAC/WD33C93), the CD32's CD-ROM is controlled **directly by Akiko** through a proprietary PIO interface.
### Drive Capabilities
| Feature | Specification |
|---|---|
| Speed | 2× (300 KB/s data, 150 KB/s audio) |
| Media | CD-ROM (Mode 1/2), CD-DA, Mixed Mode |
| Seek | ~400 ms average |
| Interface | Akiko PIO (no SCSI, no IDE) |
### CD-ROM Register Protocol
Communication with the drive is command/response based through the Akiko registers:
1.**Write command bytes** to `CDROM_TXDATA` (`$B80018`)
2.**Poll status** via `CDROM_PBXSTAT` (`$B80010`) for response availability
3.**Read response bytes** from `CDROM_RXDATA` (`$B8001C`)
4.**Read subcode** from `CDROM_SUBCDATA` (`$B80020`) for TOC/position data
### Boot from CD
The CD32 boots exclusively from CD-ROM (no floppy drive). The boot sequence:
4. The system reads the TOC and looks for a boot block (Amiga executable format)
5. If found, the boot executable is loaded and run — this is the game/application entry point
> [!NOTE]
> CD32 game discs use standard ISO 9660 with Amiga-specific boot blocks. Many titles also include CD-DA audio tracks for music, played via Akiko's CDDA passthrough.
---
## NVRAM (Non-Volatile Storage)
### Hardware
The CD32 includes a **1 Kbit (128 bytes) serial EEPROM** (typically a 93C46 or compatible) accessed via I²C bit-banging through Akiko registers.
| Parameter | Value |
|---|---|
| Type | Serial EEPROM (I²C / Microwire) |
| Capacity | 1 Kbit (128 bytes usable) |
| Interface | Akiko bit-bang (SCL/SDA via `$B80024`/`$B80028`) |
| Persistence | Battery-backed (CR2032) |
| Typical use | Game saves, system preferences, high scores |
### Access Protocol
NVRAM access requires bit-banging the I²C clock (SCL) and data (SDA) lines through Akiko registers:
```asm
; Simplified NVRAM byte read
; d0 = address (0–127)
; Set SDA as output, clock high
move.l #$01, $B80024 ; NVRAM_CTRL: configure direction
The CD32 gamepad uses a serial shift-register protocol through the standard DB9 controller port, providing 7 buttons:
| Button | Bit | Accent |
|---|---|---|
| Blue (Play) | 0 | Fire 1 / primary action |
| Red (Rewind) | 1 | Fire 2 / secondary |
| Yellow (FF) | 2 | Fire 3 |
| Green (Stop) | 3 | Fire 4 |
| Right shoulder | 4 | Shoulder R |
| Left shoulder | 5 | Shoulder L |
| Pause | 6 | Start/Pause |
Detection: the CD32 pad responds to a clock signal on pin 5 of the joystick port. Standard Atari-style joysticks ignore this signal and remain compatible.
---
## Detecting CD32 at Runtime
```c
#include <exec/execbase.h>
/* Method 1: Check Akiko ID register (hardware-level) */
BOOL has_akiko(void)
{
volatile ULONG *akiko_id = (ULONG *)0xB80000;
/* Wrap in exception handler — bus error on non-CD32 */
return (*akiko_id == 0xC0CACAFE);
}
/* Method 2: Check for CD32 via expansion.library (safer) */
