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

The CV1000 PCB

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.

The SH3 CPU

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.

The YMZ770 sound chip

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 Altera Cyclone FPGA chip on the 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?

A port labeled 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:

  1. The chips containing the sound data aren’t accessible over JTAG.
  2. The process is agonizingly slow– 3 days to read out or write the entire U2 graphics ROM. Any interruption could break the process.
  3. 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.

Some letters with colors

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 Engine is tile-based. The blitter is designed for framebuffers, dealing with the particulars of screen video layout and transparency.

A straight line in the Amiga UI gets a jog in it because of bad deinterlacing

Probably the retro system best known for use of a blitter is Commodore’s Amiga computer. The Amiga had eight hardware sprites, but to have additional moving elements on screen, you could use what Amiga programmers call “BOBs”, blitter objects. The Amiga blitter could copy images into graphics memory. But you could also include a “mask”; areas where each pixel corresponds with a 0 in a mask aren’t copied. You can use these to build additional sprites on screen, but you have to handle clearing the background behind them as they move (oftentimes by redrawing the screen each frame), unlike hardware sprites, where you can move them “for free”.

BOBs on the Amiga deserves a post of its own, but this isn’t it. This is about the CAVE SH-3 platform, and here, everything is a BOB. Plus, transparency isn’t mask-based, instead it uses the last bit. The MAME source code documents the draw command, which blits a source area to a destination. Notice that these are squares of arbitrary size; this is just copying memory from one place to another. But because the designers of the copy device knew it’d be used for graphics, they were able to a lot of options that do some math on those bytes first.

Draw command
This command draws gfx data.
Offset Bits              Description
       fedcba98 76543210
00     0001---- -------- 0x1 for draw
       ----x--- -------- Flip X
       -----x-- -------- Flip Y
       ------x- -------- Enable Blending
       -------x -------- Enable Transparent
       -------- -xxx---- Source Blending mode
       -------- -----xxx Destination Blending mode
02     xxxxxxxx -------- Source Alpha value
       -------- xxxxxxxx Destination Alpha value
04     ---xxxxx xxxxxxxx Source X start position
06     ----xxxx xxxxxxxx Source Y start position
08     sxxxxxxx xxxxxxxx Destination X start position
0a     sxxxxxxx xxxxxxxx Destination Y start position
0c     ---xxxxx xxxxxxxx Source Width
0e     ----xxxx xxxxxxxx Source Height
10     -------- xxxxxxxx Source Red multiplication (0x80 = 100%)
12     xxxxxxxx -------- Source Green multiplication (0x80 = 100%)
       -------- xxxxxxxx Source Blue multiplication (0x80 = 100%)

Too complicated to understand these options through text? Well, just boot up today’s showcase game, Ibara, and enter the service menu’s OBJECT TEST. There, you can modify some of these in action on an example image. For example, here I’ve set the green multiplication to zero, making the source look purple.

A very busy object test screen. A large block of copied memory is purple.

Notice the sheer number of options here; while each byte is either transparent or not (if transparency is enabled), each block copy has 8-bit alpha transparency, allowing some nice mixing effects. While scaling doesn’t appear to be implemented in hardware, since this is RAM, the program can always implement that in software. The CAVE SH-3 platform is a very modern platform, taking advantage of its fast FPGA and CPU to handle everything in a way faster that hardware sprites could do.

And that’s the catch

Let’s take a platform with hardware sprites and DMA, the Nintendo Entertainment System (NES). On the NES, hardware sprites are generally configured by creating a table in the 2kiB word RAM, and then during VBLANK, uploading that entire table to memory in a DMA pass, which takes 513-4 cycles. Notice that nothing there actually depends on the amount of sprites you use. This is typical for hardware sprites. Slowdown on the NES has nothing to do with how many sprites you’re using, except that more sprites probably means your game logic is doing more.

But a blitter object is something that takes CPU time and blitter copy time for each individual BOB. This means that blitter-based systems are inherently more prone to slowdown than sprite-based systems. And, surprisingly, that’s not such a bad thing.

A boss with many large bullets on screen

This hardware was used almost exclusively for “bullet hell” shooters, known, logically enough, for the huge amounts of bullets that can be on-screen at a given time. This is considered poorly suited for hardware sprite-based systems like the NES due to strict limits on the numbers of sprites, but those huge numbers of bullets are also going to slow down the game even with a blazingly fast SH-3 CPU.

Why isn’t that so bad? It will slow down the game when there is a lot going on screen; this is exactly the time that the player will want the game to slow down. Hardware limitations give you a bullet time effect, and one that you never actually need to code for deliberately. As long as you’re just the right amount of inefficient, at least.

MAME error message. Improperly emulated features: timing

But what’s easier for the game developer is harder for the emulator developer. See, timing is tricky. Timing on a blitter implemented on a commodity FPGA (with a number of variants) and a relatively rare CPU (the MAME implementation is actually based off of the Dreamcast’s SH-4), all on a circuit board that is very expensive and not easy to run your own code on? It’s definitely not impossible. But it’s a lot of tricky work that requires a very dedicated developer with expensive equipment (the clocks on this system run fast compared to, say, the Super Nintendo) and particular skills. Until then, you’ll see this warning.

And it’s not just MAME. The PlayStation 2 port of Ibara, the only time that particular game made it out of the arcades, is known for having little to no slowdown compared to the arcade version. This makes the game much more difficult.

The game: Ibara

So the CAVE SH-3 hardware is straightforward on its surface, but surprisingly complex in the fine details. That’s also a description of the game I have on it.

Ibara title screen

Ibara, released to Japanese arcades in 2005, has an interesting history.

Its lead developer is Shinobu Yagawa, and this is his first game for CAVE: he came from prior work at Raizing/Eighting, and before that worked as a Famicom developer at KID, where he developed the legendary Summer Carnival ‘92: Recca.

Recca gameplay

Ibara isn’t very much like Recca, though– for that, you’ll want its sequel, Pink Sweets: Ibara Sorekara. Ibara takes after a title from Yagawa’s Raizing era, Battle Garegga. Garegga is one of those shooters that is downright legendary among enthusiasts, but has less visibility outside of them. Such is life in a niche genre.

Battle Garegga title screen

Ibara, according to legend, originates from CAVE founder Tsuneki Ikeda meeting with Shinobu Yagawa with a simple offer: make Garegga, but at CAVE. And that’s what Ibara is. It has the looks and music of a CAVE shooter, and in this era, that means beautiful prerendered art, and anime girls a-plenty. It also means colorful bullets that stand out across the background.

Dr Teresa in the Rose Garden

But in terms of gameplay, it’s much more Garegga than Dodonpachi. Starting the game you can hold buttons to change your character’s attributes (only two characters here, linked to 1P and 2P sides). A scoring system based off of chaining medals dropped by enemies to get higher values, but letting a medal fall break the chain. All of these systems are also completely unexplained. There’s also a surprisingly generous extra life system; an “extend” is granted every million points. And that also means rank.

A rank system is a dynamic difficulty system; in addition to the level layouts, the game becomes harder the better you are at it. It judges this by the powerups you collect, how often you shoot, and the longer you live without dying. Battle Garegga didn’t invent the concept, but it’s very aggressive here, the game can become nearly impossible. A skilled player needs to understand the rank system; and the only way to go down in rank is to die. Watch a 1cc run, and you’ll see constant suicides– not a good strategy in most shooters!

It’s probably not a game for everyone, but in 2005, shoot ‘em ups weren’t for everyone. They had a dedicated fanbase. A fanbase dedicated enough to buy PCB sets like this at home. And Yagawa was nice enough to include some features for them.

Special mode

So arcade PCBs are generally expected to be purchased by arcade operators, not game players. And that means businessmen, businessmen or repair folks who may not even be that good at the games they put on location. But I believe the supergun hobby actually started in the Japanese shoot-em-up fanbase, or at least, that was an early place for its popularity. CAVE’s PCB sets were definitely being bought by fans in 2005. And Shinobu Yagawa left them a gift.

Flip the DIP switch 2, and then hold down the “A” and “B” buttons while pressing the “TEST button”. If you did it right, you’ll see “special ver.” now listed in the test menu.

