(WIP) David Haywood's Homepage - 模擬器

2013.03.01

"All Gunpeys Blazing"

I suggested to Kale that after Cool Riders we should take a look at
another long-term non-working game, Gunpey.

The reason it hadn’t been emulated was because everybody was rather
scared of the AXELL AG-1 blitter chip, boasting some useful features
including graphic compression. Beyond that the game code is ugly, and
difficult to follow, the interrupt system was less than clear, and
previous attempts at writing the driver had resulted in something where
the game code appeared to be running super-slow, the blitter copy was
meaningless, and it wasn’t sending anything that resembled useful game
data to the video device. Basically, if you ran it in MAME over the last
couple of years you’ll have seen something like this at best. This is
the result of the ‘blitter’emulation copying some data from the roms
to the screen, it’s clearly nonsense.

http://mamedev.emulab.it/haze/pics2013/gunpey_old.png
(Gunpey in MAME as it was 2 days ago)

Tasked with this Kale set about improving the interrupt emulation, and
removing the hacks needed to run the game, while doing this he noticed
something else, while the game was said to use a blitter there was
actually also a spritelist in RAM, and tracing around the code showed
that ASCII text from the game rom was being written here as sprites.
With this in mind he changed the renderer to draw solid blocks for
these and instead we ended up with something like this.

http://mamedev.emulab.it/haze/pics2013/gunpey_old2.png
(Gunpey after Kale identified a sprite list, with solid block drawing)

Clearly a menu, the test menu. This required a little more work from
him in fixing up some broken inputs and the like, but it soon became
possible to navigate the test menu. I decided to help a bit at this
point and hook up the same fake ASCII rom we used for Cool Riders up
to the emulation, although in this case it wasn’t quite as
straightforward because the ’tile numbers’ in RAM were actually
co-ordinates, so to render them with the fake ASCII rom we had to
convert each set of co-ordinates to a character number. I did a few,
Kale filled in the rest and we ended up with this.

http://mamedev.emulab.it/haze/pics2013/gunpey_old3.png
(Gunpey with a fake ASCII rom hooked up)

Doing this presented various useful test menus, making it clear that
the OKI sound write had been hooked up to the wrong byte (I fixed
that) and that the sound banking was wrong / missing entirely (Kale
fixed that)

Now, keep in mind that the graphic rom is a 2048×2048 page of
‘textures’(a very uncommon setup for a 2D game) you might ask why we
didn’t just use the co-ordinates directly to index that page and draw
the real text. The reason is it’s not really that simple, the
co-ordinates were not references into that texture page, I did try.
That’s actually where the ‘blitter’comes in. It’s not so much a
blitter to show things on the screen, but a device to copy graphics
from the 2048×2408 page of graphic ROM to another 2048×2048 page of
RAM, which is what we’d been trying to display in years before, not
realizing it’s real purpose. The existing hookup was wrong anyway,
putting the data in the wrong places, so I hacked up a quick viewer for
that RAM, and improved the copy operations somewhat. This left us with a
page of data in RAM where there clearly seemed to be a font at one
location, as shown here.

http://mamedev.emulab.it/haze/pics2013/gunpey_font.png
(abusing the MAME tile viewer with 2048 wide tiles to
identify where a font gets copied to RAM)

Yes, that’s tiny, but remember that’s a view of an entire 2048 wide
texture page in RAM, and I could just about make out some character
like symbols over there, you need a keen eye for these things
sometimes…

I then attempted to replace the fake ASCII font with the one from this
data, leaving us with this…

http://mamedev.emulab.it/haze/pics2013/gunpey_old4.png
(Gunpey, first attempt at using the font copied from ROM to RAM)

Clearly not quite right, but at the same time it clearly IS a font as
expected. Kale did some checks, and it appeared even my new copy
operation was buggy, every texture was being copied at half-width, to
the wrong places (I’d initially made the RAM texture page 1024×2048
based on the values used by the blitter) This meant that while we were
indexing roughly the right place for the real font it couldn’t be right
until that was fixed, so after a bit of head scratching I fixed it, so
we ended up with some more readable text using the real fonts.

http://mamedev.emulab.it/haze/pics2013/gunpey_old6.png
(Gunpey with the original font hooked up properly)

