(Kawaks / Nebula) King of Fighters 2003 News IV

[James]

Ok guys I have started this thread just for the rom status for Kawaks, Nebula, NeorageX and for the work on the p rom.

 

So please post news or some tips and keep it with the topic of this thread.

All other Topics to be posted here: http://www.1emulation.com/forums/index.php...?showtopic=4580

 

Please note anyone who post off topic will be deleted without notice!

Edited February 18, 2004 by james

[James]

well i still think we should have a good look at the mame driver for kof2003 could be a good idea.

 

 

it loads the p roms. and going by the p roms region

 

ROM_START( kof2003 )

ROM_REGION( 0x800000, REGION_CPU1, 0 )

ROM_LOAD16_WORD_SWAP( "271-p1.bin", 0x100000, 0x400000, CRC(92ed6ee3) )

ROM_LOAD16_WORD_SWAP( "271-p2.bin", 0x500000, 0x200000, CRC(5d3d8bb3) )

ROM_CONTINUE( 0x000000, 0x100000 )

ROM_CONTINUE( 0x000000, 0x100000 )

 

the rom load is weird compaired to other rom loads for neogeo.

 

and i am sure there could be some info here as well

 

static unsigned short kof2003_tbl[0x1000];

 

static READ16_HANDLER( kof2003_16_r )

{

return kof2003_tbl[offset];

}

static WRITE16_HANDLER( kof2003_16_w )

{

UINT32 bankaddress;

kof2003_tbl[offset]=(kof2003_tbl[offset]&mem_mask)|((~mem_mask)&data);

if(offset>0xff9) return;

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

*(((UINT8 *)kof2003_tbl)+0x1ff0)=0xa0;

*(((UINT8 *)kof2003_tbl)+0x1ff1)&=0xfe;

*(((UINT8 *)kof2003_tbl)+0x1ff3)&=0x7f;

neogeo_set_cpu1_second_bank(bankaddress);

*(((unsigned char *)memory_region(REGION_CPU1))+0x58196)=kof2003_tbl

[0xff9]&0xff;

}

 

DRIVER_INIT( kof2003 )

{

install_mem_read16_handler (0, 0x2fe000, 0x2fffff, kof2003_16_r);

install_mem_write16_handler (0, 0x2fe000, 0x2fffff, kof2003_16_w);

init_neogeo();

}

[cosmic_lord]

I don't use mame because I hate it... although I compiled my own version of mame32 plus to beat kof2003 on a few times.

 

Anyway, you use it james. Do you have a mslug5 driver for us to look at? I read somewhere that the rom bankings are similar, and I want to see if that's right or not.

[James]

I don't use mame because I hate it... although I compiled my own version of mame32 plus to beat kof2003 on a few times.

 

Anyway, you use it james.  Do you have a mslug5 driver for us to look at?  I read somewhere that the rom bankings are similar, and I want to see if that's right or not.

go to neomame plus website and download there source..it has the mslug5 driver.

[cosmic_lord]

ROM_START( mslug5 )

ROM_REGION( 0x800000, REGION_CPU1, 0 )

ROM_LOAD16_WORD_SWAP( "268-p1.bin", 0x000000, 0x800000, CRC(3F1CF3D2) SHA1(2C85EB5ACDEDE4816675B91F8989C9E13C1573F8) )

 

ROM_REGION( 0x20000, REGION_GFX1, 0 )

ROM_FILL( 0x000000, 0x20000, 0 )

ROM_REGION( 0x20000, REGION_GFX2, 0 )

ROM_LOAD( "sfix.sfx", 0x000000, 0x20000, CRC(354029fc) SHA1(4ae4bf23b4c2acff875775d4cbff5583893ce2a1) )

 

NEO_BIOS_SOUND_128K( "268-m1d.bin", CRC(6FA01C9A) SHA1(3DAB7593BFCCE318D22EC3DF672EE3B4AB73DCF5) )

 

ROM_REGION( 0x1000000, REGION_SOUND1, ROMREGION_SOUNDONLY )

ROM_LOAD( "268-v1.bin", 0x000000, 0x400000, CRC(C3540E0D) SHA1(BF7CA3ABE291B28A4CFAEF791F0C556CC98AD8D8) )

ROM_LOAD( "268-v2.bin", 0x400000, 0x400000, CRC(077BD2F4) SHA1(1699959D17F8C7113CEBDB9DA2E1CD18CE48486C) )

ROM_LOAD( "268-v3.bin", 0x800000, 0x400000, CRC(39B14567) SHA1(1658612A93BA30130F9260BC41D3F18F6B90C1E7) )

ROM_LOAD( "268-v4.bin", 0xc00000, 0x400000, CRC(969FF3B2) SHA1(50FECEB741A1C08B000B077A33151AB1352EB798) )

 

NO_DELTAT_REGION

 

ROM_REGION( 0x4000000, REGION_GFX3, 0 )

ROM_LOAD16_BYTE( "268-c1.bin", 0x0000000, 0x800000, CRC(27d59de8) SHA1(DE3C5CFA980CCA2FAB0416AC0D292948B5D4C9C3) ) /* Plane 0,1 */

ROM_LOAD16_BYTE( "268-c2.bin", 0x0000001, 0x800000, CRC(e600dee1) SHA1(3198EE5C7C2C7563B49EBD9F7BA95D9B0B303F6C) ) /* Plane 2,3 */

ROM_LOAD16_BYTE( "268-c3.bin", 0x1000000, 0x800000, CRC(b650f098) SHA1(99443EA4C1BAB45F1977A390EB7E1A0163915110) ) /* Plane 0,1 */

ROM_LOAD16_BYTE( "268-c4.bin", 0x1000001, 0x800000, CRC(10499589) SHA1(68A36D336582069E79AD481638D92F57C4CD6523) ) /* Plane 2,3 */

ROM_LOAD16_BYTE( "268-c5.bin", 0x2000000, 0x800000, CRC(19352405) SHA1(4AE15D29BA979601598EDDF8905072FE1D9E0A98) ) /* Plane 0,1 */

ROM_LOAD16_BYTE( "268-c6.bin", 0x2000001, 0x800000, CRC(bbec8745) SHA1(86A6C036BF51AF516FEA83A30874026EC1586A83) ) /* Plane 2,3 */

ROM_LOAD16_BYTE( "268-c7.bin", 0x3000000, 0x800000, CRC(fe2c1338) SHA1(30F3280FE527098ECF46541CC645A59B366105EA) ) /* Plane 0,1 */

ROM_LOAD16_BYTE( "268-c8.bin", 0x3000001, 0x800000, CRC(ecce3141) SHA1(B5D0D81D5CC624538B0651C568295E578A1330D1) ) /* Plane 2,3 */

ROM_END

 

ROM_START( mslug5nd )

ROM_REGION( 0x800000, REGION_CPU1, 0 )

ROM_LOAD16_WORD_SWAP( "268-p1.bin", 0x000000, 0x800000, CRC(3F1CF3D2) SHA1(2C85EB5ACDEDE4816675B91F8989C9E13C1573F8) )

 

ROM_REGION( 0x20000, REGION_GFX1, 0 )

ROM_FILL( 0x000000, 0x20000, 0 )

ROM_REGION( 0x20000, REGION_GFX2, 0 )

ROM_LOAD( "sfix.sfx", 0x000000, 0x20000, CRC(354029fc) SHA1(4ae4bf23b4c2acff875775d4cbff5583893ce2a1) )

 

NEO_BIOS_SOUND_128K( "268-m1d.bin", CRC(6FA01C9A) SHA1(3DAB7593BFCCE318D22EC3DF672EE3B4AB73DCF5) )

 

ROM_REGION( 0x1000000, REGION_SOUND1, ROMREGION_SOUNDONLY )

ROM_LOAD( "268-v1.bin", 0x000000, 0x400000, CRC(C3540E0D) SHA1(BF7CA3ABE291B28A4CFAEF791F0C556CC98AD8D8) )

ROM_LOAD( "268-v2.bin", 0x400000, 0x400000, CRC(077BD2F4) SHA1(1699959D17F8C7113CEBDB9DA2E1CD18CE48486C) )

ROM_LOAD( "268-v3.bin", 0x800000, 0x400000, CRC(39B14567) SHA1(1658612A93BA30130F9260BC41D3F18F6B90C1E7) )

ROM_LOAD( "268-v4.bin", 0xc00000, 0x400000, CRC(969FF3B2) SHA1(50FECEB741A1C08B000B077A33151AB1352EB798) )

 

NO_DELTAT_REGION

 

ROM_REGION( 0x4000000, REGION_GFX3, 0 )

ROM_LOAD16_BYTE( "268-c1d.bin", 0x0000000, 0x800000, CRC(969C0D62) SHA1(DE3C5CFA980CCA2FAB0416AC0D292948B5D4C9C3) ) /* Plane 0,1 */

ROM_LOAD16_BYTE( "268-c2d.bin", 0x0000001, 0x800000, CRC(C69AE867) SHA1(3198EE5C7C2C7563B49EBD9F7BA95D9B0B303F6C) ) /* Plane 2,3 */

