What's new
By:

Reverse engineering 161 in 1 cartridge to change Rom games

S rom data is doubled with just the low byte used, total data is just under 16MB so using less than 8th of the chips capacity.
Have also dumped the M rom, same thing, and no scrambling surprisingly :D

Setup is Arduino Mega + sd module with custom board I had made, other IC's are just 5v<->3.3v level shift, also 3.3v reg on other side.

mvp55-prog.jpg


I'll put the code, pcb design, chip details etc. all on Github at some point, need to optimize at bit, currently taking nearly 1/2 hour for single dump, so an hour with a read/verify. These things are big, 128MB is a fair bit of data to bit-bang (that's 32 27c322 eproms 8| ) Hopefully get it down a bit as another 21 chips to dump... ;)
 
rockbottom said:
I have now cracked the MSP55LV100S chip, turns out it's an oddball, 2x 512Mbit 8-bit cores (id matches Spanison S29GL512P) arranged as one 16-bit chip :huh: So I can read,erase,write etc. and have a confirmed good pinout, can write up the details if there's any interest.
Looks like another annoyance will be scrambling, have only dumped the S rom so far, some trivial-ish scrambling which i've cracked, but that's the low-hanging fruit, the others will most likely be trickier... X/
Click to expand...
I would like to see a write of it so I can compare it to the Version 3/4 version's flash chips.
 
The cart seems to be pretty oddly designed. Probably designed it to use spare ics they had lying around whenever they started making these.
 
Made fair bit of progress, have dumped the P and V roms. P roms are hellishly scrambled, took a while to figure out, V roms also scrambled but not so bad, just data lines swaps. First 1MB of P for each game are in P3, nice and neat in same order as menu. >1MB P for each game (varying lengths) are spread in no particular order across P1 and P2.
V's are spread in no particular order across V1-4, noticed a few errors they've made: Puzzle Bobble: missing v2, Sengoku 3: bad v2, missing v3, NAM: 2nd copy of v23 instead of v21, few other games have bad data.

Also worth noting, later games which have various encryption, everything so far is unencrypted although more often than not don't exactly match unencrypted data dumped from mame.

So onwards with the biggest task of all... graphics, 14x C roms to dump, that's gonna take a while... :D

Side note: cheap JLCPCB board holding up brilliantly, 9 soldering/desoldering cycles so far, not so much as a lifted pad ;)
 
Last edited:
Could you share the files for Nightmare in the Dark, please? There's a sound bug in the game when played on original hardware (Mame doesn't have it), but apparently it's been fixed in some multicarts (and possibly genuine carts too). See here:

Games with Issues
 
Nice work! Always good to see bootlegs deciphered!

I hope this dumping technique can be used with the "old" cps1 multigame with the super pang hack (it was a stand alone game but lost to time).
 
nem said:
Could you share the files for Nightmare in the Dark, please? There's a sound bug in the game when played on original hardware (Mame doesn't have it), but apparently it's been fixed in some multicarts (and possibly genuine carts too). See here:

Games with Issues
Click to expand...
If you're talking of the music disappearing but sound effects still working it's also present on the multicart I got. P ROMs pass the CRC check but it could well be a bug in the Z80 code.
 
Apocalypse said:
If you're talking of the music disappearing but sound effects still working it's also present on the multicart I got. P ROMs pass the CRC check but it could well be a bug in the Z80 code.
Click to expand...
That's not it. The sound bug affects the jump sound effect, it sounds distorted. It happens every time you jump. It's really obnoxious.
 
nem said:
Could you share the files for Nightmare in the Dark, please?
Click to expand...
NITD V/M are good, V's crc match mame bootleg set, which itself is the official set (single v) cut in two.
M is 128KB, original is 512KB but only first 128KB contains data, rest empty, actual data is crc match.
So all good there, I guess whatever is causing the sound issues isn't rom related, at least on this cart, others may well be different.
(The cart i'm dumping is dead (2x dead cpld's), never had it running so can't confirm if it had issues.)

Hammy said:
I hope this dumping technique can be used with the "old" cps1 multigame with the super pang hack (it was a stand alone game but lost to time).
Click to expand...
It's the Fujitsu MSP55LV100S (128MB/1Gbit sop70) chips i'm working with, so anything else using those I can now dump and reprogram.
I'm guessing the half size MSP55LV512 (64MB) chips are very similar so possibly them too.


Good news: I've now dumped the first C rom pair, just trivial data line swaps, so looking like an easy (though long) road ahead... :D
 
nem said:
That's not it. The sound bug affects the jump sound effect, it sounds distorted. It happens every time you jump. It's really obnoxious.
Click to expand...
yes it sounds scratchy/staticy it's present on my original cart and very annoying.

I forget who but I recall someone saying it was due to the developers overflowing the audio memory and it works in MAME because it's able to properly handle the overflow. I could be remembering it wrong though.

info here: https://mametesters.org/view.php?id=1850
 
I've been wanting a way to change the games on my 161 in 1 cart for a while too. It's annoying that they chose to populate it with easy to find and inexpensive games like Art of fighting 1+2 while missing some of the more expensive and desirable games like Art of Fighting 3.

Plus, even if you ignore the awful hacks, there is still far too many KOF games.

I'm wondering if the errors found re missing or incorrect files are consistent across all of the 161 multi carts or just a QC error. I've had a few and they all seem to have different graphical glitches.

I gave up trying to find one with 161 working games. I assumed the graphical glitches were hardware faults. It would be great if the games were just dumped poorly (if I had a way to fix that error).
 
Zebra said:
I've been wanting a way to change the games on my 161 in 1 cart for a while too.
Click to expand...
At this stage it's only really fixes, eg. for NAM I could quite easily erase the duplicated V and replace with the correct one. I guess something like changing a hack/clone of a game to the official (or different hack) should be possible too.

In terms of wiping the slate clean, picking a list of games and reprogramming the whole cart as desired, that is still very far off. Ability to reflash the roms is just the first hurdle.

To have full control of the cart there's still...
  • understanding of the cplds, dump (if not secured), reverse to logic, edit, reprogram -or- create new logic from scratch (I can't attempt the former as mine are dead). Also factor in, there's the SNK chip functionality to do (the PCM, ZMC, NEO-273 etc.) not just the multi-cart specific stuff (logic definitions are available in the Mister FPGA project which might work ok for this)
  • as above but for the Atmega8 mcu (will see if I can dump this at some point, although probably secured)
  • edit 68k code for menu (easy)
  • edit S rom data for menu (easy)
  • possibly edit C rom data for menu, atm looks like menu just uses S for graphics, tbc... (easy if required)
All-in-all, possible but long way to go, well at least I wouldn't say anything there is impossible anyway ;)
I guess the dream would be if the whole process could be wrapped up in an application, just drag-drop the roms and it would spit out images for all the chips, roms, cplds, mcu, then reprogram the whole thing. But even then the physical removing, reprogramming, refitting of all the chips is still a major time consuming task!
 
nem said:
That's not it. The sound bug affects the jump sound effect, it sounds distorted. It happens every time you jump. It's really obnoxious.
Click to expand...
Humm... Neither my OG cart nor the cheap 161 in 1 does that. However I can reliably trigger a bug causing music to stop if I throw flames at a chest and just before it disappears I pick it up and a diamond in the same frame.
 
If there is a fixed version I'd venture a guess that the fix would be in the S or M ROMs, I don't think the error is with the V-ROM Sample so much as how the samples are handled/layered.

I suppose it's also possible that it's dependent on the mobo and or mobo bios used.

if this error is indeed absent on Apocalypse's setup I'd be very interested to know why and how I can fix my own cart.
 
This is awesome! This is really impressive, considering how much soldering and desoldering you have to do
 
Finished the dumping at last...

dump.png

Full dump totals just under 3GB, zips to around 1.2GB ;)

chips.jpg

Eagle-eyed will notice one extra chip there... dumped a Mega Drive 112-in-1 multi-cart whilst I was at it :)
PCB held up great, 24 remove/resolder cycles, just one pad started to lift on the very last chip. not bad for a pcb that cost less than £1 :thumbsup:

In other news...
got the menu code running in Mame, turns out it uses only S rom graphics, no C, uses two S roms with trivial bankswitch mechanism.
lots writes to 2ffff0, 25fff0, 2fffc0, presumably communicating with the cpld and atmega, also reading data from 200000-2fffff region so looks like it should have a P2 data rom somewhere in P1 or P2 roms which i've yet to locate...
I think the atmega is storing/loading soft dip settings but not yet confirmed, need to go through the code in detail soon...
will attempt to dump the atmega soon, probably secured but might get lucky ;)
also in process of creating schematics, nearly finished prog board so far, cha board todo...

mame.png

Also found out today, i've still got a very old version of Quartus (Altera dev tool suite) with support for these old cpld's on an old XP box, think i've got programmer somewhere too... I'm thinking I might try and source some NOS (or more likely crap from china ;) ) on ebay and have a crack at getting the cart working again. Unlikely i'll get it fully working but even just manually switching a few games would be a start, sadly cpld dumps in the other thread are bad so would be coding something new from scratch... on the todo list... :D
 
Love that kind of project/study.
The step by step approach is the key IMO. Learning a bit at a time.

Good work!
 
3 gigabytes (bytes i'm assuming) means most of the neo geo's 4gb sized library can fit on there if you remove stuff like the Mahjong and Quiz games and a few high sized games.

I had assumed that they included so many ROM hacks because they would reuse assets between vanilla and hacked games to save on storage space. But the 3gb file size tells me they weren't doing that and were literally just including multiple full sized roms. It's mind-blowing to me that that's what they chose to do instead just including every vanilla game. If this is true, than the 161 in 1 must have over 4 gigabytes of storage.
 
You must log in or register to reply here.
Back
Top