Reverse engineering 161 in 1 cartridge to change Rom games
- Thread starter goguelnikov
- Start date
menu-c1.bin and menu-v1.bin
davidmorom
Student
I made a quick test with the default gamelist_asm and MAME and, as leonk said on the previous post, the renaming is as follows (I think the neogeo-menu build.bat should give the files already renamed, or the documentation be more clear about it):
The PatchMenu parameter should be removed cause is only needed for the original menu, to modify the games list. The alternate menu is already built with the new list, so it doesn't need to be patched.
After you compile your ROMs with VTXCart.exe, before flashing anything, test everything with MAME, specially to see if the menu list is correct and is sorted as you want. You can also run individual games to test them, but you can't run the games from the menu. Place MAME.exe inside the MAME folder which is next to VTXCart.exe, and the neogeo.zip BIOS inside MAME\ROMS. Then to run the menu or a game, exec the following commands:
- crom0 -> menu-c1.bin
- m1rom -> menu-m1.bin
- prom -> menu-p1.bin
- srom -> menu-s1.bin
- vroma0 -> menu-v1.bin
The PatchMenu parameter should be removed cause is only needed for the original menu, to modify the games list. The alternate menu is already built with the new list, so it doesn't need to be patched.
After you compile your ROMs with VTXCart.exe, before flashing anything, test everything with MAME, specially to see if the menu list is correct and is sorted as you want. You can also run individual games to test them, but you can't run the games from the menu. Place MAME.exe inside the MAME folder which is next to VTXCart.exe, and the neogeo.zip BIOS inside MAME\ROMS. Then to run the menu or a game, exec the following commands:
- mame.exe neogeo -cart1 menu
- mame.exe neogeo -cart1 game_name
Thank you, the compiled menu started normally on MAME.
But that's for the next cartridge, otherwise you'll have to change all the roms in this one. I put together a standard menu with PatchMenu. I compared the roms with those that were, only P1 changed. I'll just flash it and re-flash the S rom.
There are 2 FPGAs signed CP1 on the board, which one should I flash CHA_CP1 into, and which one should I flash PROG_CP1 into? I flashed PROG_CP1 to the one next to the P roms, and CHA_CP1 to the one next to the V roms.
But that's for the next cartridge, otherwise you'll have to change all the roms in this one. I put together a standard menu with PatchMenu. I compared the roms with those that were, only P1 changed. I'll just flash it and re-flash the S rom.
There are 2 FPGAs signed CP1 on the board, which one should I flash CHA_CP1 into, and which one should I flash PROG_CP1 into? I flashed PROG_CP1 to the one next to the P roms, and CHA_CP1 to the one next to the V roms.
davidmorom
Student
The CPLDs are like this:
It turns out that I combined Srom incorrectly - in Romwak via /m, not a simple merge, but some kind of byte merge. I used another utility to combine the files normally and everything worked. Thanks to everyone who helped, and Vortex c ArcadeTV for the development.
littlecharlie
Beginner
Is it possible to program C1 already soldered to the dual daughterboard?
I'm getting chip id bad and several errors.
Also, when programming s and mroms with the t48, I get an ID chip of 227E (instead of 2223).
Still, I can program it, but when I check the md5 of the dump and compare it to the source, it doesn't match
I'm getting chip id bad and several errors.
Also, when programming s and mroms with the t48, I get an ID chip of 227E (instead of 2223).
Still, I can program it, but when I check the md5 of the dump and compare it to the source, it doesn't match
Last edited:
davidmorom
Student
It is, but only if C3 is not soldered yet.
littlecharlie
Beginner
Then I don't know what is wrong with my chip. Maybe I fried it when desoldering. I'm getting bad chip id and several errors. I've checked several times continuity, it seems ok.
And the issue with the t48 is strange. The programmer and adapter works Ok because I was able to program the first chip (though I didn't check which chip id it showed). Md5 checksum ok.
But I've tried 3 other chips, and in all of then I get wrong md5 checksum. Even though in the process I get no errors at all.
davidmorom
Student
Providing the chip is not damaged, there are several possibilities:
- Continuity is fine, but there can be bridges between or under castellated holes. Sometimes they can be very hard to spot, use a microscope or magnifying lens, at least. Check there is no continuity between adjacent pads (some of them are joined together on the daughterboard, take this into account). Also, clean any possible flux leftover.
- There are bad connections between the male pin strip of the daughterboard and female header of the programmer. The female headers are a bit flaky. Check continuity here also, if you didn't already.
- Your chip is one of those that can't be reliably programmed at 3.3v, test the mods described a few post ago to lower the voltage. Test also the modified firmware for the WeAct board, the author claims it is much more reliable with problematic chips.
littlecharlie
Beginner
Thanks David, I think it might be the flux. I've clean it thoroughly with iso alcohol and now it's working.
Next battle, what the heck is wrong with the s/mroms/programmer ...
Next battle, what the heck is wrong with the s/mroms/programmer ...
Last edited:
If the programmer tells you that it completed correctly (and verified) then there’s nothing wrong. I think it’s user error. You are comparing FLASH (ROM) file to ROM+settings dump. Check the file size. You’ll see it’s not the same. All you should care about is FLASH data and not settings. Select FLASH from this menu and not default if you want to compare outside the tool.
Attachments
littlecharlie
Beginner
The first cartridge with menu from Vortex works fine. I soldered the second cartridge, with the menu from ArcadeTV- it shows the crosshatch table at startup. I checked all the soldering - it looks good, everything is soldered and without short circuits. What could be the best place to start?
Last edited:
davidmorom
Student
I assume you already tried the basic cartridge edge connector cleaning, so a contact issue is discarded. Did the cart work fine before modification? If it worked, you at least know that the CLPDs are OK.
The crosshatch is displayed when the BIOS doesn't detect a valid P ROM header. The menu is at the beginning of P1, so it should the obvious place to start, but as the three P chips are on the same bus, any of them malfunctioning can cause troubles. Thoroughly check and recheck the soldering of the three chips, sometimes there are loose pins that are hard to spot, I use the tip of a very thin needle to slightly push the pins of the chips to check that they are firmly soldered.
On a previous post I think you said that you tried the menu on MAME, and I assume you verified all the chips after programming, so that should not be the problem. Check that you didn't swapped the three P chips between them, it would be a silly mistake, but sometimes shit happens.
And of course the problem can be on the P ROM CPLD, did you verified it after programming?
Do you have UNIBIOS? I think it has an integrated memory viewer that can very useful to see what is happening on the P ROMs.
That's everything that comes to my mind right know, I hope it points you on the right direction.
The crosshatch is displayed when the BIOS doesn't detect a valid P ROM header. The menu is at the beginning of P1, so it should the obvious place to start, but as the three P chips are on the same bus, any of them malfunctioning can cause troubles. Thoroughly check and recheck the soldering of the three chips, sometimes there are loose pins that are hard to spot, I use the tip of a very thin needle to slightly push the pins of the chips to check that they are firmly soldered.
On a previous post I think you said that you tried the menu on MAME, and I assume you verified all the chips after programming, so that should not be the problem. Check that you didn't swapped the three P chips between them, it would be a silly mistake, but sometimes shit happens.
And of course the problem can be on the P ROM CPLD, did you verified it after programming?
Do you have UNIBIOS? I think it has an integrated memory viewer that can very useful to see what is happening on the P ROMs.
That's everything that comes to my mind right know, I hope it points you on the right direction.
Just now checking out your firmware.In case anyone wants to try it out, I pushed a binary release along with all the code a few days ago:
https://github.com/mrehkopf/VTXCart
Firmware binary download: https://github.com/mrehkopf/VTXCart/raw/refs/heads/main/Dumpers/Firmware/bin/cart.bin
NOTE: Only P, C, and V ROMs are supported at the moment; I don't have adapters for S/M
What is the expected output for each chip's Chip ID? Looks like we've gone from 4 digits to 16!
Does "garou" (last revision) work good on Vortex version? I mean, is it correctly unprotected/decrypted?
GAROU has a patched beta version running, it doesn't crash when you make a super punch from one of the fighters. davidmorom posted the patch a few pages ago.
The second cartridge also worked in the end -I didn't understand what was going on, I soldered everything that was, but in my opinion, soldering Srom helped in the end from crosshatch. But there are vertical artifacts in the image that change when you touch the Crom pins - contact disappears somewhere, I'll look for it later while I make the last third cartridge. All 3 F0095H0S that came from Aliexpress turned out to be serviceable, but I'm working with the firmware from ikari and with a mod to lower the voltage to 3 volts.
But that patch applies to the prototype version, right? I ask for the official "garou" rom, not "garoup". Supossedly "garoup" doesn't have the final scenes.
EDIT: sorry, I have seen "garou" rom isn't in Vortex, only "garoup". So, until today that version has minor glitches and no final cutscenes, am I right?
Last edited: