What's new

Butter Meister

Student
Joined
Oct 9, 2020
Messages
43
Reaction score
46
Location
USA
As my quarantine project, I have been experimenting with the 161 in 1 cartridge. https://wiki.neogeodev.org/index.php?title=161-in-1_Series_1 You've heard about this multicart before i'm sure, or at least seen it on eBay or AliExpress. It holds several Neo Geo games, and then a bunch of lousy ROM hacks.

Like many others I had been curious to see if its contents could be modified, mostly out of rage that Windjammers wasn’t in it. I’ve used my JTAG and soldering abilities to figure out how it works and if anything can be changed Here’s the specs:

I’ve bought 3 carts, new off AliExpress, and all of them are Version 4, they must be the only ones in production now.


CPLD - ALTERA MAX EPM3256ATC144 - 10N

There’s three of these on the board, each connecting to the flash chips, the cartridge pins, and each other. In addition, the CP1 on the SB board connects to the microcontroller, and CP1 on the XB board connects to the NOR flash chips.

Microcontroller - STC 11F08XE 351 - LQFP44

This connects to the CP1 SB, however I am still unsure exactly how it is used.

NOR - Micron JS28F512M29EWL

Two NOR flash chips 64 megabytes each, enough to have any released Neo Geo game loaded into from the ‘mystery flash chips’. Multicarts often load a ROM into a flash bank to play off of, which is possibly what these do.

Flash storage - F0095H0

And now the biggest mystery. Four flash chips of unknown origin resting on weird adaptor stilts. I haven’t found any information about these online, no datasheets or nothing. I even resorted to emailing AliExpress sellers of this chip for information, but they had none. I did find a possible alternate name for these, BK58F0095HVX010A. All I can surmise is the P chip holds game programming, the V chip holds sound, and the C1/C3 and C5/C7 chips hold the graphics, as they go to the CPLDs that connect to those relevant cartridge pins.

I am continuing to trace the pins of each chip on this cartridge with boundary scanning, and sometimes by eye, just to figure out the pinout of the stilt chips. I do have some useful things for you here. I have dumped the NOR chips, and the programming for the CPLDs, which you can download here. I also have my (as of now incomplete) board tracing work for you to see.

As of now, my goal is to discover the pinout of the mystery “stilt chips” and construct an adapter board to read its contents. My dumps and research are available for you all, and I hope for assistance or contributions on this project

Dumps - https://drive.google.com/drive/folders/1vBwigZcanxIWmZf6rJRyfP-kC3phxE3t?usp=sharing

Pinouts, my notes, and datasheets - https://docs.google.com/spreadsheets/d/1-YMRnKtDR4kIXg0ZiDjbrplcoMx6NIcARI7GP8PLKb0/edit?usp=sharing
 
Last edited:
I dont have another cart to try my MV1C , but i think a cause of what is in video is because this cart

 

Attachments

  • 943DBC9D-6471-4B4F-B026-13DD557AC056.jpeg
    943DBC9D-6471-4B4F-B026-13DD557AC056.jpeg
    213.3 KB · Views: 174
Bit of useless information on the 'stilt' roms going by the game sticker on "https://www.yoycart.com/Product/524468608478/"
Manufactured by/for or Okumura Yu Ki Co Ltd "https://ja.wikipedia.org/wiki/%E5%A5%A5%E6%9D%91%E9%81%8A%E6%A9%9F"
This company made pachinko machines.
Went bankrupt 2015

If there was repair schematics around for one of their machines then it may help in figuring out the pinout.
That was on the wiki with no source, so good job finding evidence. That's a good suggestion for figuring out the pinout, but who knows if those are online.
 
Have the CPLD dumps been tested? Usually these devices are read-protected, if they're good you are very lucky indeed! Will come in handy for repairs...
 
Have the CPLD dumps been tested? Usually these devices are read-protected, if they're good you are very lucky indeed! Will come in handy for repairs...
The dumps are essentially the coding in one file. They're read protected in the same way compiled code is read projected. I had somebody in a different thread comment that it was useful in a repair, which confirms that the dumps can be reused.
 
