Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
[TUTORIAL] porting romsets from hbmame #122
So i wanted to sync kof98pfe with the hbmame version (having a hack of a hack just to get it working is no good, i won't keep it in the core if it's not fixed), and i thought it would be a good idea to open an issue that might become a reference for @SumavisionQ5 or whoever who want to add support for more hacks in the future.
First, here is the original romset from hbmame :
I think there are 2 difficulties in this romset, which weren't handled correctly in the present implementation from @SumavisionQ5 (hence the modified
@dinkc64 correct me if i'm wrong, but the callback + burnloadrom thing allows to load a rom at a specific offset ? (that's what i used for the kof2k2omg hacks)
The second issue would be the
Barbudreadmon, yes, of course. This topic is a great idea! Let's go:
On patching the rom, let's take for example these:
But, let's do it in a bit differently - to learn some other methods:
UINT16* ROM = (UINT16*)Neo68KROMActive;
Let's explain a few things:
Maybe you just want to do it exactly the same way as HBMAME?
or even with memset():
memset(Neo68KROMActive + 0x701af4, 0x4e, 1);
hope this clears some things up :)
Updated the first post with latest version of the code.
Seems like it's failing on
Looks like we'll need a kludge in neo_run for this set to have it allocate the required memory for the main roms. try this:
in the driver d_neogeo, remove the extrarom stuff & change a things a bit:
.. and should be good :)
@dinkc64 got the game working with "official" kof98pfe from hbmame (see commit above), some details :
I think i understand this part, we need an allocation of 0x700000+0x020000 which is last 68k code rom offset+size, and it was previously failing because fba compute it only from file size by default (which makes me realize that maybe we are over-allocating 68k code memory for the kof2k2omg romset, it's computed 0x3bd4c1+0x400000 while we only need 0x100000+0x400000, but maybe that's not an issue ?).
I got a similar issue with the sound data roms and fixed it like this :
There are 4 roms of 0x400000 each for sound data, which is 0x1000000. However i don't understand why there was no crash with previous version of the implementation (size is the same)
I didn't understand the changes in kof98pfeInit, and actually the game will stop working (black screen after the neogeo logo) if i apply those changes (edit : actually i understand what you are trying to do now, however it's still not working for some reason). Here is the code i tried :
@dinkc64 it's needed, but i'm just not too sure why
My bad, it seems the good return value for
I think the code you looked at in hbmame is the right one.
I don't understand why, in both cases, direct access to Neo68KROMActive doesn't work for this 3rd rom, but you can backport the kof98pfe romset to standalone anyway.