Booting the game at this point resulted in something actually resembling
a game, but with many corrupt graphics. This was because our indexing was
still incorrect for anything not on the first few lines of the RAM page.
This did allow for some more fixes tho, the Demo Play text for example
showed that the hookup for X/Y size sprite size Kale had done was swapped
around (unsurprising because he only had 8×8 sprites to work with
before) That made a good reference point for a fix.

http://mamedev.emulab.it/haze/pics2013/gunpey_old7.png
(Gunpey, preliminary ingame shot, showing Demo Play text
used as a reference for another bug fix)

After a bit of work I was able to improve this, and get the game booting
with somewhat correct graphics.

http://mamedev.emulab.it/haze/pics2013/gunpey_old8.png
(Gunpey with more of the source offsets fixed)

Meanwhile Kale was fixing the palettes. The palettes are stored in the
ROM with the graphics, and copied to the RAM page in the same way as
everything else. In addition to this Kale added support for transparent
pen, and decoding of the 8bpp graphics. (The chip supports 4bpp, 6bpp,
8bpp and RGB555, but the game only seems to use 4bpp and 8bpp, although
the test mode has tests for the others) He also fixed sprite X/Y
positioning and a few other problems.

http://mamedev.emulab.it/haze/pics2013/gunpey_kaleshot_2.png
(Gunpey part way through Kale fixing some graphical issues)

At this point the game booted and you could easily identify what was
going on, but was still it had significant, and hung if left in attract
mode. Also inputs weren’t working on the I/O test screen nor properly
on the character select screen. Kale figured out this was an interrupt
problem, fixed that, and also identified the end of sprite list marker,
and fixed that, getting rid of most bad graphics. We also found things
to work better without an ‘invert bank select’ hack that had been
added earlier for the spritelist, so that was removed.

I then spent an hour or two debugging some of the remaining graphic
problems, figuring out, getting rid of some issues where graphics were
incorrectly offset (because we weren’t using enough lower bits to
index the RAM bitmap when drawing sprites) and identifying which bits
were source sizes, and which ones were zoomed sizes.

That leaves us where we are now. The majority of remaining glitches can
be attributed to a handful of things. The major one is the graphic
compression, it’s used for most backgrounds and a number of other
elements, there doesn’t seem to be an obvious bit to enable
decompression when the sprites are drawn, so it might happen during
the blits. Beyond that there are still transparency / alpha issues,
and the zooming hasn’t been hooked up. Anyway, this is what it looks
like *now*

http://mamedev.emulab.it/haze/pics2013/gunpey_new_1.png
http://mamedev.emulab.it/haze/pics2013/gunpey_new_2.png
http://mamedev.emulab.it/haze/pics2013/gunpey_new_3.png
http://mamedev.emulab.it/haze/pics2013/gunpey_new_4.png
http://mamedev.emulab.it/haze/pics2013/gunpey_new_5.png
http://mamedev.emulab.it/haze/pics2013/gunpey_new_6.png
http://mamedev.emulab.it/haze/pics2013/gunpey_new_7.png
http://mamedev.emulab.it/haze/pics2013/gunpey_new_8.png
http://mamedev.emulab.it/haze/pics2013/gunpey_new_9.png
http://mamedev.emulab.it/haze/pics2013/gunpey_new_10.png
(Gunpey as things stand now, still missing the graphic
decompression, but otherwise looking good)

Not bad for a days work on a driver that has been sitting idle in the
source for years where every previous attempt at making progress quickly
hit a brick wall. I think it’s fair to say that Kale did most of the
important work with this one, especially in getting past that initial
brick wall and identifying some vital points about the hardware, but
like Cool Riders team work was involved in getting us this far. The
compression looks interesting, the compressed data for the BanPresto
logo case shows that it might not be especially efficient, the white
fill still needs a significant number of bytes to represent it, but
we’ll see.

The actual game is most similar to the PSX version that became playable
in UME/MESS recently, I don’t know if the background data there will
be helpful / needed to decompress this, but still it’s something you
might find interesting. Obviously the hardware here is VERY different,
and strange for a (c)2000 release, an original V30 CPU being used at
that point definitely wasn’t common.
______________________________________________________________________________

來源：http://mamedev.emulab.it/haze/

--

ポーラステーション
http://perryt0517.wordpress.com/

--