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/ --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.168.21.137