EEPROM Example Not Working Correctly on DSi

[fasteddy5]

Hi everyone,

I'm quite new to the DS development scene, so I'll start by thanking everyone who put their time into this remarkable development environment - downloading, installing, making the examples and running them on my DSi was a breeze!

That being said, this - my first post - will, naturally, be a question about something that doesn't seem to work...

I'm trying to use the eeprom (card) example to read game data from a cartridge inserted into my DSi. It would appear, though, that all of the functions (cardReadHeader(), cardReadEeprom(), etc) are all returning null data. I'm guessing that the current library functions don't play nicely with the DSi (likely something to do with the new hot-swap card functionality), but I don't know for sure. I installed the entire development environment from scratch today using devKitProUpdater-1.5.0, so I'm assuming I'm all up to date.

Can anyone confirm that this is a known issue with the DSi, and not just me doing something silly?

Thank you, and best regards.

[zigg]

I don't have a card for my DSi yet to check this myself, but is it still returning nulls etc. after you reload the card (eject/reinsert)?

[fasteddy5]

I can eject/reinsert a cartridge (and I've tried a number of different cartridges just to be sure) until I'm blue in the face and I still just get null values. The only time that I do get any information is if I leave my homebrew cartridge in after starting it up and don't ever eject it, in which case the cardReadHeader() function seems to work correctly. As soon as I swap cartridges I get nothing.

Everything seems to work fine on a friend's DSLite, so I'm assuming this is a DSi compatability issue.

[zigg]

A cursory search found a mention of savsender not working on the DSi. So I think you might be on to something, unfortunately.

This is particularly troubling for me, actually, since I am writing a host program specifically for manipulating the save chip on a card.

I do know a little bit about card.c (I've trivially modified it to support the 64 mbit chip on Band Brothers DX, which I'll contribute back once I'm confident it works well), but I really have no idea what it would take to get it working on the DSi.

Hopefully, once DSi-enhanced titles start coming out, someone can use them to figure out how to get into DSi mode and once again access the save chips... though we might have to be in DSi mode to do it.

[fasteddy5]

I was actually wanting to create something similar to savsender when I first looked into devKitPro/libnds. (At the time I didn't know savsender or the WiFi Backup Tool existed - not that it matters, as neither work on my DSi.) I don't have any direct experience with DS programming, but have done a bunch of C/Assembler/Electronics design with other microcontrollers and figured between the example code and help through this forum I could probably muddle my way through it. For the time being - until someone figures out how to communicate with cartridges on the DSi - I'll have to come up with another project.

For what it's worth (and bearing in mind that this is wild speculation with very little DS-specific knowledge to back it up), the current inability to read cartridge/eeprom data on a DSi might not have to do with the "DSi mode" conundrum. Bear with me here...

My understanding is that with a DS-Lite you had to insert the cartridge before you turned the power on, and (theoretically) leave the cart in until the power was off. There was never any built-in provisions for someone to swap carts while the power was on, so certain assumptions would have been made (by Nintendo, by the devKitPro folks, etc) about the state of hardware control registers, the sequence of events required to access data on a cart and so on. The DSi, on the other hand, allows for cart "hot-swapping", so it's entirely possible that when the system detects that a new cartridge has been inserted it does some of the initialization leg-work automatically, likely altering the sequence of events required to access cart information.

Interestingly enough, if you look in the card.h file in libnds, you'll see comments that say "These commands require the cart to not be initialized yet, which may mean the user needs to eject and reinsert the cart or they will return random data". Perhaps the DSi automatically "initializes" carts when they are inserted, thus rendering the current cart access functions...uh...confused.

As I said, just a theory...

[zigg]

As I understand it, on DS, the save chip is always available.

But to read the card header et al, you need to get the decrypter working. That's what the reinsert is for.

I've seen this while developing savehost, if I boot off SLOT-2 or WMB; I can actually see the type and size of save and read it. IIRC, savsender can deal with it too. But cardReadHeader returns garbage until the reinsert is done.

This is just to make the point that I'm not so surprised that cardReadHeader fails on DSi, but the *Eeprom functions, I am surprised about.

[fasteddy5]

You bring up an interesting point - I'll have to try just reading EEPROM save data without bothering with the header stuff to see what happens. I assumed (yes, yes, I know about assuming...) that if I couldn't read the card info I couldn't read anything off of the card period.

For what it's worth, though, on my DSi if I boot to my homebrew card (what do people who aren't stealing ROMs call these things anyway?!) - a SuperCard DSonei - and run a program that reads the card header, it does actually return a game name. (I believe the DSonei claims to be "Fish Tycoon" or something silly like that) It doesn't want to talk about any EEPROM, though, which I gather is because the card doesn't have any EEPROM in the traditional sense. As soon as I eject and insert another card (or even just re-insert the DSonei) I get nothing but null values.

On another note, I realized while looking at the 'card' source code that my references to a "cartridge" in previous posts could be confusing, as the official terminology seems to be that a Slot-1 device is a "card" and a Slot-2 device is a "Cartridge". In this thread I have always been referring to a Slot-1 device, as the DSi doesn't even have a Slot-2. My apologies if I confused anyone along the way.

[cyrusomega]

I have to ask, what were your findings on this? Being able to properly handle DSi hot-swaps seems like a logical next step for libnds if there is in fact an issue.

That said, I bet that under the hood the hardware is blocking/ignoring the reads until some sort of transactional event is triggered. A hey-i-am-ready-for-data flag being set or something. The older DS probably had no such gatekeeper logic and thus "just worked" because it acted as a dumb card reader.

Disclaimer, I wrote my own NES emulator back in the day for a CE project, but I am a bit out of date on the newer designs. Hopefully I know enough to help out though, as I have an interest in this.

[zigg]

Here's where I may or may not be able to help out, and my interest.

I started writing a program called savehost that was intended to provide access to the save chip (arbitrary reads/writes and card ID) to PC-based server programs. Beyond backup/restore this would also permit people who can't write for DS to create software to modify saves, including injection or extraction of user content (i.e. a next-generation version of my save tool for the original Band Brothers, something to allow sharing of Korg DS-10 works... etc.)

As part of this I have a slightly-patched version of card.c that appears to be able to handle the 64 Mibit Flash chip in Daigasso! Band Brothers DX. The only reason I haven't contributed it back yet is because I have not yet gotten around to making sure it handles writes properly.

I do have a DSi, but I don't have any solution for running code on it. I do know enough about card.c to provide a simple test program that anyone can run to get some debug output and tell what exactly is working. Just let me know if this is useful.

Tangentially: what are you guys working on? On my end, savehost is being rewritten with a TFTP server design, in part because I was having trouble with TCP, but also because I've really come to appreciate some of the possibilities from doing so. But it's really slow going because I'm a busy man. If we're working on similar things, perhaps we can pool our efforts. Just let me know.

[cyrusomega]

I am more or less learning how the system works right now. I have an Acekard 2i coming in soon so I can start writing some of my own custom apps/games. That said, backing up games saves seems like a first logical functional step but the tools that require the changing out the cartridge seem to not work for the DSi. I just dug deeper on the interweb until I got here

Just fyi, I would love to pool some know-how and make some high quality apps. BTW, here are some trivial behaviors from my DSi regarding card swapping...

1) Taking the card out during the suspend suspend state while playing a NDS game causes the system to reset (blue and wireless lights go out and you have to press the power key to get back going)
2) Taking the card out during the suspend suspend state while in the main DSi menu does *not* cause the system to reset
3) Taking the card out during normal gameplay causes the system to freeze but not reset.
4) Removing the card normally or by pulling it straight out (ie not triggering the push down release lock things) has no effect on the above cases.

I was hoping that during suspend mode it just turned the power off to everything but RAM and kept the CPU registers cached somewhere, but it appears there is some logic that is actually checking the card. I then was hoping that the card release mechanism was just firing a trigger when you pressed down to release the card but as I stated in (4) this is not the case.

Thoughts?