Archive for August, 2013

From time to time something really cool will show up, lost boards, prototypes, you know the story by now. Sometimes the owners feel generous and allow us to emulate their boards for them, other times they keep them locked away.

Well, an exceptionally rare board showed up a couple of weeks ago, as this post on Arcade Otaku shows. The board in question is a Taito F3 prototype board running a prototype version of Bubble Bobble 2 / Bubble Symphony. The owners / finders ‘Dsyde’ and ‘muddymusic’ were kindly emulation friendly, so the version found on his PCB will be supported in the 149u2 release. *edit* It has been pointed out to me a few times that the Jamma+ forums where Dsyde is an admin is the original source of this news :-)

As shown on the page there are many, many differences from the final version, it’s almost an entirely different game, lacking even a title screen at the point in development it comes from. Levels are different, graphics are different, enemies are different, sound and music are different, gameplay is different, stage names are different, stage selection is different, no story sequence, no high score sequence, no game logo during attract, it’s really more of a proof of concept sequel than anything close to a finished game at this point and that’s what makes it fascinating. The build date is close to a year before the final game, as you can imagine, a lot changes in one year of development, there isn’t a single rom the same as the final in terms of content.

As observed in the original thread the actual game on show here is much closer to the original Bubble Bobble than Bubble Symphony, the pacing is slower, the controls act more like they do in the original, and the music you get is a redone version of the original theme!

Here are some pictures of it running in MAME, although I suggest you check out the original thread for more information! (and say thanks to Dsyde and muddymusic while you’re at it) Other than working on how the roms should be loaded in for this prototype board layout (a trivial task) it really was no work at all on my part, I only thought I’d mention it because findings like this can give a real insight into how games developed from concept to release, plus I love Bubble Bobble (who doesn’t?)

Proto Left, Release Right







(these 3 don’t appear here in the release version at all, only the proto)

(back to levels in both)

Reminder of the day of course is to check your PCBs, if you have a PCB or access to a PCB it’s always worth dumping what’s on it to see if it matches MAME. Bubble Bobble 2 here was an obvious case because it’s a well known game and the changes were very obvious, especially to somebody who knows it, but plenty of other protos and undumped revisions might appear on the surface to be the same as the released versions; not many manufacturers used 100% unique ROM labels throughout their entire history like Sega did to make knowing easy from a glance at the board. I do wonder what some of the other boards in the piles where this was found were, for somewhere to have what appears to be a trade show demonstration version (seems too early to be a location test) of what would have been a high profile Taito project they must have had some significant ties / contacts in the industry and might have other unidentified prototype versions of things too.

One technique Seibu liked to use is encoding additional data with their tile graphics in otherwise ‘unused’ planes, I encountered this before when fixing the emulation Dynamite Duke where Seibu stored the priority data in an extra plane of the tile graphics (I do wonder if the Alpha in SPI might be done in a similar way, although it would be obvious if the maths didn’t add up so unless there has been a massive oversight I admit it’s a little unlikely)

Another technique Seibu liked to use is massive ROM based tilemaps. This technique obviously has limitations (you can’t change the tiles, so you can’t animate anything, but mean you don’t need any RAM or CPU power beyond writing scroll registers to display huge scrolling backgrounds) Actually Air Raid / Cross Shooter uses this technique along with custom ROM modules on the PCB which end up acting more like background generators containing both the graphics and tilemap definitions with no CPU access other than providing co-ordiates of the background map to draw (hence why that one isn’t emulated yet, we have no good technique for extracting the data in a non-hacky way)

This post isn’t about Air Raid tho (Kale did make some recent improvements to that, but without the graphics being dumped it’s never going to be interesting) instead it’s about another Taito / Seibu collaboration, this time the early Video Pinball title ‘Panic Road’

Panic Road employs both the techniques mentioned above, there is a single extra bit of priority data in the tile planes representing the priority of tiles vs. sprites, and the tilemaps are stored entirely in ROM.

What is unique about Panic Road compared to other Seibu devleopments is that there are 2 more bits of ‘invisible’ data in the tile planes, these are responsible for collisions and until now haven’t been understood properly.

I took another stab at this yesterday, and this time managed to come up with some good results. First of all I identified the priority bit (it hadn’t already been identified) and implemented that, leaving me with just the 2 bits of priority.

The collision readback window on the hardware was a 0x4000 byte region, assuming that both collision bits can be read back then 2 bits of data with a size of 256×256 occupy exactly 0x4000 bytes. The full area of the screen is approximately 256×256 (the edges are cut off for actual display) so that was my starting point. Turns out that this was a good theory, and the area is kind of a readback of the invisible (collision) bits of screen data although the way it interacts with the scroll register is a little strange, eventually I managed to figure it out tho.

As a result the game now appears to be playable. If anything the sprite-sprite collisions are letting it down, but those are handled entirely by the game software, so I have to assume them to be correct unless I can find a reference video of the game being played properly to prove me wrong. Actually a good reference video would be handy anyway because sprite-sprite priorities are almost certainly wrong right now. As a game it doesn’t seem to hold up very well compared to later video pinball games, the physics are horrible and the entire game seems to really revolve around you using the 100 ‘shakes’ you get per level to get the ball to go where you really want it rather than any kind of precise aiming skill. It’s no Pinball Dreams for sure!

The collision data is quite interesting, one bit of the data represents solid objects, things the ball should not pass through, the second bit represents areas where the flippers can take effect, I’m not entirely sure why this was necessary but if you return blank data for those bits in the readback the flippers simply don’t work.

I’ve used the MAME tilemap viewer to show some side-by-side shots of the level graphic data, and the collision data below, there is no separate shot for priority data as I’d already fully integrated it as hidden data in the regular level graphics by the time these shots were made. It should hopefully give a clear representation of the collision types, you can clearly see where the flippers go from the different colours collision map! This visual representation was very useful for working out the meaning of the bits.

and another level

I’ve also put together 2 videos, both are playbacks of the same MAME inp recording, one displays the regular backgrounds, the other displays the collision map data instead.

Content not available.
Please allow cookies by clicking Accept on the banner

(Regular video)

Content not available.
Please allow cookies by clicking Accept on the banner

(Collision map video)

Nothing especially complex here, it just required somebody willing to experiment a bit and a fresh pair of eyes, I dare say anybody could have actually fixed this.

As mentioned, a few things could do with verifying on the original hardware (I especially wonder what the conditions are for falling down the killer black holes in the middle of the playfield, although that could be another sprite priority issue, or depend on the speed the ball is moving)

The Dumping Union recently found a board for a game called Casanova. Some sources list this as a Promat game from 1994, but I’m not 100% convinced this is the same game and no manufacturer information is displayed.

What is known is that it runs on the same hardware as 3×3 Puzzle by Ace Enterprise (actually I didn’t know this at first, but after adding it the addresses matched up and it became obvious)

This PCB is a mess, it has a 10Mhz OSC just tacked on in the middle there with wires going to it!

Mariusz Wojcieszek fixed a few things based on new findings from this in the 3×3 Puzzle driver to get the game working once I’d identified it as that hardware.

Like 3×3 Puzzle it has few redeeming qualities. It’s a tile matching game, it has an awful pre-rendered intro featuring amateurish glitches with parts of the tilemaps not being copied correctly causing bits of the character’s hat to vanish (confirmed on the real PCB) and in addition to that the background colours inexplicably change in places between frames!

Music is just cheesy samples, and about the only noteworthy thing about the entire game is the goofy Superman character who wipes out tiles for you if you get stuck after doing a little dance to more cheesy sampled music. I’d make a video but the hardware does resolution changes and MAME can’t handle that, nor has any way I’m aware of to record a fixed resolution scaled avi for cases like that (snapsize doesn’t work for such cases)

Usual bikini girls included, maybe they strip, that would mean actually playing the game to find out tho. The game also has a number of other stupid bugs, like some of the credit modes ending up with >9 credits and corrupting the display (again happens on real hardware) This really is bottom of the barrel quality!

This is possibly a bit of a premature announcement because I don’t consider the game to be working yet but I’ve spent a large amount of the past week looking at the IGS game ‘Puzzli 2’ with some real hardware assistance from rtw.

As with almost all IGS games of this period there is an MCU on the board providing certain functions for use by the main game code. The ultimate goal is to find a way to trick the MCU into spilling out it’s internal ROM and simply emulate the ARM CPU program contained inside but in some cases that isn’t possible because the MCU is not using any commands with unchecked lookups into internal ROM.

After running a data logger on the Puzzli 2 board and watching what it wrote to and read from the device it quickly appeared Puzzli 2 was one of those cases, all functions were work on the data passed in, transform it and give it back in another format.

There are 3 main functions the Puzzli 2 MCU provides, first, descrambling of the addresses where the Z80 code is stored for sound / music, this was the first thing I hooked up after studying the logs (albeit with hardcoded addresses because the scramble isn’t clear) It was also confirmed that the device provides the correct addresses for Puzzli 2 or Puzzli 2 Super depending on which game code you have running, so clearly the addresses returned are derived from the data passed to the device at startup.

The second function is providing offsets to where graphics / palettes are stored. This is used for the random tiles shown during the intro animation and all the backgrounds. In the end this turned out to be a two step operation, the first step multiplying the two nibbles of data passed by 0x19 and 0x5, the second step being the addition of a 4-bit value to the final result.

The third, and by far most complex thing it does is descramble and decompress the level data structure for each level. Before each level starts the 68k passes in a stream of data from ROM, the MCU then applies a loop of 16 8-bit xor values to that data (from a 256 byte table, the first value passed is the 8-bit offset into that table) Having done that, in the same step (without revealing the intermediate results to the 68k) the MCU fills in a 10×8 structure for the level data as well as a few misc variables based on the input stream. The MCU is also responsible for flagging to the 68k when it has received enough data to build a level.

The level structure is then read back with another command, again with the MCU signaling when enough data has been returned based on the data passed earlier.

What this means is to simulate the protection device I had to understand the format of the source level data, and the format of the level data the game expects (sizes, object types etc.) as well as find a way to figure out the scrambling, easier said than done because you can’t see the descrambled data directly, only the final level structure after the MCU has also expanded / decompressed that descrambled data. Understanding this was by far the most time consuming part and is where work still really needs to be done.

The work done so far has however seen the game emulation improve significantly, many level structures are built correctly, although currently if I look at all the levels the game has several contain what appear to be invalid elements (if you put them in a level the level becomes impossible to finish) interestingly many of these are stripped from the Puzzli 2 Super rom, so I don’t know if they’re unused data, game bugs, or if they do something else on the level they’re meant to be used (they could also be errors in my descrambling, but the xor addresses on which they fall are confirmed with other levels so that’s unlikely)

Needless to say this is a lot of work, and while I took a lot of joy from being able to clean up and remove all the per-game simulations of the Data East 104 / 156 chips there are still cases like this where we have no choice but to simulate things (unless a way for the MCUs to be decapped becomes available)

There are also problems with my interpretation of the ‘depth’ data, I think I see where it’s passed and read but what I’m doing to it is clearly wrong, the width data passed at the same time appears to be processed correctly by the simulation. Depth is one of the level difficulty factors and it being wrong is causing the black bars at the bottom of some screens because it’s drawing everything too high up / for an easier difficulty setting.

Hopefully I can figure out the remaining issues and we can get this one marked as working in the near future. Interestingly it also points at there being a background colour register we’re not emulating on PGM, unless some of the backgrounds are just glitchy on real hardware (it happens more often on games than you’d think). Even if things aren’t fully working yet this felt like promising enough progress to mention it, and should give some insight into just how tricky even the easier cases can be sometimes. Also for those wondering Puzzli 2 Super is quite a significant upgrade, it adds the entire VS CPU mode, the regular Puzzli 2 only has a VS. mode for 2 players.

One thing I really like about this game is the music, I find many of the tunes to be catchy and perfectly fitting for a game of this kind. I don’t know if like with Bee Storm they’re not all exactly original creations but I have a feeling we might find out with time if people end up matching them to source mods ;-) The intro music I’d hope is original because it syncs up so well with the intro animation and is delightfully bouncy!

In other PGM news XingXing dumped the internal ROM of a Knights of Valor 2 Nine Dragons or ‘kov2plus’ as it’s otherwise known, that was actually next on my todo list but it looks like some time has been saved. Instead I’ll bump Puzzle Star to the #1 spot after this one is done, and hopefully figure out how that one manages the level data properly so that it’s playable beyond the first world.

*edit* after some further work I’ve made some more improvements and fixes to the emulation, including fixing the backgrounds, and what seems to be an additional region protection that was causing resets when you attempted to insert coins to continue. I’ve uploaded a video to YouTube showing gameplay plus the various attract cycles for each region at the end.

Content not available.
Please allow cookies by clicking Accept on the banner