ROM_LOAD16_BYTE( "268-c3d.bin", 0x1000000, 0x800000, CRC(D7BEAEAF) SHA1(99443EA4C1BAB45F1977A390EB7E1A0163915110) ) /* Plane 0,1 */

ROM_LOAD16_BYTE( "268-c4d.bin", 0x1000001, 0x800000, CRC(E1B1131B) SHA1(68A36D336582069E79AD481638D92F57C4CD6523) ) /* Plane 2,3 */

ROM_LOAD16_BYTE( "268-c5d.bin", 0x2000000, 0x800000, CRC(2FA1A5AD) SHA1(4AE15D29BA979601598EDDF8905072FE1D9E0A98) ) /* Plane 0,1 */

ROM_LOAD16_BYTE( "268-c6d.bin", 0x2000001, 0x800000, CRC(6DE89589) SHA1(86A6C036BF51AF516FEA83A30874026EC1586A83) ) /* Plane 2,3 */

ROM_LOAD16_BYTE( "268-c7d.bin", 0x3000000, 0x800000, CRC(97BD0C0A) SHA1(30F3280FE527098ECF46541CC645A59B366105EA) ) /* Plane 0,1 */

ROM_LOAD16_BYTE( "268-c8d.bin", 0x3000001, 0x800000, CRC(C0D5BC20) SHA1(B5D0D81D5CC624538B0651C568295E578A1330D1) ) /* Plane 2,3 */

ROM_END

 

 

add this to the driver DRIVER_INIT section

 

int ms5_bank_offset = 0;

 

static WRITE16_HANDLER( mslug5_calc_bankoffset_w )

{

ms5_bank_offset = (data>>12)%0x03;

}

 

static WRITE16_HANDLER( mslug5_bankswitch_w )

{

neogeo_set_cpu1_second_bank( (neogeo_ram16[0x10/2] + ms5_bank_offset) << 20 );

}

 

DRIVER_INIT( mslug5 )

{

neogeo_fix_bank_type = 1;

kof2000_neogeo_gfx_decrypt(0x19);

 

install_mem_write16_handler(0, 0x2ffff0, 0x2ffff1, mslug5_bankswitch_w);

install_mem_write16_handler(0, 0x2ffff2, 0x2ffff3, mslug5_calc_bankoffset_w);

 

init_neogeo();

}

 

DRIVER_INIT( mslug5nd )

{

/* the S data comes from the end fo the C data */

{

int i;

int tx_size = memory_region_length(REGION_GFX1);

int rom_size = memory_region_length(REGION_GFX3);

 

UINT8 *src = memory_region(REGION_GFX3)+rom_size-tx_size;

UINT8 *dst = memory_region(REGION_GFX1);

 

for (i = 0;i < tx_size;i++)

dst = src[(i & ~0x1f) + ((i & 7) << 2) + ((~i & >> 2) + ((i & 0x10) >> 4)];

}

 

install_mem_write16_handler(0, 0x2ffff0, 0x2ffff1, mslug5_bankswitch_w);

install_mem_write16_handler(0, 0x2ffff2, 0x2ffff3, mslug5_calc_bankoffset_w);

 

init_neogeo();

}

 

GAMEB( 2003, mslug5, neogeo, neogeo, neogeo, neogeo, mslug5, ROT0, "SNK Playmore Helmet2003", "Metal Slug 5" )

GAMEB( 2003, mslug5nd, mslug5, neogeo, neogeo, neogeo, mslug5nd, ROT0, "SNK Playmore Helmet2003", "Metal Slug 5 (decrypted C)" )

 

Here's the driver for mslug5, can anyone verify that it's correct?

Edited February 3, 2004 by cosmic_lord

[cosmic_lord]

Is it possible to write a program that does the following:

 

1. Create a list, with p2_2.bin, p2_1.bin, p1_4.bin, p1_3.bin, p1_2.bin, p1_1.bin as elements of this list. I'll call this list A to avoid confusion.

2. Randomly select a file from this list, and remove it from list A and add it to a new list, list B.

3. Randomly select a file from the remaining files in list A and add it as the second term in list B. Repeat this process until list A is empty and list B has all of list A's terms, but arranged randomly.

4. Open the command prompt and execute 'copy /bin "p2_4.bin" + "list B term 1" + "list B term 2" + "list B term 3" + "list B term 4" + "list B term 5" + "list B term 6" "test.rom" but with the filenames instead of list B term x.

5. (My nebula folder is located in Emulators\Nebula\ from the desktop where I keep the p files) Add test.rom to Emulators\Nebula\roms\kof2003t.zip; copy test.rom's CRC and store it as the variable C. Create text from kof2003t.dat in your romdata folder, but for the test.rom CRC, input A and save this output file to Emulators\Nebula\romdata\kof2003t.dat

6. Open Nebula and run kof2003t.

7. If Nebula has an error (which it usually does when u put the test.rom file's CRC in instead of 0), then the program will repeat itself over again, but since the list B was generated randomly, it will do a different chain of files, but this chain always starts with p2_4.bin. If no error occurs, the program will stop.

 

I have done a lot of programming in BASIC, and a little with javascript and ActionScript (in Flash). I know most of this is possible, I'm not sure about steps 5 and 6, particularly 6. I think this would be a pretty simple program. But where these values would be generated randomly it would probably have to run for a long time before it got the right combination... but if somebody else knows how to do it and make it remember and avoid what combinations it took, it would go a lot faster.

 

Maybe I'm just crazy, but I think this could be done mostly in BASIC, so I'm sure that anyone who knows an advanced language could do this without trouble, I'm just not sure that steps 5 and 6 can be done with programming.

[cosmic_lord]

All I can tell from looking at those drivers is that there are at least some similarities... like the cpu1 in the rom start for both kof2003 and mslug5. I don't use mame unelss I have to, so I really don't know how to read these too well. That's more your dept I think james.

 

Bah. It aggrovates the hell out of me that I can't figure this damn thing out.

[cosmic_lord]

Here's a quick question:

 

In this line of a dat file for example, I'll use kof2003

 

271-p1.bin,0,400000,crc,0

 

What do those two single 0's represent? I know the 400000 is the size of the p file, and the crc is the crc, but what are the other two? I think these are important questions, because I was looking over the beginning of the 2003 driver for mame.

 

According to that, a dat file for kof2003 would be like

 

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

271-p2.bin,500000,200000,5d3d8bb3

 

I left off the typical,0 at the end there, because I think the

 

ROM_CONTINUE( 0x000000, 0x100000 ) part might have something to do with it. Maybe it would be like this

 

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

271-p2.bin,500000,200000,5d3d8bb3,0,100000

 

I'm not sure, but I've never seen that ROM_CONTINUE thing before, so it must do something different when writing a dat file liek that. Anyway, one thing that strikes me about the mame driver, is the p2 file. It lists the p2 file's size as 200000, but still gives it the same CRC as the p2 file I have is, and that file has a size of 400000. If that's right, I think two of the p2 files are unnecessary, but I already tried adding p2_1 + P2_2 and then p2_2 + p2_1, and the file didn't have the same CRC as the original p2 file, so I'm going to try all teh combinations I can of 2 files.

[ugenn]

to consmic lord:

 

Hi, I have written a PHP script that does a permutation of all 720 possible combinations (I'l post this here if anybody wants). The main problem is, as you have mentioned, steps 6 and 7, particularly step 7. Step 7 requires that nebula or whatever emu be able to return error status to the environment/command shell.

An alternative solution is to try to calculate the CRC within the script itself. Problem is I do not know this algorithm. If somebody who's reading this knows how the CRC value is calculated by nebula and is willing to explain the algo here, I might be able to implement this in the script.

[cosmic_lord]

I'm on windows XP, and what I meant by Nebula having an errror, when I load a bad p rom or something it comes up with one of those error report dialogs, and nebula closes when I click on don't report.

 

Normally when it does that, Nebula goes to "Not Responding" status in the task manager, maybe it would be possible to use that in some way, I don't know.

 

If worse comes to worse, I guess you make the program omit the part about checking it in nebula, and have it rename test.rom to liek 1.rom and then when it repeats itself, to 2.rom and so on, so you owuld have output p files to test. I know there would be like 720 of them, but you could sit there for a few hours and test them one by one with nebula yourself, that way you could see if each one worked or not. If you don't want to do that, if you can configure the script to do what i said you can send it to me and I will when I have time.

[N3oGhost]

well when doing these tests (ive done about 8/720) lol........i use KAWAX (xbox emulator)

 

i renamed all roms to match kof99p (protototype) and have hexed it to look for the 7mb p1 and 512kb m rom.

 

this is the test emu.

 

when i create a new test rom. I simply delete the p rom from the zip and add the new test rom from the zip.

 

log into xbox, delete rom then upload test rom........load emu and test.

 

i dont need to rewrite any dat file or anything since it doesnt check for crcs.

 

all i end up with is the GRID of DEATH screen.

like i said though, ive only tried 8 configurations.

also with the assumption that the 7th 1mb piece is the 1st part of the rom (as it seems it should be)

 

so as you all test on winkawaks, im testing on kawax and it would be nice to have all the roms ready to choose so i can just plug em in and fire em up.

[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?