What's new
By:

Reverse engineering 161 in 1 cartridge to change Rom games

pluger said:
If the Usb Blaster dont supply the correct voltage, could be connect the vcc/gnd pins to a external power supply, per example a arduino with 3.3 V out? or the boar must be connected to a mvs board (mv-1, etc...), the mvs or aes card could be connect to another power supply (Power adapter) to the cart pins?
I order the FT232H USB, this friday i tested.
Click to expand...
You could use some other way to power the board, but using the mvs motherboard is the easiest.
 
ack said:
You could use some other way to power the board, but using the mvs motherboard is the easiest.
Click to expand...
Thanks, could you send a photo for this setup, how it is connected the board to de mvs board, and the programmer, please. So many thanks.
 
pluger said:
Thanks, could you send a photo for this setup, how it is connected the board to de mvs board, and the programmer, please. So many thanks.
Click to expand...

IMG_1131.jpg


Nothing fancy going on. Supergun provides power to the MVS motherboard, which is providing power to the 161in1 pcb, which is connected to the computer via the usb blaster.
 
ack said:
It was the PROG_CP1 CPLD. It only happened with one of the carts I have. openocd would see the device, but programming would always fail.
Click to expand...
Well, finally ran into this. 71/72 carts without a problem. OpenOCD will program and fail, or program and then hang on the MSSE flush no response in xxxx time error. Also a PROG_CP1 CPLD. AES. Must have tried 30 times now.

Gonna borrow a USB Blaster again I suppose, since Amazon won't ship your recommended knock-off to me.
 
Would it be possible to interface a logic bank switcher with a 512kb eeprom wired up to the srom to get support for larger s roms? Could something like that work with how the srom is implemented on these 161 carts?

Edit: I think it would be possible after looking up some examples. The only question is could a flex pcb cable be made successfully with connections small enough to interface to the js28f512 tsop package?
 
Last edited:
You can use this.

https://github.com/aluzed/MiSTer-Neogeo-Rom-Decrypter

Or do it manually because this tool says it's not compatible with the whole neo geo rom library, whatever that means.

https://www.arcade-projects.com/threads/how-to-convert-files-to-work-with-neogeo-multi.24393/

Pay attention to rewrite's post of it not containing all the info on how to properly combine the C roms. You basically have to use the python script on two c rom files at a time. Then combine them all into one big file.

Also look at this to fix an audio issue on fp and 5s in the vrom. Towards the end of that thread, there is a fix for Nightmare in the Dark as well.

https://www.arcade-projects.com/thr...al-perfect-improperly-decrypted-v-roms.18187/
 
Last edited:
I've also just found that my S1 chip is a JS28F256 not a JS28F512

Will this still work or will I need to replace with a 512 (I still have one of these spare)

Also literally none of my chips seem to match the MD5 that ack posted. Not even close. Hardware IDs check out and I'm not getting errors on the dump so I'm not sure what's going on there
 
Last edited:
A24 of the s rom(JS28XXX,) is left floating on the 161 CHA board. This address line is not connected to anything. This mean's the 161 can only address up to 256MB for the s rom, so it's fine.
 
Good question. Probably, haven't compiled a game list yet. Open the srom up in a hex editor and you will likely either see that the first half is full, while the second half is empty. That, or the first and second half are the same. Used a hex editor to split the size in half.
 
Vortex said:
It's a pity that @rockbottom hasn't appeared on this forum for a long time.
The project is very interesting and useful. Even in V3 there are problems with games and I really want to re-flash this cart.
I currently began to reverse and study the V3 boards.
It is almost like the previous, but differs with 1.27mm headers for stilts.
I developed three boards for my STM32 dev board for programming P, S_M and C_V chips.
I'll keep you informed.

Another (crazy) approach is to program the cart boards right in the slot. To do this, we need two 120-pin slots and a MCU.
Unfortunately, some pins (WP#, etc.) are hard-wired in the cart's PCB, so I decided to start with separate boards first.
Click to expand...
Hello, where can I find the gerber file for the dump pcb of the rom?
 
Just hit a dead end.

Cart doesn't boot. It just goes straight to the check board screen.
I've programmed everything, dumped and checked the Cr32 for every chip's content before soldering them into the cart.
Could this be related to the CPLDs? I've never used Quartus before, so I'm not sure if I'm doing something wrong.
What I do is click compile, get some warnings after compiling, then click on program device (open programmer), check the first box, and click start.
I don't get solid connections every time because I didn't solder directly to the connector of the cart, but after some tries, I get a 100% successful green bar.

I would appreciate any suggestion.
 

Attachments

  • print2.png
    print2.png
    167.7 KB · Views: 128
Misos said:
Just hit a dead end.

Cart doesn't boot. It just goes straight to the check board screen.
I've programmed everything, dumped and checked the Cr32 for every chip's content before soldering them into the cart.
Could this be related to the CPLDs? I've never used Quartus before, so I'm not sure if I'm doing something wrong.
What I do is click compile, get some warnings after compiling, then click on program device (open programmer), check the first box, and click start.
I don't get solid connections every time because I didn't solder directly to the connector of the cart, but after some tries, I get a 100% successful green bar.

I would appreciate any suggestion.
Click to expand...
A crosshatch screen indicates an issue talking to the program roms on the PROG board. For the 161in1 it could be caused by the PROG_CP1 CPLD or something with the P1/P2/P3 flash chips. If you have unibios what you can do is at crosshatch screen press 'D' to go into the memory viewer, then scroll down to around address 0x000100 and see whats there.
 
Last edited:
ack said:
A crosshatch screen indicates an issue talking to the program roms on the PROG board. For the 161in1 it could be caused by the PROG_CP1 CPLD or something with the P1/P2/P3 flash chips. If you have unibios what you can do is at crosshatch screen press 'D' to go into the memory viewer, then scroll down to around address 0x000100 and see whats there.
Click to expand...
I'm happy to report that I have solved the problem and have a proper working cart now.
Reflowed the P-roms and the cart booted properly.
The only problem is powering off the system to choose a different game, but I'm not complaining it's worth the trade-off.
Special thanks to RockBottom, Vortex, Ack, Rewrite, and everyone else who helped here in this thread or was involved in the project.
 

Attachments

  • 1703715194112.jpg
    1703715194112.jpg
    186.6 KB · Views: 194
Misos said:
The only problem is powering off the system to choose a different game, but I'm not complaining it's worth the trade-off.
Click to expand...

Install a Unibios and you can soft reset with a button combination.
 
You must log in or register to reply here.
Back
Top