rslr/amiga-bootcamp

Fork 0

mirror of https://github.com/alfishe/amiga-bootcamp.git synced 2026-06-12 16:16:28 +00:00

Ilia Sharin 8133b3a6cb More content added

2026-04-26 14:46:18 -04:00

13 KiB

Raw Blame History

← Home · Hardware · AGA

Akiko — CD32 Custom Chip

Overview

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:

Chunky-to-Planar (C2P) conversion — hardware-accelerated pixel format conversion
CD-ROM controller — drives the internal double-speed CD-ROM
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:

    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
`$B80004`	`AKIKO_INTREQ`	R	Interrupt request (CD subcode, C2P done)
`$B80008`	`AKIKO_INTENA`	RW	Interrupt enable mask
`$B80010`	`CDROM_PBXSTAT`	RW	CD-ROM PIO buffer/status
`$B80014`	`CDROM_FLAGS`	RW	CD-ROM control flags
`$B80018`	`CDROM_TXDATA`	W	CD-ROM command transmit
`$B8001C`	`CDROM_RXDATA`	R	CD-ROM response receive
`$B80020`	`CDROM_SUBCDATA`	R	CD subcode (Q-channel) data
`$B80024`	`NVRAM_CTRL`	RW	NVRAM I²C control (SCL/SDA direction)
`$B80028`	`NVRAM_DATA`	RW	NVRAM I²C data (SCL/SDA bit-bang)
`$B80030`	`C2P_INPUT`	W	Chunky-to-Planar input register (longword)
`$B80030`	`C2P_OUTPUT`	R	Chunky-to-Planar output register (longword)

Important

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)

Step 1 — Write 8 longwords of chunky pixels:

; a0 = source chunky buffer (32 pixels = 32 bytes, read as 8 longwords)
; Each longword contains 4 consecutive 8-bit pixels: [P0|P1|P2|P3]

    lea     $B80030, a1         ; C2P input register
    move.l  (a0)+, (a1)         ; pixels 0–3
    move.l  (a0)+, (a1)         ; pixels 4–7
    move.l  (a0)+, (a1)         ; pixels 8–11
    move.l  (a0)+, (a1)         ; pixels 12–15
    move.l  (a0)+, (a1)         ; pixels 16–19
    move.l  (a0)+, (a1)         ; pixels 20–23
    move.l  (a0)+, (a1)         ; pixels 24–27
    move.l  (a0)+, (a1)         ; pixels 28–31

Step 2 — Read 8 longwords of planar output:

; a2 = destination planar buffer (8 bitplanes × 4 bytes = 32 bytes)

    lea     $B80030, a1         ; C2P output register (same address, read mode)
    move.l  (a1), (a2)+         ; bitplane 0 (32 pixels, 1 bit each)
    move.l  (a1), (a2)+         ; bitplane 1
    move.l  (a1), (a2)+         ; bitplane 2
    move.l  (a1), (a2)+         ; bitplane 3
    move.l  (a1), (a2)+         ; bitplane 4
    move.l  (a1), (a2)+         ; bitplane 5
    move.l  (a1), (a2)+         ; bitplane 6
    move.l  (a1), (a2)+         ; bitplane 7

Optimized Loop (MOVEM)

In practice, the entire 32-pixel conversion is done with two MOVEM instructions:

; Convert 32 chunky pixels → 8 planar longwords
; a0 = chunky source, a2 = planar dest
; a1 = $B80030 (Akiko C2P register)

    movem.l (a0)+, d0-d7        ; load 32 chunky pixels (8 longwords)
    movem.l d0-d7, (a1)         ; write to Akiko C2P input
    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.

Full-Screen Conversion Example

For a 320×256 screen at 8 bitplanes (256 colors):

; Total pixels = 320 × 256 = 81,920
; Each pass converts 32 pixels → 81,920 / 32 = 2,560 passes

    lea     chunky_buffer, a0
    lea     planar_buffer, a2
    lea     $B80030, a1
    move.l  #2560-1, d7         ; loop counter

.c2p_loop:
    movem.l (a0)+, d0-d6/a3     ; 8 longwords (use a3 for 8th reg)
    movem.l d0-d6/a3, (a1)      ; write to Akiko
    movem.l (a1), d0-d6/a3      ; read planar output
    movem.l d0-d6/a3, (a2)
    lea     32(a2), a2
    dbf     d7, .c2p_loop

Performance Characteristics

Metric	Value
Pixels per pass	32
CPU cycles per pass	~80–100 (68020 @ 14 MHz)
Throughput	~1.5 MB/s (register I/O bound)
320×256×8bpp full screen	~54 ms (~18 fps standalone)

When to Use Akiko C2P

Scenario	Recommendation
Stock CD32 (68020, Chip RAM only)	Use Akiko — significantly faster than CPU-only C2P
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+:

#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:

Write command bytes to CDROM_TXDATA ($B80018)
Poll status via CDROM_PBXSTAT ($B80010) for response availability
Read response bytes from CDROM_RXDATA ($B8001C)
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:

Kickstart 3.1 initializes from ROM ($F80000)
Extended ROM at $E00000 provides cd.device and the CD filesystem
Akiko initializes the CD-ROM drive
The system reads the TOC and looks for a boot block (Amiga executable format)
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:

; Simplified NVRAM byte read
; d0 = address (0–127)

    ; Set SDA as output, clock high
    move.l  #$01, $B80024       ; NVRAM_CTRL: configure direction
    
    ; Send device address + read command via bit-bang
    ; (full protocol requires start condition, address bits, ack)
    
    ; Clock in 8 data bits
    moveq   #7, d1
.read_bit:
    bset    #0, $B80028         ; SCL high
    move.l  $B80028, d2         ; read SDA
    bclr    #0, $B80028         ; SCL low
    roxl.b  #1, d0              ; shift bit into result
    dbf     d1, .read_bit

AmigaOS NVRAM Access

The OS provides nonvolatile.library for structured NVRAM access:

#include <libraries/nonvolatile.h>

/* Store data */
StoreNV("MyGame", "SaveSlot1", save_data, data_length, TRUE);

/* Retrieve data */
APTR data = GetNV("MyGame", "SaveSlot1", TRUE);

CD32 Expansion Options

The CD32 has no standard expansion slots (no Zorro, no CPU slot, no trapdoor, no PCMCIA). Third-party units connect via the rear expansion port:

SX-1 (Paravision)

Feature	Specification
Memory	1× 72-pin SIMM (1–8 MB Fast RAM)
Storage	Internal 44-pin IDE (2.5" HDD) + external DB37 IDE
I/O	Parallel (DB25), Serial (9-pin RS232), RGB video (DB23)
Keyboard	AT-101 connector
Floppy	External DB23 floppy connector
Other	RTC (CR2032), FMV pass-through, disable switch

SX-32 / SX-32 Pro (DCE)

Feature	Specification
Memory	1× 72-pin SIMM (up to 8 MB)
Storage	Internal 44-pin IDE
I/O	Parallel (DB25), Serial (DB25), RGB (DB23), VGA (HD15)
CPU upgrade	SX-32 Pro includes 68030 socket
Other	RTC, external floppy

FMV Module (Commodore)

Feature	Specification
Function	MPEG-1 video + audio decoder (Video CD playback)
Video chip	C-Cube CL450 MPEG decoder
Audio chip	LSI Logic audio decoder
Limitation	Caps system Fast RAM at 4 MB
Compatibility	Works with SX-1 (pass-through); incompatible with SX-32

Warning

The FMV module had four hardware revisions. Early revisions (rev 1–2) are prone to overheating. If sourcing one today, look for rev 3 or later.

CD32 vs A1200 — Hardware Comparison

The CD32 is often described as "an A1200 in a console shell." The chipset is identical, but the system-level hardware differs significantly:

Feature	A1200	CD32
CPU	68EC020 @ 14 MHz	68EC020 @ 14 MHz
Custom chips	Alice + Lisa + Paula	Alice + Lisa + Paula + Akiko
Chip RAM	2 MB	2 MB
Chipset	AGA	AGA
Storage	IDE (Gayle), Floppy	CD-ROM (Akiko), no floppy
Expansion	Trapdoor (150-pin), PCMCIA	Rear port only (SX-1/SX-32)
Keyboard	Built-in	None (requires SX-1/SX-32)
Controller	Atari-style DB9 joystick	CD32 gamepad (7-button protocol)
NVRAM	None	128 bytes EEPROM (Akiko)
Gayle	Yes (IDE, PCMCIA)	No — Akiko replaces storage functions
C2P hardware	No	Yes (Akiko)
Boot media	Floppy / HDD	CD-ROM only

CD32 Gamepad Protocol

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

#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) */
#include <libraries/configvars.h>
#include <clib/expansion_protos.h>

BOOL is_cd32(void)
{
    /* Akiko autoconfig: manufacturer 0x0202, product 0x3E */
    struct ConfigDev *cd = FindConfigDev(NULL, 0x0202, 0x3E);
    return (cd != NULL);
}

References

WinUAE source: akiko.cpp — reverse-engineered register definitions (Toni Wilen)
Commodore CD32 Technical Reference (internal, partial — never publicly released)
NDK39: graphics/gfx.h — WriteChunkyPixels() prototype
NDK39: libraries/nonvolatile.h — NVRAM access API
Big Book of Amiga Hardware — CD32
English Amiga Board (EAB) — CD32 hardware discussions

13 KiB Raw Blame History Unescape Escape

Akiko — CD32 Custom Chip

Overview

Chip Identification

Register Map

Chunky-to-Planar (C2P) Conversion

The Problem

How Akiko C2P Works

Conversion Protocol

Optimized Loop (MOVEM)

Full-Screen Conversion Example

Performance Characteristics

When to Use Akiko C2P

AmigaOS Interface

CD-ROM Controller

Hardware

Drive Capabilities

CD-ROM Register Protocol

Boot from CD

NVRAM (Non-Volatile Storage)

Hardware

Access Protocol

AmigaOS NVRAM Access

CD32 Expansion Options

SX-1 (Paravision)

SX-32 / SX-32 Pro (DCE)

FMV Module (Commodore)

CD32 vs A1200 — Hardware Comparison

CD32 Gamepad Protocol

Detecting CD32 at Runtime

References

See Also

13 KiB

Raw Blame History