TEST MODE special ver.

The test mode of the Ibara PCB is fun enough to mess with as-is, as I showed with the object test above. But here let’s go into the GAME MODE. Right away, you’ll see a difference– the CAVE logo also features a build date, in lovely readable white-on-white text.

harware ver.20040303 00

Let’s look at the game demo.

Gameplay. There is a row of @ signs cut off at the bottom, and a number next to R at the top.

Notice the row of green @ signs at the bottom of the screen. I believe, though I’m not sure, that this is a CPU usage meter. When it maxes out is when you’d start to see slowdown. At the top of the screen, the high score alternates with this version, a display of the rank. As noted, the rank is actually a large number that is constantly decreasing. Being able to see the rank is invaluable to higher-level play.

And if you had any doubts that this was for enthusiasts, not arcade operators?

Very beginning of Ibara. A pause text is shown.

It adds the ability to pause in-game. No arcade operator would stand for that.

Markets are fickle

So, all this adds up pretty well, right? The developers of Mushihimesama and Battle Garegga join forces to create a game with the art of the former and the complexity of the latter. A lot of nice bonuses are added for enthusiasts, which is not as common to see in CAVE games that Yagawa wasn’t involved on. A recipe for huge success?

Well… no. Ibara wasn’t what CAVE fans had been waiting to see, as it played much more like a Raizing shmup. To recoup their investment, CAVE retooled the game, releasing in February 2006 Ibara Kuro: Black Label. (It succeeded an “Arrange” mode in the PlayStation 2 port that introduced some of its ideas)

Ibara Kuro black label title screen

Ibara Kuro essentially moves Ibara to be more in line with a CAVE shooter. For example, you now pick the ship you start with from a menu rather than knowing what buttons to press.

Ibara Kuro black label ship select screen.

The game itself is also quite a bit different. You can see these right away once the game starts.

Ibara Kuro gameplay, featuring a weapons bar at the bottom and a rank indicator

You can see a weapons bar at the bottom, which lets you choose between the option upgrades you’ve collected on the fly. The weapons work differently; Ibara was a 2-button game. Ibara Kuro is a 4-button, as the main weapon works a bit more like the laser/shot system in Dodonpachi. Items can fly towards your ship when you’re close as well.

Button Ibara Ibara Kuro
1 (tap) Fire Fire rapid shot
1 (hold) Autofire Fire sustained shot, move slower
2 (tap) Bomb Bomb
2 (hold) Hado-cannon Hado-cannon
3   Autofire (rapid shot)
4   Switch option configuration

You’ll also notice a rank indicator. But the rank works completely different; the rank can swing dramatically, and it’s possible to lower the rank by maxing out rank for a bonus, or by collecting roses. But it can also get a lot higher faster.

Ibara Kuro gameplay, huge numbers of bullets in stage 1

And after Ibara Kuro, Yagawa’s next CAVE titles would no longer attempt the Battle Garegga-style gameplay, though some elements, like medals and rank systems would continue to exist.

The PC always wins

Ibara was the second game released for the CV1000 platform, and followed the same configuration as the first, Mushihimesama, known as CV1000-B. Quite a few games were released on this; until 2008, when the CV1000-D upgrade was released for Deathsmiles Mega Black Label, which doubled the total video RAM. This was used until the last CV1000 titles, Akai Katana and Dodonpachi Saidaioujou.

And what do they use today? Well, uh, not much– 2012’s Dodonpachi Saidaioujou was their last unique shooter. But 2009’s Deathsmiles II was released for a unique PC-based platform. Akai Katana made it to the PC-based Type-X (as Akai Katana Shin) and Exa-Arcadia (as Crimson Katana Exa Label) platforms; Saidaioujou also came to the latter (as Dodonpachi True Death Exa Label). Is the CAVE SH-3 platform cool? Yes, I think so. The PC may always win, but do you have a cool laser-cut case for your PC?

the CAVE CV-1000 PCB now safely enveloped on top and bottom but not the sides by resin

I mean I guess technically nothing says you couldn’t make a laser-cut acrylic case for a PC…