Here are the first Work in Progress shots from The King of Fighters ’98: Ultimate Match HERO after Morten Shearman Kirkegaard and Peter Wilhelmsen dumped the internal rom.
They show that the PGM2 emulation still needs work, especially with a missing sprite enable register and screen resolution control. There is also no music at the moment, and a hardlock in attract mode.
*edit* fixed various bugs, made a video. sound is still incorrect but being worked on.
*edit2* MetalliC improved the sound emulation, it should be good now
Some pictures for the non-videoy people
This progress will be in MAME 0.193
*edit* Further bug fixes to the audio, stage music doesn’t play over intro if left in attract now.
The PGM2 system allowed for use of Memory Cards (supplied by the arcade, specific to each game / region) in order to save Character progress. Each card allows for a limited number of saves (500?) but allows you to store items, XP and money your character has acquired and reuse them between playthroughs. For the 0.193 release (or current GIT code) this is supported.
The English language version of Oriental Legend 2 does NOT have this feature (and the game is rebalanced to not require it) however the Chinese version does use it, so knowing how to use it in MAME makes sense.
Anyway, using it…
Once you get to the character select screen you’ll be presented with a 10 second timer to insert a memory card. It’s recommended you pause MAME at this point (with p)
It’s worth noting that without a memory card the bottom 2 characters are locked,you can’t move the cursor over them without inserting a memory card.
Bring up the tab menu, go to File Manager
from filemanager select ‘memcard1’
and from the next menu select ‘create’ as this will allow us to create a blank (default) memory card
Type in the name of your new memory card, with a “.pg2” extension (I used oriental2.pg2) (note, MAME is silly, so pressing p when typing pg2 will actually unpause it, so don’t take too long here)
and you’ll see that the memory card is inserted in memcard slot 1. You can now close the menu with tab
and choose your character (I chose the bottom left one that is now unlocked)
you can now enter a name, I’m not actually sure how this screen works as it’s all very Chinese.
you’ll see that you start the game as level 0, with 1500 gold.
so play it a little bit, level up, collect some gold etc.
At this point (for the purpose of our testing) allow your character to die, so that you get the Game Over message (if your character doesn’t die no progress is saved) Take note, we’re a LV01 character (progressed from LV00) and have 1521 gold pieces.
Quit MAME, reload MAME and get back to the character select screen.
You’ll be prompted with the ‘insert card’ screen you saw before, again it makes sense to pause the game here.
Bring up the tab menu, select file manager, select the first Memcard slot as before
This time, instead of selecting ‘create’ you should scroll down the file browser (or type the name of the filename previously used) and select that file
The game will take a brief moment to read the card, and tell you a value (I believe the number of writes left on the card)
It will then show you equipment you have etc.
And then you’ll be back at the game. Note, the character is ‘LV01’ (not LV00) and has 1521 gold pieces, exactly as it was left when we killed the character off earlier.
Knights of Valour 2 New Legend has a similar feature.
*edit* after some new information about the actual Card Reader came to light here are the new default card images, that include some additional ‘security data’ used as unlock passwords, current GIT requires these, old 256 byte memcard images are invalid.
fixed up some bugs in the ARM core, identified IRQ controller, located palette…
other layers aren’t yet emulated, but you can already see the palette uploads for what is running eg. the IGS logo
If you wait a while you get the ingame HUD for attract mode
located the background tilemap data, not added to video mixing yet, but can see tilemap RAM content in tilemap viewer
found sprite list. sprites use 1 rom for ‘mask’ (1bpp shape) and another for colour (5? bpp palette) Similar to PGM1, but not the same as the offsets to both are in the sprite list this time. hooked up the 1bpp mask data for now.
started hooking up colour data to the sprites, giving them detail, not quite right yet
worked out the slight scramble on the colour data
improved various things about the sprites, still some issues with y-flipped sprites tho
Metallic added preliminary sound, as I can’t demonstrate this in screenshots here’s a quick video
started adding in the background layer (priority still wrong) and fixed the y-flipped sprites. still the odd sprite issue (actually looks like the badly coloured sprite in the 2nd to last screenshot should just be hidden by the bg and never seen) sprite zoom not yet implemented either. Metallic also made further sound improvements.
emulated sprite priorities, fixed a few other sprite bugs. most (all?) the features of the video needed by Oriental Legend 2 are now emulated, so it’s looking pretty good. made a new video
added linescroll effects
although annoyingly the game still seems to crash at this point.. even with no hacks etc. I’ve seen videos of the hacked build doing this too, so bit of a mystery at this point, maybe another ARM bug?
While I came up with a crude hack to work around the above crash (which probably isn’t safe) I’ve been unable to find a real solution yet, although the game is playable past this point with the hack.
PGM2 dumping is likely to resume on Wednesday, maybe having proper dumps of some of the other titles will throw more light on the issue.
Morten Shearman Kirkegaard and Peter Wilhelmsen built an FPGA based board that plugs into the program ROM socket on a PGM2 board.
Doing this allows direct control over what the IGS036 CPU reads, and allows us to monitor all bus signals to and from the external ROM.
The hardware setup they created looks like this
With this, and existing knowledge of the encryption scheme they were able to modify the code running on the board while it was running, thus allowing their own code to be injected. Code was added to read the internal ROM space at 0x0000 to 0x3fff, as we didn’t know how the video hardware worked at this point the value read was then used as an offset to read into external rom, the bus signals were monitored meaning we could translate our external rom read offset back into the byte value for each address in the internal rom. This proved successful. Surprisingly, unlike the later PGM1 games there wasn’t even an Execute Only area on the PGM2 CPU being read (Oriental Legend 2) so they managed to get a complete dump.
All the actual dumping was done without the PGM2 board hooked up to monitor / display, but instead simply by looking at what the FPGA was sending back. (Earlier testing to get the setup built obviously did make use of an actual monitor)
Anyway, it was easy enough to see some of the startup strings in the internal ROM.
Hooking this up to MAME revealed a few things, first of all the internal ROM code really doesn’t like the ARM7/ARM9 MMU implementation; it could be different here, so for the time being I’ve disabled it if the CPU type is IGS036. That allowed a few basic devices to be hooked up, which gave the following
After that the code rather jumped into the weeds, clearly there are other ARM9 bugs in MAME, as the code flow below shows
Obviously it shouldn’t be jumping straight back into the middle of a BL (HI) / BLX (LO) combo. This one seems relatively easy to fix, it was simply adding 4 to an address where it should add 2.
Even with that fixed, the code ends up going off the rails tho. More investigation is needed, but this is a good start.
btw, if anybody has “Jigsaw World Arena” or “Puzzle of Ocha / Ochainu No Pazuru” we could do with borrowing them. They used to sell for dirt cheap relative to the other PGM2 titles at the time (around $250 – $300) but lately they haven’t been showing up for anything like that. They’re single board PGM2 games that were only distributed in Japan to the best of our knowledge. The internal ROM is different for every game, so they will need dumping using the methods outlined here. Apart from those 2 boards we have access to at least one of each other game (although AFAIK only the China regions – internal ROM controls the region)
Further note, please don’t post links to that ghastly hack of MAME with badly hacked in PGM2 support, it’s loaded with anti-debugger nasties, has no source and it doesn’t seem safe to run (it blew up my VM image) and is entirely the wrong way of going about things. The point of the work being done here is to actually get it done as it should have been done.
The Gamate is a console made by Bit Corporation, it was released around 1990 and designed to compete with the original Nintendo Gameboy offering a similar 4-shade green tinted screen which unfortunately suffered from a lot of ghosting, which combined with the rather poor response times many games have on the controls made playing it quite a frustrating experience.
It’s a Taiwanese system, and compared to others developed in the region, even many years later, it was surprisingly well built and had the potential to be fairly competitive.
MAME has had a driver for a short time now, coming from when MESS was merged in, however prior to the original MESS driver being developed around that time there were no dumps for the system due to the custom card media, and protection system that hadn’t been cracked. Once the protection had been figured out dumps arrived and MESS got a preliminary driver that ran the dumps available at the time, however as new dumps showed up the emulation was found to be lacking and didn’t see the necessary improvements to support them properly.
Kevtris had already written up a tech document about the system, and done his own FPGA based implementation of it, so with those in hand I decided to rewrite the majority of the MAME driver. As a result the MAME driver now appears to be on par with the original system, complete with many graphical errors that were also present when using original hardware, but harder to see due to the poor quality LCD screen (for example flickering sprites, wobbly status bars, badly flipped sprites etc.)
At this stage most games that were known to be released have been dumped for the system, so it seemed like a good time to improve the driver. There are some hardware features that none of the games seem to use however, and only one uses the serial link which I haven’t emulated yet (it apparently barely works even with original hardware so I’m not sure it will really work under emulation either)
From a hardware perspective the system is quite interesting, it uses a 6502 series chip, with an AY8910 clone for sound (strangely the original MAME driver had an entirely custom implementation for this)
Video is probably where the system design becomes a bit more questionable, the CPU drives 2 1bpp framebuffers which are combined to give 2bpp output, however, it can only write one framebuffer at a time (there’s a register to switch) and every read/write has an auto-increment, so to draw 4 colour graphics is tricky. There are no hardware sprites or tilemaps, it’s all done with software in the framebuffers.
There’s x and y scrolling, but they apply to the entire display so you’re left either having to erase and redraw either your backgrounds or your sprites if you don’t everything scrolling together, that can be quite demanding on the relatively weak 6502. This is why some games have wobbly status bars when scrolling, as after scrolling the status bar needs to be redrawn at a new position.
There are also 2 special ‘Window’ modes that make having a non-moving status bar easier, the most commonly used one of these allows the top 16 rows of the display to become a static, non-scrolling area taken from a different part of the video ram. This is one of the things that was previously not emulated in MAME.
The 2nd Window mode, which nothing seems to use allows for between 1 and 7 lines taken from yet another place in VRAM, although I think it also turns off vertical scrolling for the rest of the screen, so could be seen as less useful.
Anyway, what sparked my interest in fixing up this driver was a recent dump of Kiki Inland, which is a game influenced by Adventure Island / Wonderboy. The emulation was especially bad before, now it’s just bad in ways that match the original hardware.
Some screenshots for the non-videoy people. (I’ll add more later)
and some videos for people with better bandwidth.
I’ve also made some videos of some of the other games on the system, and will likely upload more to my YouTube channel in the coming days
In other, less interesting news, I updated the MAME SH3 and SH4 cores to use the SH2 recompiler, which gives the Cave SH3 / CV1K driver a speed boost on weaker hardware. Unfortunately most Naomi games don’t seem to want to boot with the recompiler enabled, so it’s still disabled on those, if you do enable it then Crazy Taxi gets a boost to around 75-80% ingame without any other driver optimizations on my system tho, which is a good start if the issues can be fixed.
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.