Not really... these devices, PALs, CPLD's, etc. have security bits which are set (or not) when the device is programmed. This is almost always done as it prevents casual cloning of the device. Now when we come to try and dump them, depending on device, method, reader etc. even if the device has the read-protect bit(s) set the read usually appears successful. One then has to look at the generated file and/or test by programming/testing another chip. Best example is simple PAL's which I dump often, the read appears fine, no error messages etc. but view the file and it's blank... Now sometimes we get lucky, the guy who programmed the chip didn't set the protection for whatever reason, if that's the case then like I said you were lucky :)
If there's someone familiar with these devices (not me) I guess they could just look at the .pof and see straight away if it looks valid or not.
 
The 3 pof files for the cplds are blank meaning the security bits were set. That's a shame but not at all unexpected, was hoping to possibly fix a 120-in-1 (very similar) with 2 dead cplds :(
 
The 3 pof files for the cplds are blank meaning the security bits were set. That's a shame but not at all unexpected, was hoping to possibly fix a 120-in-1 (very similar) with 2 dead cplds :(
Yeah that's a shame. I'm sorry I couldn't have helped you more on your work. I'm happy you got this much working so far on earlier models of the board. If the flash memory chips pinouts of version 3/4 were known I could have had the end goal of editing in different roms done months ago.

There's this program called JTAG Flash Programmer which supposedly lets you read the contents of a flash memory chip via a JTAG-able device. If you haven't heard if it, you should see if it could help you.
 
I'm just making assumptions about the 161 in 1 for now, because those 'stilt chips' are really something. Version 1 of the 161-in-1 uses the same chips as the 120 in 1, you can see the data for that on the wiki or from rockbottom's work. Versions 3 and 4 use the stilt chips and are more or less the exact same architecture just in a different layout. Version 4 is what I have been analyzing and working on since that's still sold on aliexpress.

C is two stilt chips in series with each other. The C chips on the version 1 board total 2 gigabytes so each stilt chip must be 1gb in size. That, and among the many weird names I found for the stilt chip in my research, some of them had 1024 in the title. That would total 4gb of flash storage, but not necessarily structured in such a way to store every game.

Fortunately the S and M chips already have full datasheets online. In theory, I can oscilloscope the S and M chips compare their wavelengths to the 'stilt chips' and determine the pinout one by one. Am I desperate enough to try that? I suppose I could try.
 
... so each stilt chip must be 1gb in size...
Yep, comparing versions 1 and 2/3, it looks like 1 "stilt chip" replaces 8 of the 128MB 55lv100s chips, so they must be 1GB/8Gbit. That's hell of a chip for parallel NOR 8) I wonder if they're actually 2x 512MB/4Gbit cores in a single package?
I've got a 161 cart coming soon, don't know yet what version (2nd hand, not sure how old), will be nice to have a working cart to play with, only got the dead 120 for now...
If I do ever manage to dump these "stilt chips" it's going to take a while, on my current setup it takes just under an hour to do a 2 pass dump (dump + single verify) for one 128MB chip, so these are going to be 7-8 hours per chip... crazy :D

(Although if they're 32-bit I guess that could be halved)
 
rockbottom' said:
I wonder if they're actually 2x 512MB/4Gbit cores in a single package?
Well you know it has 88 pins and multiple Vcc pins. That's an interesting theory.

I couldn't find any datasheets or info about the stilt chips, so it's going to be tough to figure them out. Ideally, I want to be able to dump and rewrite their contents, which is possible over JTAG even if it'll take all day to do it. I will work on the pinouts of the CHA board to help you, just check the link on my original post
 
The 55lv100s i've been playing with appear to be 2x 64MB cores in one package so I guess it's possible with these too... ?(
I found 16-bit write commands don't work, 8-bit commands affect every other byte, doubled 8-bit commands (same byte on each half word) work ok. Therefore I'm assuming it's 2 cores configured internally in 8-bit mode, each doing one half of the word. Kind of weird but I guess the Fuji had there reasons...
 
Back
Top