Neo Geo Pocket Cartridge Protection Information Database
You guys are great! You really make this NGPC homebrew community work.
After my last post explaining some technical details about NeoGeo Pocket SaveGame Backups, we got a little dialog going. Loïc chimed in with a proposal to build a database of information about known cartridges. The idea is that, when the information would not be retrievable from the cartridge, a database lookup could supply the necessary information about the cartridge.
Well, not only was this a good idea, but Loïc took it several steps further. He effectively built a database of NGPC cartridge identification and protection information. He was able to obtain information about almost every cartridge. From his data, it seems that he’s only missing data on 12 cartridges. Of these 12, some can be inferred from other data or dumped by someone else.
At the moment, I’m working on other things, but I need to come up with the best way to store and parse this data. Then it can be integrated into future builds of NeoLinkmasta.
If you are interested in working on adding this (or any other feature) to the software, please get in touch with me.
Thanks guys!
Nice work! If this was implemented, would each cartridge be recognized correctly, and all saves would work properly when flashed back onto the cartridge? Also, would this in any way fix the Cotton save problem, or is that completely on the game software side and required a ROM fix?
That’s the idea. When checking the protection info of a cart, it could then be compared to the database. If there was a mismatch, the software would know that it was probably a flash cartridge. Then it could use the database info to properly handle savegame data (instead of relying on the protection info from the cartridge).
I don’t think this has anything to do with Cotton. I think that will need a ROM patch. There’s something about that game that does something different than the others.
does it means that cotton have savegame issue on a flashcard, and is ok on an original cartridge ?
Yes, I think so. My guess is that somehow Cotton tries to read protection info, but I have not been able to track that down anywhere.
So the game have some kind of test that makes him skip the flash write function ?
I don’t really know how to disassemble stuff, but with neopop, I can see that save function depend on fixed address :
DIS 2D83F4: LD RW3, 0x08 “C7 31 03 08”
DIS 2D83F8: LD RA3, 0 “C7 30 A8”
DIS 2D83FB: LD RB3, 0x11 “C7 35 03 11”
DIS 2D83FF: LD (0x6F), 0x4E “08 6F 4E”
DIS 2D8402: SWI 1 “F9” # erase block 17 (0x0FA000)
DIS 2D8403: LD A,RA3 “C7 30 89”
DIS 2D8406: CP A,0 “C9 D8”
DIS 2D8408: RET NZ “B0 FE”
DIS 2D840A: LD RW3,6 “C7 31 AE”
DIS 2D840D: LD RA3,0 “C7 30 AS”
DIS 2D8410: LD RBC3,1 “D7 34 A9”
DIS 2D8413: LD XHL3,0x00004724 “E7 30 03 24 47 00 00”
DIS 2D841A: LD XDE3,0x000FA000 “E7 38 03 00 A0 0F 00”
DIS 2D8421: LD (0x6F),0x4E “08 6F 4E”
DIS 2D8424: SWI 1 “F9” # write data at 0x0FA000
DIS 2D8425: LD A,RA3 “C7 30 89”
DIS 2D8428: RET “0E”
this function seems to be called from 3 points in the rom :
0x2D86FA
0x2D8A0F
0x2E7205 => at least when the games saves high-score
Great data once again, loïc.
Let’s decode this a bit more.
First it is doing system call 0x08 to erase the memory at 0xFA0000-0xFBFFFF. From my data, this should be unprotected. It then checks the return code of that erase to see if it completed properly. This is the only place in your ASM dump that would return prematurely, and I assume it is where it fails, but let’s look further.
The system call to erase a flash sector will send the commands to flash and then poll the flash until the operation is complete. There are a few ways this can fail.
1) The system detect that there isn’t a chip at the requested location (unlikely).
2) While polling, it runs out of time. It will only poll it 0x200000 times and then give up.
3) While polling, the flash memory returns an error.
I’ll look at the flash writing one in a bit, but I think it’ll be very similar. I don’t know why it would be failing.
Is there anything before these calls at 0x2D86FA, 0x2D8A0F, and 0x2E7205 that might be checking flash mem?
well, no, the code before 0x2E7205 is a loop until player input the “A” button, then test a value in ram to know if you need to call 0x02D83F4.
I’ll try to skip that test and see what’s going on.
well, with nop instead of ret nz, it’s the same.
With bung card, when I change life number, after ‘saving’ life is set to 1 (either with nops or ret nz), so something is writen… I’ll try to search a bit more later, but that’s my first time playing at disassembly
[the code before 0x2E7205 is a loop until player input the “A” button, then test a value in ram to know if you need to call 0x02D83F4.]
What RAM value are they testing? What’s the address? Maybe it’s a system value (or maybe Cotton-specific).
no, the address is in the range of ram data (4000+ if I remember), not a system value.
But I’ve tested with neo geo cup 98, and savegame fails (not the same way).
So… (need more testing), maybe it’s because of the under 16mbits cartridge structure.
16mbits and 32mbits have the same layout, but 8 and 4 are different.
Block 17 is only 2000 bytes on 8mbits cartridge, and 10000 bytes on 16/32mbits
can it be the source of problem ? ie any under 16mbits game that saves data in a block under 10000 byte will fail ?
maybe I’m wrong, but I’ll test a bit later with that. Tell me what’s your opinion on the subject.
I could also try to change coton to a 16mbits cartridge, and relocate savegame… don’t know how hard it can be :-/
You are on a good track with this idea of the block structure.
I think we could easily test this by hacking the code you pasted above to clear a different block.
What can happen is that it clears block 17, but that block isn’t quite the same spot as it would be for a 16mbit chip. Interesting. Yeah, this is hackable. Let me think a moment.
As a quick hack, though, it could be changed to block 15 (instead of 17). This could cause other problems, but let me think.
Scratch that. Erasing block 15 will kill some game data.
Okay, how about this.
Change the 00A00F00 that appears at byte 0xD841D to 00A01F00.
Also change the C7350311 that appears at byte 0xD83FB to C7350321.
I think that’s the fix, but let me know. Thanks, loïc.
You probably also need to change the 08A00F00 that’s at byte 0x131AC to 08A01F00.
Oh, wait. There’s probably more.
Yeah, there’s a 00A02F00 at 0xD83D7 that (I think) needs to be 00A03F00.
What’s worse is that I typed some stuff wrong too. I see it now. So, here’s the list. They may not all be necessary. They may not be everything, but I don’t see others at the moment.
Change the C7350311 at addr 0xD83FB to C7350321.
Change the 00A00F00 at addr 0xD841D to 00A01F00.
Change the 00A02F00 at addr 0xD83D7 to 00A03F00.
Change the 08A00F00 at addr 0x131AC to 08A01F00. [I am not sure about this one]
Does the Bung cartridge fail the exact same way, and is there a way to correct this within the flash cartridge, so that there’s no need to hack every single title with displays this particular problem?
Well, let’s make sure this hack/patch technique actually works properly. Then maybe I could come up with a fix. One option might be to automatically patch a ROM while writing it to the cart.
I haven’t come up with a good way to do this in the cart, yet.
The Bung cart actually has another odd issue with erasing that I found when I made the multirom menu thing. Anyway, I can’t type right now. I gotta run.
Sorry for the delayed reply.
@morden : bung fails the same, I do my tests on them as I don’t own Flavor’s flash unit ^^
I don’t know about actual flashmasta, but cartridge must have a programmable controller to overcome this issue, having a dedicated chips that emulate the block layout for 4/8mbits games, making them more complex I suppose.
@flavor : I’ll try to take a look at your changes. relocating savegame seems tricky… easy for the saving part, but harder regarding the retrieving data process because the code can do direct readings on the flash, so it requires a full disassembled code to search for address within save range. And some addresses could be computed in ram, mostly base + computed offet :-/
I agree that this isn’t a fix for each case. However, I think that the save info in Cotton is very limited. I think the hacks mentioned may be all there is. I think maybe there is one place that saves and one that restores. I did a quick test on NeoPop, and it seemed to work, but it would definitely need testing.
Also, it kinda breaks our idea how to handle savegames by using the dumped protection info. 🙂
I think the savagame handling is still relevant, at least for 16/32mbits games (42/105).
Do you think it’s possible to add 4/8mbits handling to the flashmasta cartridge ? (it certainly is, but is it worth the pain ?)
Keep in mind that this isn’t a problem for all 4/8mbit games. It’s only a problem for those ones that save to the boot block area.
To make the Flash Masta cart handle this, there would need to be some way to somehow write to the CPLD. Either that or there could be a physical switch that you could toggle based on cart size. Neither of these options is that great/realistic, really.
I’ll think on this a bit more.
At last some raiatntlioy in our little debate.
A lot of GameBoy Advance clients would patch ROM images to save correctly when flashing them onto a cartridge. That would work, and the database would ensure that each ROM requiring a patch is recognized and patched correctly.
This would fix games that won’t save at all, but what about save import / export and swapping them between original games and those on the Flashmasta? At the moment, restoring saves to games on Flashmasta isn’t really working, but with the fixes you guys are talking about here, would it be possible to, for example, dump a save from a legit copy of Cotton, upload it to Flashmasta and have the game working, saving further progress, etc.? And could that progress be later dumped and transferred to the original game without any glitches?
That’s a lot of questions, but there’s so much I’d like the client software and the cartridge to be capable of doing, and as a user, I’d like everything to work perfectly. Haha.
I’ve modified my Cotton dump
(nearly the same as yours :
Change the C7350311 at addr 0xD83FB to C7350321.
Change the 00A00F00 at addr 0xD841D to 00A01F00.
Change the 00A02F00 at addr 0xD83D7 to 00A03F00.
Change the 08A00F00 at addr 0x131AC to 08A01F00.
)
First, I did nothing more and flashed… and it failed.
I guess there’s a memory test after writing, so I created a 16mbits image by copying twice the patched rom and now I’m able to play Cotton with savegame.
I’ve finished the game with emu (dragon boss is tough, last one is too easy), it seems ok (graphical glitches in the last cut scene, but maybe the same with original rom)
I think morden would be interested in the rom, but I don’t know if I need to create an ips patch + copy /b patched_rom + patched_rom new_rom_with_save_enable
Oh, that 0xD841D change was probably just an accident on my part. I’ll edit mine above.
When I tested it on NeoPop, instead of making a copy of the game twice, I just filled the second 0x100000 bytes with 0xFF. Though, I would have thought that it would do the same thing. Odd.
One interesting thing is that, on some Bung carts, the flash chip they used has a sector erase and a block erase. I think they consider a block to be 0x100 bytes (IIRC offhand). The command for erasing a block on that chip is the same as the command for erasing a sector on official carts. I’m surprised that this hasn’t caused more problems on those carts.
If you could upload an IPS patch that would fix the “widely available” ROM image [CRC B8A12409], I’d be happy to try it. I don’t remember any glitches, but completing the game doesn’t take that long, so I could check both versions, the patched one, and the original.
Too bad the save issue wasn’t fixed in the Capital release. There is a +4 trainer for this game, and they must have noticed the save error if they played it on the Bung cartridge. Oh well.
I’ve created 2 ips :
one for Japanese rom with CRC B8A12409
one for EU rom with CRC 1BF412F5
Let me know if you find issue. I’ll upload that on the forum if Ed don’t mind.
here’s a list of game that must have broken savegame with flash cartridge :
B.M.Unitron1
BM2000
COOLBOARDERS
COTTON-NGP-C
CRUSH ROLLER
HANAFUDA DJ
InfinityCure
KOIKOIMARJAN
MELON
MEMORIES OFF
Mahjong K2
N.C.M.color
N.Mystery B.
NGC98+COLOR
NGP BBall
NGP YAKYUU
NIGE-RONPA
NeoGeo Cup98
PACMAN
PTennisColor
PUYOPUYO2
PUZZLE LINK2
PocketTennis
SHANGHAIMINI
TSUNAGETE P2
party mail
shogi color
shogi
Other games can have problems too, as some of them uses 0xF0000 for saving, but have block 0x0F8000 and 0x0FA000 protected. So saving will erase data of these 2 “protected” blocks
I just saw something about this on television. It talked the same things you wrote about.
I go to school in Canada and we just now are learning about this in our class.
Thank you for helping me with the last little
bit of my report.
Thanks for the outline of tv stuff.
I definitely think that cable tv is going to go away.
Or at a minimum have to change with the times.
Online tv is definitely the wave of the future.
As internet speeds get quicker, everyone will be watching their tv shows on sites
like this.
What do you know about this? I think there’s a lot more to the subject
I was just watching this on television this week.
They spoke the same things you wrote about.
My site :: tv free (Dawn)
Garden – June 2011
Feel free to visit my page; Oakland Hills Golf Course (http://www.youtube.com)
Im glad i check this out. I was actually concerned with accomplishing this very same thing within my home.
It doesn’t seem which bad right now.
my web site: Furnace Maintenance (Dewitt)
Feel free to surf to my weblog; roofing gutters – Stefan,
After reading a couple of of the blog posts in your blog now, I wanted to tell you I actually like the way to blogging. Feel free to try my website and let me know what you think.
The bed store sounds produced up. Why not simply make your?