A Last Gasp of 2D: The Cave CV1000

Two-dimensional video game hardware is often considered a solved problem. Things like hardware sprites and tilemaps are basically gone; everything is done in software. Anything past that is done with 3d accelerators that work on entirely different principles. So let’s today take a look at a machine at the very end of the 2d period. And maybe also see why a straightforward platform still vexes emulator developers today. Bonus: A cool game!

The Cave CV1000

CAVE Co. Ltd., niche manufacturer of shoot-em-ups, has shown up before on this blog; they made some of the last and best titles for the IGS PolyGame Master. But that system was, even in the early 2000’s, a relic. To keep up today, CAVE needed something newer. And due to their niche market, CAVE needed something more powerful but also cheaper to manufacture. And so they licensed a new platform: the CV-1000, often just called the CAVE SH-3 hardware, whose first title, Mushihimesama, was released in October of 2004.

An earlier version of this blog post claimed that the CV-1000 was designed in-house by CAVE. Thanks to MetalliC on Twitter for the correction.

The system is powered by a 133 MHz SH-3 CPU, a predecessor of the SH-4 used in the Dreamcast and Atomiswave, so nothing cutting-edge for 2004.

And the sound chip is a YMZ770, which belongs to the same family as the YMZ774 in the IGS PGM2. Here, it’s used in a mono configuration. It’s worth noting that much like the IGS PGM2, the system is still JAMMA, even in an era where JVS was definitely becoming more dominant. Among other things, this means that it also features the sound amplifier on-board.

The video hardware is implemented on this FPGA. It’s actually a bit lower resolution than the PolyGame Master; the same number of scanlines, but fewer pixels per scanline. (But as we saw, the PGM actually has very narrow pixels) And an interesting thing about this platform is that it seems to be designed from the ground up for CAVE’s 2D, bullet-heavy shooters– only one title, Puzzle! Mushihimesamatama didn’t fall in that genre.

But first, the JTAG

Here’s a small aside. You might have noticed the system is covered in ports. For the most part, you don’t need to care about these to play the game; just plug in the JAMMA connector. That’s what JAMMA is for. But what’s, say, P4?

P4 is a JTAG connector. If you’re brave enough to do some wiring, you can attach this to a USB blaster and read or write to several of the flash memory chips onboard. Don’t think of this as an easy way to convert to other games, though:

The chips containing the sound data aren’t accessible over JTAG.

The process is agonizingly slow– 3 days to read out or write the entire U2 graphics ROM. Any interruption could break the process.

Of course, if your game has bad blocks on its U2 chip, you’ll need to manually remap the bad blocks for your new game.

I don’t think CAVE ever intended an end user to use this capability. But if you want to mess with it, GitHub user buffis has made some Python scripts to help with the process here. Don’t ask me for help– I’m too much of a coward.

The blitter

The video hardware of the CV1000 is a framebuffer setup. What this means is that there’s a place in video memory that corresponds to the screen pixels, and editing them edits what’s shown on screen. I don’t even know what the first machine to use a setup like this is; on consoles, it’s the Channel F, the first console to use interchangeable cartridges and a CPU. It was rare and noteworthy then; but not now.

The CAVE platform is all 15-bit RGB, 5 bits for each color, and 1 reserved for an alpha transparency. You can in fact extract this data directly; it’s stored in the U2 flash memory chip. Here’s some graphics I extracted; notice that there is a major difference with things like the IGS PolyGame Master and other older tile-based systems: nothing is paletted. These colors are part of the data, so there’s no limit on the number of colors per sprite, or anything like that.

To save money, the flash memory chips used by CAVE for graphics were often those that had failed quality assurance for all of its data; when that was done, the beginning of the stored data is some flash data used to remap around bad blocks. This was fine at the release date, but over time, it's common for blocks around bad flash memory blocks to also fail-- very unpleasant, given how expensive these boards can go for in the enthusiast market!

On the CAVE hardware, unlike the Channel F, the framebuffer isn’t all you get. Instead, there’s something called a blitter , implemented on the FPGA.

CAVE definitely didn’t invent the blitter– the term dates back to the 1975 Xerox Alto’s “bit blit” function. A blitter is basically a specialized form of block memory copy. The PC Engine has block memory transfer operations, and the Arcade Card works because those blocks can be efficiently copied to video RAM. But nobody calls that a blitter– because the PC...