(Kawaks / Nebula) King of Fighters 2003 News IV

[alphabetman]

From another forum, he doesn't state what orders he tried and which order was his best but here.

 

"look in the segment '271-p1.001' the first 00000000 to 0000d000

that piece of code right there is the same of a segment located

in the 3rd or 4th segment of the p2 just...look in the segment '271-p2.003'

goto 00053000 to 0005AFF0 and you will see what im telling you

it's the same code, exactly 0x8000 bytes, ok, with that in mind i

have done some test but all have failed, i made a LOT of testing

and my best results are this:

 

-Black screen, it keeps reseting like 1 reset per miliseconds

-Insert Coin works, and get you to th title screen

-In title screen the start button changes to 'How To play..' but at

the first instructions it freezes, and if in the test menu the 'How to play is deactivated, then you hear the selection menu BGM"

[aquasync]

I really doubt its just a matter of reordering the p roms. If it were, it would be more likely that the DRIVER_INIT section would normalize them, and then have no other special code.

This, of course, isn't the case at all. Rather, it has this fairly complicated write handling function, which is where all the work is done. It uses a table, which is never initialised, and writes + reads from it, and even writes to the p roms (...memory_region(REGION_CPU1)... = kof2003_tbl...).

I've been planning to look into this more closely, for instance to see how often the first if is satisfied in the write_handler, and whether the kof2003_tbl reaches some rest state by the end (in which case we can dump it and fix the proms with it).

However, what my point is, I don't think these roms were 'cooked'. It just seems a little overcomplicated (it might turn out simpler than i think though) - maybe this is just part of how SNK encrypted the p roms.

[skid]

Yeah, I didn't want to be the negative one, but your current course of action is not going to lead anywhere. It was based on the assumption that the p roms have been split into 1 meg parts. This is not true and the kof2003 driver does not indicate this. I'll explain why further down.

 

The trick is that kof2003 is using a different type of bank switching. The bank switch is performed by this line:

 

bankaddress=((kof2003_tbl[0xff8]>>|(kof2003_tbl[0xff9]<<)+0x100000;

 

What this piece of code means is "take the 16 bit value in address 0x2feff8 & 0x2feff9 and add 0x100000 to it to get the new bank address for CPU1 whenever a value is written to the memory between addresses 0x2fe000 & 0x2ffff9".

 

Like cosmic_lord, I was hoping that it would have used the same type of bankswitching as mslug5. But the mslug5 driver uses a different type of bankswitch:

 

bankaddress=neogeo_ram16[0x10/2] + (data>>12)%0x03;

 

Translated this means "to get the new bankaddress, read the 2nd to 4th bits of the value passed into 0x2ffff2 & 0x2ffff3 and add the value at address 0x05". This is nothing like what kof2003 is doing.

 

Even if we could unwrap the kof2003 bank switching, we'd need to translate the p rom to standard neo-geo bankswitching so that it works in kawaks, neoragex and nebula. In the standard neogeo driver, the bankswitch is performed by this line:

 

data = data&0x7;

bankaddress = (data+1)*0x100000;

 

This line means "take the bottom 3 bits of the value passed to any of the addresses between 0x2ffff0 and 0x2fffff then multiply it by 0x100000 to get the bankaddress". The standard neo-geo machine allows 8 banks.

 

And that is where I gave up hope of hacking the kof2003 p rom. I used a log and found that kof2003 has more than 1500 banks. According to the driver, kof2003 can potentially have 16777215 banks (0xffffff) by using 48 bits from ff8 and ff9. There's no way that we can fit that amount of banks into the standard neo-geo driver.

 

It might be okay if kof2003 performed some bankswitches early in the game, but it performs bankswitches throughout. The banks are also not aligned to nice boundaries (like 1 meg), I found that some "chunks" would only be 2 bytes in size.

 

It may be possible to disable most of the bankswitching, but this might require changing the memory pointers in the code. That'd be like chopping up kof2003 into really small pieces then sticky-taping it back together. Possible, but not fun.

 

I'd like to understand how the "universal" p rom for mslug5 was made. The universal rom does not seem to bear any resemblance to the original rom. Where did the universal rom originate?

 

aquasync, I first thought that the table was part of the bank lookup, but all it really is, is to simulate RAM between 0x2fe000 and 0x2fffff. The really crappy thing is that the table is not static once initialised. kof2003 writes different values into the same location in the table at different points in the game.

 

I'd love to be proved wrong and I don't claim to know everything, but I think our best chance is to sit tight and hope that the emu authors will release the emulators with new bankswitching code.

[cosmic_lord]

Well, it was just a theory, and it gave me something to try during boredom, which is better than doing nothing .

 

Anyway, I think we can all agree that the problem is in the p roms...

 

From what you just said, if you re structured the p rom in a hex editor to make it satisfy the forumla for the typical bank switch, would that not work?

 

I do believe there is something to the "cooked" part, though. The kof2003 p2 rom has the typical p1 header in it, twice.

 

Bah... why can't Nebula and Kawaks be open source?

[Agozer]

Wrong forum. Why did you double-post?

[James]

Wrong forum. Why did you double-post?

Deleted .... they were warned.

Edited February 4, 2004 by james

[cosmic_lord]

Actually double posting isn't much to him. In the other thread that we moved here from, he posted the exact same thing like 8 times in a row.

[cosmic_lord]

Allright, I looked into the question I asked earlier. Apparently, in the driver for kof2003, in the line ROM_LOADp2 etc etc, 0x500000,0x200000

 

the 500000 is the address it loads the p2 rom to in the memory region.

 

I'm not used to writing drivers so I don't know what that means, but somebody should. But still what bugs me is that the mame driver lists the p2 rom as 0x200000 for its size. The p2 rom I have (that works on mame with this driver) is 0x400000 and has the same CRC as the p2 rom the driver reports as 0x200000.

 

How? Mame must somehow dice up the p2 rom... I've tried all the combinations of 2 roms I can think of to try and get the right CRC and none of them worked, so I don't know.

 

Anyway, I was thinking, in kawaks or nebula dat files. For example, kof2003

 

271-p1.bin,0,400000,92ed6ee3,0

 

Well, from running these tests, I know that if you leave the CRC slot with a 0, nebula determines it dynamically. So, I'm assuming that the 0 following the CRC slot is the SHA1 slot, and every rom I've seen leaves it with a 0 to let it be determined dynamically because CRC is accurate enough to identify a rom. But I'm going to put in the right SHA1 values and see if it helps any, give me some feedback here people.

[aquasync]

Its not surprising that your longer p rom has the same crc. if you check, the extra length will be all 0 - thats the idea of the rom_continue parts in the mame driver.

Skid - yeah, i checked to see if the table is static, or rotates around a finite number, with a number of dumps - but it changes continually.

One big difference between kof2003 and mslug5, is the write to the p rom (only ever the same spot).

When you start the game, it has a lot of code that sort of initializes the table i found, with a fairly obvious looking pattern. From then on it just goes berserk.

[cosmic_lord]

So... are you saying that if the p2 rom was changed to be 0x200000 in size, tand still have that same crc, the ROM_CONTINUE portion would be unnecessary?

[skid]

From what you just said, if you re structured the p rom in a hex editor to make it satisfy the forumla for the typical bank switch, would that not work?

After restructuring, at least part of the rom would need to be modified so that kof2003 knows it has been restructured. For example, the part of the rom that says, "jump to point b" would need to be changed to jump to the place where the code has been moved. I don't think this would be an easy thing to do.

 

One big difference between kof2003 and mslug5, is the write to the p rom (only ever the same spot).

I think that is part of the protection. Try commenting out this line in the driver and you'll find that the game resets just before a new game is started. This is typical for what protection schemes do - they allow the demo to run but won't allow anybody to play the game. Since it is only at the one memory location, I'd guess that this should be easy to crack.

*(((unsigned char *)memory_region(REGION_CPU1))+0x58196)=kof2003_tbl[0xff9]&0xff;

I also found that mslug5 uses only 4 banks and all of the banks are at 1meg boundaries.

Edited February 6, 2004 by skid