David Haywood＇s MAME(tm) WIP - Road of the Hidden Bits (2013/08/14)

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 0×4000 byte region, assuming that both collision bits can be read back then 2 bits of data with a size of 256×256 occupy exactly 0×4000 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.

(Regular video)

(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)


News Source: Here