Quoting @wwylele here:
Hi, I saw that godmode9 added cart save dumping. I tried it, but only 1 of 7 of my carts got the save recognized and dumped. For others the save file just doesn't display in the cart drive. Do you know what could be happening here?
These are the games I tried (all Japanese version, on both Japanese o3ds and n3ds):
mario 3d land
new super mario bros 2
pokemon y
pokemon alpha sapphire
pokemon mystery dungeon: gates to infinity
Kirby triple deluxe
pokemon super mystery dungeon (This one succeeded)
Can't do much myself, we'll need your help @dratini0 - got any clue? And, @wwylele, can you add some info? Did these carts simply not display their saves in the gamecart drive?
Right, they simply didn't display their saves in the gamecart drive. Additionally, the jedecid file isn't displayed for these problematic games either.
card2 games aren't supported at all, dunno if those are.
Among my list only the two big pokemon games (Y & AS) are card2. Others are card1
Hmm, memory serves me right ORAS and gates to infinity are card2 as well, but I might be wrong. In any case, I will have code that can ascertain this ASAP.
In the meantime you can tell for sure by looking into the header for the 3ds file in the hex editor, finding the line that says 188 and checking the sixth byte (offset 0x18d). If it is 01, it is a card1, if it is 02, it is a card2. I am not sure what 00 or 03 means.
Among my list only the two big pokemon games (Y & AS) are card2. Others are card1
I posted this right after I checked my games using ctrtool. I assume the card type reported there is correct?
Oh, sorry. Probably it did the same thing as I was suggesting, making me a smartass. In this case, I have no clue what is going on.
My best guess at this point is buying samples and opening them up and/or looking at the transactions with a logic analyzer. In any case, thank you for pointing this out - this will take me some time.
In the meantime you can tell for sure by looking into the header for the 3ds file in the hex editor, finding the line that says 188 and checking the sixth byte (offset 0x18d). If it is 01, it is a card1, if it is 02, it is a card2. I am not sure what 00 or 03 means.
Don't need to, you can just look at the serial on the label. EXXX are card2.
Anyway, you can add Mario & Luigi: Paper Jam and Professor Layton vs. Ace Attorney to the list, in case that matters. (both US versions.)
Oh, interesting, never realized that, even though the NTR had something similar going on.
And thank you for the further examples!
On 21 October 2019 01:11:52 BST, Ammako notifications@github.com wrote:
In the meantime you can tell for sure by looking into the header for
the 3ds file in the hex editor, finding the line that says 188 and
checking the sixth byte (offset 0x18d). If it is 01, it is a card1, if
it is 02, it is a card2. I am not sure what 00 or 03 means.Don't need to, you can just look at the serial on the label. EXXX are
card2.Anyway, you can add Mario & Luigi: Paper Jam and Professor Layton vs.
Ace Attorney to the list, in case that matters. (both US versions.)--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/d0k3/GodMode9/issues/553#issuecomment-544307425
Bálint Kovács
It's not a bug or CARD2. Some 3DS games come with new save flash/EEPROM types your code doesn't recognize. Should be a matter of adding them to the supported list and using the right read/write code paths.
Hmm, I don't think so. They can't seem to read the jedecid_and_sreg.bin, which is there just for this reason. So unless I messed up the implementation of that, I suspect it is something more interesting (like flash chips that start in QIO mode or something)
On 21 October 2019 02:00:41 BST, profi200 notifications@github.com wrote:
It's not a bug or CARD2. Some 3DS games come with new save flash/EEPROM
types your code doesn't recognize. Should be a matter of adding them to
the supported list and using the right read/write code paths.--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/d0k3/GodMode9/issues/553#issuecomment-544312388
Bálint Kovács
@dratini0 - (maybe that helps) the jedecid file showed up even in cases where the chip pointer lead to NULL. I disabled display of the file in these cases.
Okay, that might explain it. How about I drop that file and add a function to the diagnostic menu or something? That way, it can try to estimate the size.
https://github.com/d0k3/GodMode9/commit/ae583300e6ec8eb122c8de004c7684d7b88d91f3
I doubt that explains it. I really only hide the file in cases where the pointer to it's data leads to NULL.
If you need some debug data about carts somewhere, there are two ways to do it, either a temporary test build, or you do a permanent A button menu Cart Info function (which should look somewhat good).
(if you got trouble making it look good, I can also help)
To clarify, you mean HOME > More, right? And I could model it after System info, I guess?
To clarify, you mean HOME > More, right? And I could model it after System info, I guess?
I actually meant the menu that pops up when you press A+R on the cart drive. And I thought about something like drive info. If there is a lot of info and/or scrolling is required, it may be worth it using the text viewer (same as System info does).
Also, nds carts with IR aren't supported right now. This may be already known, just like card2, but I figured I'd mention it, just in case they've been forgotten about.
Anything I can help with? Such as finding out the device ID of my cartridges? I got sometime to test stuff. I can dive into the code and find where I should modify, but a quick pointer helps a lot.
Anything I can help with? Such as finding out the device ID of my cartridges? I got sometime to test stuff. I can dive into the code and find where I should modify, but a quick pointer helps a lot.
Might be a good idea to tag @dratini0 here, cause he's the dev behind the save management.
Progress report: I reverted ae58330, and now all of my carts show the jedecid file. The situation for the actual save remains the same. Here is the jedecid for each card:
62 26 11 00 mario 3d land
62 26 11 00 new super mario bros 2
EMPTY pokemon y
EMPTY pokemon alpha sapphire
62 26 13 00 pokemon mystery dungeon: gates to infinity
62 26 11 00 Kirby triple deluxe
C2 22 13 00 pokemon super mystery dungeon
It can be seen that all games that don't get save recognized have unusual (?) IDs (or maybe Japanese cartridges are usually made by a different manufacturer which has a different ID)
Another update: by adding the new IDs to the list, I was able to dump all the Card1 saves I have.
@wwylele careful reverting this. In some cases that could mean accessing a NULL pointer.
@d0k3 well the worst case is just crashing my 3ds... right?
Correct. I just meant you cannot revert this in a pr :).
I wasn't considering PR this. Though now you mentioned it, I do feel this check of NULL pointer is strange. The code for assigning chip always sets it to NULL whenever it doesn't recognize the jedecid even when it exists (which was the reason the file didn't display for me). Moreover, I skimmed the code of reading jedecid but didn't find it used the chip pointer anywhere. I probably probably missed it though.
@dratini0 - no need to do this quick, but we'll leave this open until you say it's fixed. @wwylele, you could of course do a pull request of your own. I'd just want @dratini0's feedback cause this is his development.
@dratini0 - not intending to nag. We want to do another small GM9 release around christmas. We don't need to fix this until then (after all, this bug only describes stuff that hasn't worked before the save management was a thign anyways), but we can also wait for your changes.
@dratini0 (here I am, nagging again) - is there any chance you got an update on this?
I tried Pokémon X and there's no save file listed. It would probably be a safe assumption it wouldn't work anyway since it doesn't work with Pokémon Y, but I can confirm it doesn't. Same issue with WarioWare: D.I.Y.. Super Scribblenauts works fine though, so I do know it's supposed to work with NTR cards.
@flarn2006
card2 games aren't supported at all
WarioWare DIY is a special case where nobody has bothered figuring out the 8 MB save file size, none of the DS era save managers ever supported it either.
Do you happen to know of anything that will work for that game, for
injecting a save?
On Thu, Dec 3, 2020, 1:42 PM Ammako notifications@github.com wrote:
@flarn2006 https://github.com/flarn2006
card2 games aren't supported at all
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/d0k3/GodMode9/issues/553#issuecomment-738211189, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAFHZUOLAHQPBWMHBJATAW3SS7LZPANCNFSM4JCT2ORA
.
Ooof, that issue, another old one. It's obviously not fixed yet. Maybe @dratini0 is still around and can chime in. Maybe @wwylele found out something more. To be honest, my own knowledge of this is limited.
Hi, I'm back. Sorry for the unannounced and unexplained (and protracted) absence. Part of it was starting a new job, part of it is just being distracted by other stuff.
I got myself a Japanese copy of Pokemon X, and it definitely looks like a Card2 game. The NCCH flags from 3DSExplorer: 0x00 00 02 01 02 00 01 00. I have also looked what the OS does with that cart, and it doesn't pull the SPI CS line low. Not when doing a backup with checkpoint, and not when actually starting the game. So, long and short of it, my copy certainly has no EEPROM for us to back up.
As for WarioWare DIY, actually, the Desmume people have figured it out, except their code is there to emulate the cartridge and we would need to interface with it. So it's certainly not impossible, but let's just say I'm unwilling to give you a timeframe on it yet.
card2 saves to the same chip as the rom, but the save area is read-write while the actual game area is read-only.
afaik gm9 can already read this part, it just blanks it when dumping one of those carts
so surely, the solution would be to do the same thing as when dumping the rom, but instead of reading the whole chip you read just that part? unless I'm missing something
and yeah, emulators have been able to handle 8MB save files for a long time. I don't think anyone's taken the time to figure out how to actually read/write from retail carts though.
Forgot to mention, do you have a 8MB save DS cart? If not, is there anything we could do over on our end to collect any info that might be useful?
I also want to remind that the issue is not just about card2 save. I have checked that in my original list, only pokemon y / pokemon alpha sapphire are card2. The rest are card1
Tri Force Heroes is also CARD2 (that one is HUGE).
card2:
Pokemon X CTR-EKJA 0004000000055D00
Pokemon Y CTR-EK2A 0004000000055E00
Tobidase Doubutsu no Mori CTR-EGDJ 0004000000086200
Animal Crossing: New Leaf CTR-EGDE 0004000000086300
Animal Crossing: New Leaf CTR-EGDP 0004000000086400
Tomodachi Life CTR-EC6E 000400000008C300
Tomodachi Life CTR-EC6P 000400000008C400
Tomodachi Collection: Shin Seikatsu CTR-EC6J 000400000008C500
Pokemon Omega Ruby CTR-ECRA 000400000011C400
Pokemon Alpha Sapphire CTR-ECLA 000400000011C500
Chin gumoa Apateu CTR-EC6K 0004000000120C00
Girls Mode 3: Kirakira * Code CTR-ECDJ 000400000012D800
Doubutsu no Mori: Happy Home Designer CTR-EDHJ 000400000014F000
Animal Crossing: Happy Home Designer CTR-EDHE 000400000014F100
Animal Crossing: Happy Home Designer CTR-EDHP 000400000014F200
Nintendo Presents: New Style Boutique 2: Fashion Forward CTR-ECDP 000400000016A100
Zelda no Densetsu: Tri Force 3-Juushi CTR-EA3J 0004000000176E00
The Legend of Zelda: Tri Force Heroes CTR-EA3E 0004000000176F00
The Legend of Zelda: Tri Force Heroes CTR-EA3P 0004000000177000
Pokemon Rumble World CTR-ECFA 0004000000185A00
Style Savvy: Fashion Forward CTR-ECDE 0004000000196500
Tobidase Doubutsu no Mori: amiibo+ CTR-EAAJ 0004000000198D00
Animal Crossing: New Leaf - Welcome Amiibo CTR-EAAE 0004000000198E00
Animal Crossing: New Leaf - Welcome Amiibo CTR-EAAP 0004000000198F00
reminder:
you can just look at the serial on the label. EXXX are card2
I don't think this is super useful info though, card2 implementation should just automatically work for all card2 games without needing to do anything special for any games.
@wwylele Okay, sorry, that was a fool's errand. Sorry. I clearly forgot what this thread was about, and I didn't read it properly. On the other hand, we now know the JEDEC ID of the offending chips is, so I can knock up a test build real quick.
@Ammako Wow, thank you for all the good info!
Re 8MB saves: I have both WarioWare DIY, and Art Academy. WarioWare DIY is the interesting case, which desmume calls retail NAND. Art Academy is also 8MB, but it's just a good old 64Mbit SPI flash, IIRC not that dissimilar to the ones found in 3ds carts. I think I have some improvement for it, but I already forgot what I was even trying to fix...
Re card2: I recall thinking the same thing, trying it and failing. But then again, I might very well have missed the blanking behavior... I will try again.
Interesting, I didn't know there were different kinds of 8MB save carts. Any way I can check what kind Daigasso! Band Brothers DX and Jam with the Band use?
I seem to remember reading that Jam with the band was SPI flash too. As to where, I am not sure.
@wwylele Okay, here is a test build. Would you mind trying it on the carts you got JEDEC IDs for?
It adds support for the new IDs based on the hypothesis that they are very similar to these chips. I would assume 0x622611 is 128kB, and 0x622613 is 512kB, but I just put them down as 8MB for the time being. It should will read mirrors if you read past the end of the memory, so can you let me know how often it repeats to confirm the size? (Or, if you are so inclined, you can always just upload the save dumps and I can figure it out.)
There is a not insignificant chance that writing (or something else) is broken, so make sure to have a backup of your saves in checkpoint. Writing is suspect in particular, because I went with the write page size of 256B as per the datasheets, as opposed to the 64B used in my 3ds carts.
Finally, I have added yet another silly file (don't worry, no plans on getting it merged). It's for getting the SFDP data, which is basically the chip's self description. It didn't work for my carts, but it might be worth a try. If it comes out as anything but 0xFFs, please post it here if you don't mind.
Without further ado then:
Anyway, you can add Mario & Luigi: Paper Jam and Professor Layton vs. Ace Attorney to the list, in case that matters. (both US versions.)
^ seems good over here, sfdp is all 0xFF's though unfortunately
(Can't comment about writing, though.)
It is getting late today. I'll check with my 3DS on weekend (after I remembering how to do all the stuff after a year lol)
Meanwhile, I checked the save data size recorded in the game's ExHeader:
62 26 11 00 128K (mario 3d land (Japan))
62 26 13 00 512K (pokemon mystery dungeon: gates to infinity (Japan))
Also just a small observation: one of the byte in the JEDEC ID indicates exactly how you should shift 1 to get the size, like for "62 26 11 00", the size is 1 << 0x11 = 128 * 1024
@Ammako Thank you for checking! That is good news. I guess the SFDP was a bit of a long shot. Thank you for trying, anyway. (I wonder if the lack of the SFDP was one of Nintendo's customizations on the flash chips? We might never know.)
@wwylele
Don't worry, take your time. It's not like I didn't!
Re JEDEC ID: Well spotted. I knew that the last byte indicated size, but I wasn't sure about the mapping, and whether that was consistent between years and manufacturers. Looking at the table in card_spi.c, that actually holds true for all of the old flash chips that have that byte set too.
Re cart header: Yes, that should settle it, thank you! On a second thought, for 3ds carts, it might make more sense to use the cartridge header for detecting the save size, and use all the same read and write functions. There is good chance Nintendo is doing the same, but I don't know for sure. (Given that this is the first generation where Nintendo didn't stuff the cartridges full of exotic hardware, and it is actually the OS reading the cartridge, not the game) In either case, that prototype will have to wait until the weekend too.
Oh, activity! It's correct, GM9 can already read the card2 save, we just blank it so we got clean dumps. Writing is not yet possible, though.
Alright, do we still need to leave this open, or is this fixed by your pull request @dratini0 ?
It fixes the cards that @wwylele has. The following cards still won't work, however:
That's a pleasingly short list, I think :-)
Most helpful comment
Oh, sorry. Probably it did the same thing as I was suggesting, making me a smartass. In this case, I have no clue what is going on.