-
Notifications
You must be signed in to change notification settings - Fork 136
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TUTORIAL] porting romsets from hbmame #7
Comments
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 :) best regards,
|
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 : https://github.com/libretro/fbalpha/blob/f9f067906613181615aca662baafd281d169300e/src/burn/drv/neogeo/neo_run.cpp#L675 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 :
|
Nice job figuring it out :) |
@dinkc64 it's needed, but i'm just not too sure why
works and
don't. |
Oh, ok, I must have looked at the wrong code in hbmame then when I came up with that alternate init. oops :) |
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. |
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
242pfe.p2
and242pfe.p3
files).The first one is that the 2 files aren't contiguous in memory (hence the 2M padding), iirc the correct way to do this would be more like this (updated with latest version + some comments) :
@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
ROM_FILL
thing from hbmame, i think it's something like replacing data at a specific offset ? How should i deal with this in fba ?The text was updated successfully, but these errors were encountered: