What's new
Is the latest revision the green 161 in 1 cart they are advertising as "version 2" on aliexpress?

I was wondering what was different in version 2 as game list looked the same.

I noticed they do seem to have some new Neo Geo cart products lately. E.g. These custom one game carts where you tell them which game you want and they make it for you.

https://www.aliexpress.com/item/400...675#49_4452#3098#9599#134_4452#3564#16062#412
Version 4 is what's currently sold as of February 2020.

But this brand new custom cartridge service is just plain shocking. They appear to be using the same CPLD and flash chips as on the 161 in 1. Instead of the stilt chips, they're using 2 more of the NOR flash chips already found on the 161 to store the game of your choice. The CPLDs are likely programmed differently too. This is worth a post of its own.
 
Why shocking? Are you referring to the price being the same as the 161? Or it's design? Or the fact that they're selling it at all?

I think it's almost a good idea. I just think charging that much for one bootleg game is off.

I'd just prefer they made one with all the games that weren't on the 161 and it would be a no-brainer.

it would be nice to have a low cost way of owning the whole library without the loading times and cost of the flash cart options.

The thing that shocks, appalls and disgusts me is what the ones who bought the SNK IP have done / not done with it. They could have released their own MVS multi-cart but instead they chose to make that neo mini abomination with just 40 of the weakest Neo Geo games.

Then.... as if that wasn't bad enough.... while our mouths were open and aghast, they ate asparagus and pissed in our faces with that analog joystick.... I'm mean WTF!
 
My 161 arrived today, it's version 2, nice and clean, fully working*, someone's already done the "stability fix" (bridged PDWAIT1 and PDTACK together). Was kinda hoping it would be v1 so I could get straight on with the hacking... well it is what it is so looks like i'll be challenging the mysterious "F0095H0" chips to a fight to the death :D Interesting those adapters aren't flexi's but very thin rigid pcbs, 0.4 or 0.6mm thick by the looks.
Already looking to me like they're 16-bit not 32-bit chips, easy to see which pins are data (P data bus straight to edge conn), if i'm really lucky address lines are hooked up similar/same as 120, i've got complete schematics now so that should help, there's more than enough spare cpld pins to handle the bigger flash chips extra lines, hopefully they kept the pinout similar... we'll see...

Dumping should be easy, as for reprogramming that's anyone's guess atm :D
Will be a while before anything happens, will make schematics, design an Arduino pcb, get it made etc. etc. probably 3 weeks at least...
Which actually isn't all bad as it'll give me some playtime.. it's actually a really nice experience in conjunction with unibios 4.0 "PICKnMIX" mode, much better than stock menu :thumbup:

* it's a bit flakey on my MV1FS: no sound on Metal Slug 3/4/X, random crashes on certain other games. I've also got a MV1A, MV1AX, MV1B: it's rock solid on those. The MV1FS does have a wounded NEO-C1 (one 2P input is dead) that's probably why, don't suppose anyone's got a spare on a scrap/parts board?
 
Started looking into the mystery "F0095H0" chips, it's gonna be more complicated than i'd hoped as it seems they are selectable 16/32-bit chips.
As Butter Meister said, they are most likely Micron BK58F0095H0T010A, seems no info exists anywhere, no reference to anything BK58... on Micron website. I'm assuming like the 55lv100, they're exclusive to the Japan pachislot industry and probably never been officially sold outside Japan. Some Chinese brokers claim to have stock for sale, although the descriptions of what they actually are vary. One states "8Gb (256Mx32) NOR Flash Memory", I think that's probably correct. References can also be found to a F0096H0, probably just a later revision (again no info out there).

So far i've pinned out the P and V roms, very little confirmed so far, just the P data bus as that's the only thing going directly to the edge connector.
Will do C on the other board next, perhaps that will shed some more light...

crazy-chips.png

Just some random thoughts:

pin 2 is /oe?
V probably is always enabled (1 of the 4 chips is always enabled on 120)

P pin 1
very strange, goes only to PCM2 cpld...
why is the adpcm/V cpld having anything to do with P rom?
(on 120 they are entirely seperate)

pins 12, 13
mode select? (like /byte pin on 8/16-bit selectable eproms?)

max P will not exceed 512MB so they probably are just ignoring one half of the chip!

why is V using 32-bit mode?
actually V is only 8-bit on normal cart!

why has V got so many extra signals?
should actually be one less address line in 32-bit mode?

write enable pin for programming?
probably one of 20,21,22 are /we
another is probably a write-protect pin

pins 14, 15
?

pins 18, 19
?
 
will you share the content somewhere so people can dig into it?
Yes, I will put all it up somewhere at some point, I got side tracked with the arrival of a 161 cart, started looking at that instead :D
I had nearly completed lists of each dump, detailing what was where, what was bad, hacked etc. I was also working on some tools: one to automate creating Mame drivers for each game (to confirm bugs etc.) Another to automate the process of fixing issues in the dumps by overwriting the relevant part with good data, then re-scramble ready to burn back to flash. I'll get back to that once I've got a dumping pcb for the 161 chips into production.

As for the 161, created a schematic of the CHA board, sadly the two C chips didn't tell me much more. As it stands the 32 data line pins are confirmed, not much else, all other pins on all chips just go to the cplds so I can't confirm which address line is which, whats /oe, /ce etc. :evil:
I've cross referenced it with 120 schematics, hasn't changed too much so I'm hoping they've kept the address lines the same at least...

As for the chips themselves, still no info found, digging through some supported device lists for various high-end Japanese chip programmers I've found couple other Micron chips of same size and same weird 88-pad TFLGA package. They are: N28H00DB03JDK32E and MT28HL08GNBB3EBK. Sadly no info on them either :/ It's quite strange, it seems info on "big" Nor flash is kept out of public domain by the manufacturers, no mention on websites, no support info, datasheets, pinouts etc. I've contacted Micron tech support, will be suprised if they give me anything but we'll see...
I'll admit the prospect of re-programming these atm is looking fairly bleak (without knowing correct address lines can't send unlock commands etc.) but it
's far from over yet, still got a few tricks to try... ;)
 
Yes, I will put all it up somewhere at some point, I got side tracked with the arrival of a 161 cart, started looking at that instead :D
I had nearly completed lists of each dump, detailing what was where, what was bad, hacked etc. I was also working on some tools: one to automate creating Mame drivers for each game (to confirm bugs etc.) Another to automate the process of fixing issues in the dumps by overwriting the relevant part with good data, then re-scramble ready to burn back to flash. I'll get back to that once I've got a dumping pcb for the 161 chips into production.

As for the 161, created a schematic of the CHA board, sadly the two C chips didn't tell me much more. As it stands the 32 data line pins are confirmed, not much else, all other pins on all chips just go to the cplds so I can't confirm which address line is which, whats /oe, /ce etc. :evil:
I've cross referenced it with 120 schematics, hasn't changed too much so I'm hoping they've kept the address lines the same at least...

As for the chips themselves, still no info found, digging through some supported device lists for various high-end Japanese chip programmers I've found couple other Micron chips of same size and same weird 88-pad TFLGA package. They are: N28H00DB03JDK32E and MT28HL08GNBB3EBK. Sadly no info on them either :/ It's quite strange, it seems info on "big" Nor flash is kept out of public domain by the manufacturers, no mention on websites, no support info, datasheets, pinouts etc. I've contacted Micron tech support, will be suprised if they give me anything but we'll see...
I'll admit the prospect of re-programming these atm is looking fairly bleak (without knowing correct address lines can't send unlock commands etc.) but it
's far from over yet, still got a few tricks to try... ;)
Nice job once more.
Very interested in the 161-in-1 think it is to my knowledge the more common
Which model are you talking about?
Best
 
... Which model are you talking about?

I have a 120-in-1 which is fully dumped, a 161-in-1 v2 so far partially dumped, Butter Meister has partially dumped latest v4 161-in-1. Partial dumps are just M and S, the big F0095H0 chips are work in progress ;)
Currently black-box testing the CHA cpld in an effort to figure out the address and control pins of the big flash chips...

cha-bb.jpg

Success mapping cart-edge gfx bus to address pins (A0-A23 confirmed).
Currently looking at how the upper address and control lines are switched via the ribbon cable bus from other board...
 
Time for a little update...

currently in that annoying waiting phase, dumping/programming(?) pcb has been designed, ordered, production complete and in the post from China (JLCPCB). Virtually no chance it will arrive this side of xmas now (UK post barely copes at a normal xmas, let alone this xmas ;) ) Not much more can/will happen now until it arrives.

pcb.png

Having removed a chip from the adapters, it's now clear it's not a single IC but multiple dies on a substrate/pcb of some kind. (Can clearly see tracks and vias on the underside of the chip)
It's looking like 4 seperate dies in one of the following arrangements, tbc...

arrangement.png

Debugging the CHA board cpld has revealed most address lines and presence of multiple oe/ce lines (reinforcing the above point)
Still several unknown function pins. All pins now confirmed out-of-circuit (diode-characteristic tests on each pin)
Pinout so far:

chip.png

No guarantee it's correct for programming as bootleggers sure like to mix up address/data lines for whatever reason, but we'll see soon enough...

Have looked at the S and M dumps, can confirm data is identical to Butter Meister's v4 dumps. Suprisingly no scrambling :) Can only hope the same is true for the F0095H0...

As for Mircon... didn't even bother replying, I thought maybe at least a generic "sorry that's confidential" type reply, but nothing... nice :evil:
 
Progress...

PCB arrived and assembled.
Had some issues, for a while I was not getting consistant dumps, weird issue with one of the level translators oscillating or generating noise, not something easily diagnosed without a high end scope, bodged my way round it for now... I guess a rev 2 pcb will be needed at some point ;)

reader.jpg


Dumped P, turns out there's a few unused games in there, King of Monsters 2, Windjammers, Zintrick, 2 other kof97 variants/hacks.
Also 2 versions of the menu code, one English, one Chinese, not sure if there's a way to change the cart language or if it's set in production somehow?
Got it running in mame but not looked at it's inner workings in much detail yet.

eng.png chin.png

P rom is scrambled, or in other words address lines are swapped around compared to C. This is annoying as I now don't know which is correct (or perhaps neither?) when it comes to programming. On that note, haven't attempted anything other than dumping so far. Wouldn't want to accidentally issue full chip erase command before having full rom backup :P

Much faster dumping now, turns out the Arduino DigitalWrite() commands are insanely slow, just switching to direct port bit twiddling has dropped dumping time by 2 thirds,
a previous 1hr 128MB dump is now 20mins. This has brought the 1GB F0095H0 full chip dump down from ~8hrs to about 2.5 :thumbsup:
I don't even want to know how many hours I would have saved it I'd found this before dumping the 120-in-1 :evil:

That's all for now...
 
Progress...

PCB arrived and assembled.
Had some issues, for a while I was not getting consistant dumps, weird issue with one of the level translators oscillating or generating noise, not something easily diagnosed without a high end scope, bodged my way round it for now... I guess a rev 2 pcb will be needed at some point ;)

reader.jpg


Dumped P, turns out there's a few unused games in there, King of Monsters 2, Windjammers, Zintrick, 2 other kof97 variants/hacks.
Also 2 versions of the menu code, one English, one Chinese, not sure if there's a way to change the cart language or if it's set in production somehow?
Got it running in mame but not looked at it's inner workings in much detail yet.

eng.png chin.png

P rom is scrambled, or in other words address lines are swapped around compared to C. This is annoying as I now don't know which is correct (or perhaps neither?) when it comes to programming. On that note, haven't attempted anything other than dumping so far. Wouldn't want to accidentally issue full chip erase command before having full rom backup :P

Much faster dumping now, turns out the Arduino DigitalWrite() commands are insanely slow, just switching to direct port bit twiddling has dropped dumping time by 2 thirds,
a previous 1hr 128MB dump is now 20mins. This has brought the 1GB F0095H0 full chip dump down from ~8hrs to about 2.5 :thumbsup:
I don't even want to know how many hours I would have saved it I'd found this before dumping the 120-in-1 :evil:

That's all for now...


You're amazing dude...
 
Time for an update, the mystery F0095H0 chips have fallen, now have full reprogramming ability :thumbsup:
Turns out they consist of 8x Micron MT28GU01G 128MB/1Gb cores arranged as follows:

final_a.png (each 64Mx16 block is a single MT28GU01G)

The proper pinout is different to all (P,C,V) used on the cart, they've scrambled data lines (same scheme all 3) and address lines (same scheme for C and V, different scheme for P), also some additional block swapping for P.

final_p.png (pins with '?' cannot be 100% confirmed)

Have designed a new rev 2 dumping/programming pcb now the correct pinout is known, should get those soon hopefully. Simpler design this time, just a single 16-bit level translator and loads pull-up resistors, knowing the internal layout now it makes more sense to just have a common 16-bit data bus, means less components and easier assembly for anyone wishing to make one.

So where are we at now exactly?
Well, basically any existing data can now be reprogrammed, bad data corrected, like-for-like game swaps, fix bugs, hack/improve menu etc. etc.
What can't so far be done is "wipe the slate clean" as it were, so I can't erase the whole thing and say I want this game, that game etc. and arrange/program everything as I see fit.
The reason for this is the 3x cplds are hard-coded to select certain rom regions for each game. The menu code simply issues a binary game number (literally 1 to 161, with 0 to go back to the menu) which each cpld interprets differently depending on its internal config.
This is kind of annoying as going further at this point will mean from-scratch replacement firmware for each cpld. (Or unlocked dumps being found and reversed - unlikely)

In a nutshell: fairly easy for C (pretty much just a dumb slave), harder but do-able for V (also a slave but not quite so dumb + NEO-PCM functionality), very complex for P as this is the master/brain of the cart that controls the other 2, deals with system comms and handles reads/writes to the MCU.
As for the MCU itself, it's looking like rather than having any control over the cart, it deals just with loading/saving game softdip settings (saves in it's internal eeprom) Although that said I've not looked into that side of things much yet.

So that's it for now, when the new pcb arrives and tests ok, I plan to release everything done so far for others to have a play. In the mean time i'm looking at the P/master cpld, planning some hardware attacks, need to know a bit more about it before I can assess whether a replacement firmware will be possible or not.
 
Time for an update, the mystery F0095H0 chips have fallen, now have full reprogramming ability :thumbsup:
Turns out they consist of 8x Micron MT28GU01G 128MB/1Gb cores arranged as follows:

final_a.png (each 64Mx16 block is a single MT28GU01G)

The proper pinout is different to all (P,C,V) used on the cart, they've scrambled data lines (same scheme all 3) and address lines (same scheme for C and V, different scheme for P), also some additional block swapping for P.

final_p.png (pins with '?' cannot be 100% confirmed)

Have designed a new rev 2 dumping/programming pcb now the correct pinout is known, should get those soon hopefully. Simpler design this time, just a single 16-bit level translator and loads pull-up resistors, knowing the internal layout now it makes more sense to just have a common 16-bit data bus, means less components and easier assembly for anyone wishing to make one.

So where are we at now exactly?
Well, basically any existing data can now be reprogrammed, bad data corrected, like-for-like game swaps, fix bugs, hack/improve menu etc. etc.
What can't so far be done is "wipe the slate clean" as it were, so I can't erase the whole thing and say I want this game, that game etc. and arrange/program everything as I see fit.
The reason for this is the 3x cplds are hard-coded to select certain rom regions for each game. The menu code simply issues a binary game number (literally 1 to 161, with 0 to go back to the menu) which each cpld interprets differently depending on its internal config.
This is kind of annoying as going further at this point will mean from-scratch replacement firmware for each cpld. (Or unlocked dumps being found and reversed - unlikely)

In a nutshell: fairly easy for C (pretty much just a dumb slave), harder but do-able for V (also a slave but not quite so dumb + NEO-PCM functionality), very complex for P as this is the master/brain of the cart that controls the other 2, deals with system comms and handles reads/writes to the MCU.
As for the MCU itself, it's looking like rather than having any control over the cart, it deals just with loading/saving game softdip settings (saves in it's internal eeprom) Although that said I've not looked into that side of things much yet.

So that's it for now, when the new pcb arrives and tests ok, I plan to release everything done so far for others to have a play. In the mean time i'm looking at the P/master cpld, planning some hardware attacks, need to know a bit more about it before I can assess whether a replacement firmware will be possible or not.
This is incredible progress! So if the cplds are hard-coded to a region, is it just an index? So if a game I want to get rid of is 200MB let's say, can I put a 199MB game in its place? The menu will just go to this region, which is now a different game. If the next cpld depends on the 200MB size, maybe the 199MB game can be padded with 0s or junk data? I'm just shooting in the dark lol. If this is all possible, then maybe all the regions can be mapped out, and we can figure out which games can fit in which slot etc. Unless of course the hard-coding can be changed somehow.
 
Last edited:
Time for an update, the mystery F0095H0 chips have fallen, now have full reprogramming ability :thumbsup:
Turns out they consist of 8x Micron MT28GU01G 128MB/1Gb cores arranged as follows:

final_a.png (each 64Mx16 block is a single MT28GU01G)
This is exactlty what @Darksoft and I have been looking for a while (32bit flash). Where to get them? (I suppose you can't ).
 
Already saw those, but 512KB is way too small for our needs. To be complete, we are looking for 32bit flashes with (ideally) 64MB/128MB capacity.
The goal is to reduce number of chips needed for multis on systems with 32 or 64 bit busses.
Oh yash, idk if such high sizes exist in new stock. But I have actually purchased the exact same stilt chips as seen on the 161 in 1 in aliexpress. Obviously not a reliable source, but they can be purchased still.
 
Back
Top