David Haywood's Homepage
MAME work and other stuff
August 14, 2013 Haze Categories: General News. 6 Comments on Road of the Hidden Bits

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!

Panic Road Panic Road
Panic Road Panic Road

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.

Panic Road Panic Road

and another level

Panic Road Panic Road

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)


You can follow any responses to this entry through the RSS 2.0 feed.

haha I always wanted to play Panic Road. Cool stuff.

By the way a heres a random Data East question considering you were recently looking at data east stuff: Thunder Zone uses a kind of transparency effect in almost every stage of the game to create unique lighting effects, which isn’t emulated in mame. Stage 1 has the shadow on the helicopter, stage 3 is supposed to be entirely dark except for the spotlights, stage 4 has a sewer with the effect on most of the screen etc.

In mame the effects just show ugly graphic outlines and such, and in some parts like the start of stage 3 where the entire screen is supposed to be dark, the screen appears to be brighter instead.

Theres vids on nico of the game being finished on original hardware startign here: http://www.nicovideo.jp/watch/sm625248

How hard is something like this to fix in mame? I also wonder if there are any other Deco games that use the same effect? None come to my mind but the usage may be much smaller than in Thunder Zone.

Data East’s blending effects aren’t well understood and are almost always wrong.

Boogie Wings, Nitro Ball, Tattoo Assassins, Night Slashers etc. all have blending, and in every case the MAME emulation fails to match the hardware videos we have.

Proper video mixing is a difficult subject.

Nice, Panic road look different collisions, probably the Air raid game use the similar scheme in sprites-colission data

Soon Air raid and clones work with graphics soon?, with only “letters” is playable too

This 2 games was my favorites in my country

Whoa didn’t know that many games use it haha.

Fortunachan, What is your country?

In Spain it´s difficult define a single genre.

I personally think that all types of arcades worked very well.

Any people says that the Beat ’em up is the most common in Spanish Arcades. (Technos, Taito, Sega, Irem, Konami, Data East,etc….. most see games Capcom), but since 1984 I have seen all kinds of games.

@Jameson: seems like a Ville project to me…..

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.