Skip to content

Cave CV1000

Cave's arcade board (2004-2012), the platform for the house shmups: DoDonPachi DaiFukkatsu, Mushihimesama Futari, Deathsmiles, Espgaluda II… A compact single board built on an SH-3, with an FPGA blitter and the game stored in NAND flash. A darling of danmaku fans.

Identification

Field Value
Manufacturer Cave
Years 2004 → 2012
Variants CV1000-B · CV1000-D
Media game in NAND flash (single board, not trivially swappable)
I/O JAMMA / JVS
Orientation often TATE (vertical), 240×320

Architecture

Block Chip Clock Role
CPU Hitachi SH-3 (SH7709S) high CPU + 2D logic
Video custom blitter (FPGA) draws sprites by block copy; the slowdown is part of the game's timing
Sound Yamaha YMZ770C ("AMMSL") compressed samples (music + SFX)
Storage NAND flash (game data) decompressed into RAM at boot (~20-30 s boot, black screen is normal)
Backup battery-backed SRAM + RTC settings + high scores (+ clock)
Display often 15 kHz (some games 31 kHz) TATE orientation

Cave's single-board platform. Two hardware revisions: CV1000-B (the vast majority of titles) and CV1000-D (late games, e.g. DoDonPachi SaiDaiOuJou, with more memory).

The "blitter delay" (a preservation detail)

The FPGA blitter draws each sprite by copying blocks, and its work duration is baked into the game's timing: the famous danmaku slowdown is not a bug but a deliberate consequence of blitter load. In emulation, MAME must reproduce that delay precisely — otherwise the games run too fast. A textbook case where "accurate emulation" means emulating the slowdowns too.

Battery & partial 'suicide'

The battery only backs up settings/scores/clock (not the game, which is in flash): a dead battery won't brick the board, but wipes the scores/settings (and may ask you to reset the clock at boot). Replace the battery preventively — no risk of losing the game as on a CPS-2.

Region

Some games are region-locked (internal setting): the same title can show a different mode/label per region. Not suicide encryption — just a parameter.

Notable games

Mushihimesama Futari (2006), DoDonPachi DaiFukkatsu (2008, + Black Label), Deathsmiles (2007, + MegaBlack Label), Espgaluda II (2005), Muchi Muchi Pork! (2007), Pink Sweets (2006), Ibara (2005), Akai Katana (2010), Deathsmiles II… and DoDonPachi SaiDaiOuJou (2012, CV1000-D), the platform's last big title.

Don't confuse them: DoDonPachi Dai-Ou-Jou, Ketsui and Espgaluda (the first one, 2002-2003) run on IGS PGM, the platform Cave used before the CV1000.

Faults & preservation

Symptom Likely cause Lead
Lost settings / scores Flat SRAM battery Replace the battery (the game stays, in flash)
Game runs "too fast" (emulation) Blitter delay not emulated Use an up-to-date MAME build
Corrupted sprites FPGA blitter / RAM Video diagnosis
No image after a long boot NAND→RAM boot in progress (~30 s) Wait; else check power/flash
No / degraded sound YMZ770C stage Sound diagnosis
  • Targeted recap by age (SMD electrolytics).
  • JAMMA/JVS connector contacts; community multi/preservation solutions.
  • Reference emulation: MAME (cave/cv1k.cpp).

→ Previous 68000-based Cave generation (DoDonPachi, ESP Ra.De.…): Cave 68000 converts

Modernisation & mods

The common ground for every JAMMA board

Video, power, control panel and upscalers depend on the cabinet rather than the board: everything is centralised in Modernising a cabinet. To run the board outside a cabinet (at home, on a display): supergun.

  • Battery 🟢: a save battery is fitted (settings/counters/RTC). ⚠️ On this platform, a dead battery does NOT kill the game — it is a leaking battery that corrodes traces. Check and replace it before it leaks → save batteries.
  • Flash storage 🟡: data in flash/SIMM — reprogrammable, but a failed block is permanently lost: image it before working on itPCB preservation hub.
  • Scan rate 📺: ~15.72 kHz / 60.0 Hz — standard resolution, a classic 15 kHz chassis is fine — the most common JAMMA case → tri-sync and upscalers. (Computed from the MAME sources — cave/cv1k.cpp — pixel clock ÷ htotal.)
  • FPGA / emulation: see the Emulation & FPGA section below.

Repair (technician)

  • Backup battery (SRAM + RTC): keeps settings / high scores / clock → a flat battery = lost scores (and RTC), not a game fault. Remove/replace if it leaks (backup batteries).
  • ~20-30 s boot (black screen): normal — the game decompresses from NAND flash into RAM; don't mistake it for a fault.
  • NAND flash: a single, not-easily-swappable board — a dead block = lost data.
  • Sound: YMZ770C — diagnose the sound stage. Capacitors: recap (SMD electrolytics).

Methods: PCB fault-finding · Recap · Backup batteries · Traces & vias

DIP settings ✅

2 games on this platform, settings extracted from the MAME sources (INPUT_PORTS_START blocks). The Position column gives the switch's physical reference on the board (SW2:!3,!4 = bank SW2, levers 3 and 4) — which is what lets you set it up without the paper manual. Games are sorted by MAME set name.

DIP settings — MAME set cv1ks
Setting Position Options (default in bold)
Special Mode S2:2 Off · On
DIP settings — MAME set mmmbanc
Setting Position Options (default in bold)
PORT C Off · On
PORT D Off · On
PORT L Off · On

Check against your own board

These settings apply to the game and revision described by MAME. One title may have several DIP sets depending on region or revision, and some systems use soft-dips (settings in memory, via the test menu) rather than physical switches. In case of a discrepancy, the board's silkscreen and the test menu are authoritative.

See also: DIP reference · game manuals

Photos / assets

(To add: CV1000-B board, SH-3, FPGA blitter, NAND flash, battery.)

Sources & attribution

Review & corrections

How this space is used

Spotted a wrong value, an outdated procedure, a chip reference that does not match your board? Say so here, with what you observed (model, board revision, serial number, measurement). Every report is cross-checked against a source before anything changes — an unverifiable correction is published as “reported by …, not cross-checked” rather than silently applied.

Reading is open to everyone; posting requires signing in with Discord. Reports from the wiki's declared reviewers are handled first; anyone else's are read too, but go through a human before anything is changed.