Reverse engineering 161 in 1 cartridge to change Rom games

[rockbottom]

The EPM70xx are also true 5V tolerant but I think Altera doesn't make them anymore. But Atmel still manufactures equivalent parts (ATF15xx).

These are EPM3256A 144-pin, so no 7000 or Atmel equivalent unfortunately.

Won't need? Dunno, if we can't dump them and don't want to erase them what are the remaining possibilities?

No because the 70xx are pin compatible with the MAX3000.

I'm happy to erase them, just not yet, as I need them working for the moment (for more testing). I would have liked some replacements just so I could keep the originals as is, then the cart can always be put back to stock by refitting the original chips if necessary. I've actually got 1 of the 3 from the dead 120-in-1 which might be ok, i'll try that first when the time comes. I might also order a few ebay junk ones and see what happens.

Well we won't need to replace the CPLD's will we? At that point you might as well make a new board from scratch.

And don't forget about the STC chip nobody's talked about yet

No we won't need replacement cplds, as above, would just be nice to have some spares. Although I guess we should make clear it won't be possible to put the cart back to stock.
As for the STC, yes that's the biggest unknown at the moment, not much info out there about them other than basic datasheet. Luckily it doesn't seem to do much other than save game softdips to its internal eeprom and play them back when the 68k code asks for them. Although that's tbc, i've got lots more investigation to do in that area...
I'm actually wondering if it could be replaced with a PIC or AVR, if there's something that would roughly fit the footpint without too much modding, might be worth considering...
Shame they didn't stick with the 120-in-1 design, that has a Atmega8 which would be a whole lot easier to work with

 

[rockbottom]

Here's something interesting... been looking in depth at the 68k menu code, found hidden menu entries for the unused games and with a little tweak it's possible to make it draw the full list



So at some point in development they must of had plans for at least 166 games.
Strange thing is, there's actually enough empty space in the roms to fit those extra games, I wonder why they dropped them

 

[Butter Meister]

Here's something interesting... been looking in depth at the 68k menu code, found hidden menu entries for the unused games and with a little tweak it's possible to make it draw the full list



So at some point in development they must of had plans for at least 166 games.
Strange thing is, there's actually enough empty space in the roms to fit those extra games, I wonder why they dropped them

Maybe they ran out of space on the other chips? Do the cut games have address locations?

Zintrick btw is likely a hacked backport of the original Neo Geo CD game. MVS can't normally play NGCD games.

 

[rockbottom]

There's plenty empty space in all the roms, the only ones approaching full capacity are C but even they have about 40MB free, so enough for those 3 games. I think it's most likely they ran out of gates in the master P cpld, each game is unique 8 product term equation, plus all the other stuff it's doing, probably is near full usage of gates. Would also explain why they route a few lines through the other V cpld as it's doing a lot less and probably had spare gates left over.

 

[Arthrimus]

This is a great project. Is the structure of the flash dumps understood well enough at this point to repair the glitched roms on the stock cart yet?

 

[Butter Meister]

There's plenty empty space in all the roms, the only ones approaching full capacity are C but even they have about 40MB free, so enough for those 3 games. I think it's most likely they ran out of gates in the master P cpld, each game is unique 8 product term equation, plus all the other stuff it's doing, probably is near full usage of gates. Would also explain why they route a few lines through the other V cpld as it's doing a lot less and probably had spare gates left over.

Gates, oh right. Do you think that's gonna be an issue? Not if we'd be removing more than we're adding right?

 

[Fluffy]

Just wondering, are game sorted by size? I wonder if you could optimise the layout to minimise product terms.

Edit: Also, game-ids don't need to be continuous if you change the menu, which would probably allow some optimisations as well.

 

[rockbottom]

Been looking into the STC MCU side of things...
Turns out there's some info out there, nothing on this particular part, but a few snippets about similar STC stuff, mostly the STC89C52RC.
Thought i'd just post up what info I've found out so far...

STC11F08XE
STC MCU Limited, China
http://www.stcmicro.com

Intel MCS-51/8051 core with a few modern quirks,
this particular part has the largest internal eeprom option (53KB) of the range

Official free programming tool: "STC ISP programming software" (also an open-source alternative "stcgal")
programming is via simple 2-line tx/rx serial, so hardware required is just any serial/usb-to-ttl converter.

Seems these chips cannot be dumped, there's no official or known way to read from them at all (other than an id string),
so there's no protection, lock bits etc. basically the whole ISP protocol is write-only. There's no read, program, erase, verify etc. like other stuff, it's just download the hex and run.
I guess that's their way around the whole code security issue

No official IDE/compiler/assembler
official docs refer mainly to "Keil uVision" (this is actually "Keil C51" which is a commercial IDE + C compiler package)
price is by quotation only but whatever it is will be too much for me
free eval version available but is mostly crippled, mainly by max 2KB code size.
Free open-source alternative: SDCC "Small Device C Compiler", no out-of-the-box support, but very good 8051 support in general so should be useable.

So, where to from here......?
Well been a very long time since i've done any 8051 stuff but I guess I could give it a shot with SDCC.
on the other hand, i've got some old PIC18F4520's laying around that i've noticed will fit the footprint with minimal modding

decisions, decisions ...

 

[Butter Meister]

I don't think the STC is gonna be an issue with anything, but that's another mystery chip to look at if you wanna do a total reverse engineering.

 

[rockbottom]

Been a while since last post, lots has happened...

I'm reasonably sure i've figured out just about every detail of this thing now
Can now confirm 100%:
game configs are hard-set in the cplds
mcu just saves/loads softdips settings and issues a reset pulse to master cpld on power-up, no other function, responds only to 2fffe0 rd/wr
master cpld to mcu interface is just a very simple pass-through
game switch is done by: unlock: wr 2ffff6(any data), switch: wr 2fff00(game number), wr 2fff00(data=0) to get back to menu
68k menu code is very basic and buggy, they've just done it by editing pop n bounce rom with a hex editor

I've moved on to writing firmware now:
verilog definitions for CP1 (master cpld) and PCM2 are done. Not tested on hardware yet but looking good in simulation. Both are about 75% full (with all 161 original game configs) so looks like gates won't be an issue.
Code for MCU is done (used SDCC), again not tested on hardware yet but looking good in emulation using Mame (created a slot device with 8051 core).
Definition for cha board cpld is in progress... once that's done will move onto hardware testing, that's if my hacked up cart even still works

So all-in-all it's looking good, i'm planning to do "stock" firmware first, basically exact replica of original operation.
After that anything's possible, would like to have the mcu doing more, maybe setting up the cpld game configs on-the-fly so as any future game changes would just involve updating mcu, not mcu + all 3 cplds. Also in place rom flashing might also be possible to some extent, at least for P and V (would still require small hardware mod to wire up the /WE lines), also would most likely be uploading data via mcu's uart port so would be slow.

Fingers crossed there's no major hurdles on the final stretch ...

 

[Arthrimus]

Amazing work, I look forward to the real hardware tests!

Also in place rom flashing might also be possible to some extent

That's something that I was hoping to hear. I wonder if an entirely custom cart could be made based off of the work you have done here, but adding level shifters to the buss so the cart interfaces with the Neo Geo at the correct voltage, and adding user friendly programming capability. If those oddball flash chips are obtainable it seems like these carts could be built from scratch.

 

[rockbottom]

Should be possible for P and V, unfortunately for C the data lines just go directly to the cart slot, not to the cpld, so not possible.

... I wonder if an entirely custom cart could be made ...

Actually that would be far easier than reverse engineering this one The only show stopper is not being able to get big enough flash chips, of course there's other ways but then it becomes too expensive and there's no point when other solutions are already available (Darksoft etc.)

 

[Arthrimus]

Should be possible for P and V, unfortunately for C the data lines just go directly to the cart slot, not to the cpld, so not possible.



Actually that would be far easier than reverse engineering this one The only show stopper is not being able to get big enough flash chips, of course there's other ways but then it becomes too expensive and there's no point when other solutions are already available (Darksoft etc.)

I thought you potentially found a vendor selling these chips. In any case if the flash could be transplanted to a custom PCB that would be nice. One of the biggest disadvantages of the MVS multis that are available is loading time. The instant nature of these cheapo multicarts is fantastic.

 

[rcboosted]

Been a while since last post, lots has happened...

I'm reasonably sure i've figured out just about every detail of this thing now
Can now confirm 100%:
game configs are hard-set in the cplds
mcu just saves/loads softdips settings and issues a reset pulse to master cpld on power-up, no other function, responds only to 2fffe0 rd/wr
master cpld to mcu interface is just a very simple pass-through
game switch is done by: unlock: wr 2ffff6(any data), switch: wr 2fff00(game number), wr 2fff00(data=0) to get back to menu
68k menu code is very basic and buggy, they've just done it by editing pop n bounce rom with a hex editor

I've moved on to writing firmware now:
verilog definitions for CP1 (master cpld) and PCM2 are done. Not tested on hardware yet but looking good in simulation. Both are about 75% full (with all 161 original game configs) so looks like gates won't be an issue.
Code for MCU is done (used SDCC), again not tested on hardware yet but looking good in emulation using Mame (created a slot device with 8051 core).
Definition for cha board cpld is in progress... once that's done will move onto hardware testing, that's if my hacked up cart even still works

So all-in-all it's looking good, i'm planning to do "stock" firmware first, basically exact replica of original operation.
After that anything's possible, would like to have the mcu doing more, maybe setting up the cpld game configs on-the-fly so as any future game changes would just involve updating mcu, not mcu + all 3 cplds. Also in place rom flashing might also be possible to some extent, at least for P and V (would still require small hardware mod to wire up the /WE lines), also would most likely be uploading data via mcu's uart port so would be slow.

Fingers crossed there's no major hurdles on the final stretch ...

Awesome progress! Does this mean it might be possible to partially overwrite some of the games on there and burn other games onto it? Getting rid of unpopular games and put in games that are more popular.

I'd like to sign up for the waiting list for the mod kit or whatever that is needed to do the above.

These carts are so cheap and abundant, it wouldn't be too expensive to just have a list of certain games on 1 cart, and a different list on another without having to find bigger flash chips.

 

[rockbottom]

Agreed, all-flash approach is best, there's some Chinese sellers list them, I will order some and see what happens.

@rcboosted yes with custom firmware it should be possible to rewrite the cart anyway you see fit, whatever games you want. I won't be selling anything myself, I'll eventually put everything on GitHub as a open source DIY project. Perhaps in time somebody may offer some kind of service to non-diy-ers?

 

[Butter Meister]

I certainly have the means to offer a flashing service like that. It might have to be kept on the down low a bit .

 

[West]

Well, just won a MV-1C from @Arthrimus. Thanks again btw. Following this thread with great interest. Collecting MVS carts is the last thing my wallet needs right now

 

[rcboosted]

I finally received my 161 cart yesterday, it looks a whole lot different than what I've seen online. I know there are many versions, but I don't think it even looks like the PCB you guys are working on anymore based on description? I can post better pics if there's interest.

 

[Rom1]

It's in the wild since a year: https://wiki.neogeodev.org/index.php?title=161-in-1_Series_1&t=20200912131532

 

[rockbottom]

I finally received my 161 cart yesterday, it looks a whole lot different than what I've seen online. I know there are many versions, but I don't think it even looks like the PCB you guys are working on anymore based on description? I can post better pics if there's interest.

That's what we're calling a version 4, which seems to be the latest version so far.
My cart is a v2 but having compared with pics of v3/4, the only significant change seems to be the different type M and S chips.
(I don't currently have a solution fo reading/writing those but they're fairly common with datasheet available so should be easy to knock up an adapter pcb or whatever.)
Of course software changes are possible, would be interesting to get a v3/4 dump to see if anything's changed, particually if bugs in the P menu code have been fixed.

Interesting side note regarding M: seems they made some very strange rom choices for some of the later encrypted-M games. svc, kof2001, kof2002, matrim etc. all use ancient hacked up M roms dating from around 2003-2004 which (if memory serves) was before the encryption was properly broken. Guess they couldn't be bothered to get clean decrypted code from mame