Reset Cart in DSi SLOT-1

[xbmbmx]

Hi!

first of all I want to mention that this thread is somewhat related to my thread here: Gathering DS flashcard knowledge - DIY "opencard" idea.

I am trying to rewrite the DevkitPro EEPROM example to also be compatible with DSi hardware (granted the howebrew is ran in DSi-mode through an exploit like MemoryPIT or Flipnote Lenny).

However, I am struggling with this.

GBATEK mentions that ejecting a cartridge from the DSi's physical slot will result in the SLOT-1 slot being powered off, requiring a DSi reboot (I assume) to be used again. A card reset is required however to read the header (because the encryption needs to be disabled on the physical cartridge).

I cannot get this to work.

My plan of attack was to check if the homebrew is in DSi mode, and if it is, use the disableSlot1() and enableSlot1() features of the devkitPro stack to do a "digitally triggered" card reset - this does however seem to simply not work.

Code snippet for reference:

...
        // Read the header twice to verify.
        // If the card is being encrypted, we will get random junk
        cardReadHeader(header1);
        cardReadHeader(header2);

        // Make sure we got the same data twice
        while (memcmp(header1, header2, 32) != 0)
        {
            // If not, the card needs ejected and reinserted into the DS
            // Or reset if ran in DSi mode, as the DSi does not have reinstert option
            if (isDSiMode())
            {
                disableSlot1();
                // Don't know if required, but inject some artificial wait (I have also tried without, no change)
                for (int i = 0; i < 25; i++)
                    swiWaitForVBlank();
                enableSlot1();
                for (int i = 0; i < 15; i++)
                    swiWaitForVBlank();
            }
            else
            {
                printf("Please eject & reinsert DS card.\n");
            }
            ButtonWait();
            cardReadHeader(header1);
            cardReadHeader(header2);
        }
...

I do still get Null values (leading me to believe SLOT-1 is still powered off). I do not know how to work around this or if I'm thinking fundamently wrong about this whole DSi slot-1 disabling thing.

What amazes me is when I run this homebrew from the SD card (not SLOT-1) with SLOT-1 being empty, and then inserting a card, I still get null values. This confuses me as I believed a reset has not occured yet and thus the CARD slot should not be disabled (or return null values on read). It does however so I'm confused.

It must be possible to circumvent as homebrew like GodMode9i allow you to dump multiple cartridges in and it does not seem to have this null issue (also somewhat confusing, if GBATEK is right and the reading slot is powered off, how can GodMode9i keep reading???). The GodMode9i source repository is quite big and I don't know where to look to find out how they fought this problem, but it must be possible.

Anyone who can explain to me what is going on here? I don't really understand what's going on under the hood and the behaviour I observed confuses me.

 

[tech3475]

Not sure if this is relevant:

NDS Slot / Cartridges
DSi carts are using an extended cart header (1000h bytes), with RSA signature (making it problematic to run unlicensed/homebrew code), the icon/title format has been also extended, and the cartridge protocol contains a new command (command 3Dh, for unlocking extra DSi regions on the cartridge, and for reading new DSi secure area blocks).
The NDS Slot's Reset signal can be controlled by software (required because otherwise one could use only command 3Ch or 3Dh, but not both). The Power supply pin can be also controlled by software (yet not 100% confirmed how?). Moreover, there's new cartridge inserted sensor. And, DSi prototypes did have two NDS slots; DSi retail consoles do have only one slot, but they do still contain prototype relicts internally (like extra registers and extra irq sources for second slot) (there appear to be also unused extra pins on the CPU, but they couldn't be used without desoldering the whole chip).

https://problemkaputt.de/gbatek.htm#dsibasicdifferencestonds

 

[xbmbmx]

Not sure if this is relevant:


https://problemkaputt.de/gbatek.htm#dsibasicdifferencestonds

It is somewhat relevant but I'm not interacting with a DSi cart, I'm interacting with a normal "DS" cart on a DSi system.

None of the comments made in that section really relate to my situation as far as I am aware.

 

[Pk11]

You may need to send a dummy command after Slot-1 reset, I know it's needed for retail carts not sure if it'd 100% be required with this

cardParamCommand (CARD_CMD_DUMMY, 0, CARD_ACTIVATE | CARD_nRESET | CARD_CLK_SLOW | CARD_BLK_SIZE(1) | CARD_DELAY1(0x1FFF) | CARD_DELAY2(0x3F), NULL, 0);

There's also usually a wait between disabling and enabling

https://github.com/DS-Homebrew/GodMode9i/blob/master/arm9/source/read_card.c#L333-L355

(Lines 347 onward aren't usually required on DSi, only original DS/Lite, however they are required for NAND carts for some reason)

Also, make sure you're in DSi mode with Slot-1 access (ie not DSiWarehax, not Slot-1 flashcard). In DS mode resetting Slot-1 is impossible and DSiWarehax have no Slot-1 access at all.

Edit: Just reread and noticed you said Lenny/Memory Pit, that simply won't work. Install Unlaunch and run it from there.

 

[xbmbmx]

You may need to send a dummy command after Slot-1 reset, I know it's needed for retail carts not sure if it'd 100% be required with this

cardParamCommand (CARD_CMD_DUMMY, 0, CARD_ACTIVATE | CARD_nRESET | CARD_CLK_SLOW | CARD_BLK_SIZE(1) | CARD_DELAY1(0x1FFF) | CARD_DELAY2(0x3F), NULL, 0);

There's also usually a wait between disabling and enabling

https://github.com/DS-Homebrew/GodMode9i/blob/master/arm9/source/read_card.c#L333-L355

(Lines 347 onward aren't usually required on DSi, only original DS/Lite, however they are required for NAND carts for some reason)

Also, make sure you're in DSi mode with Slot-1 access (ie not DSiWarehax, not Slot-1 flashcard). In DS mode resetting Slot-1 is impossible and DSiWarehax have no Slot-1 access at all.

Edit: Just reread and noticed you said Lenny/Memory Pit, that simply won't work. Install Unlaunch and run it from there.

I didn't explain it in my post indeed, but I have TwilightMenu++ on my DSi.

If I run homebrew isDsiMode() returns true so I assume that is enough?

Anyways all homebrew I run is through the latest version of TwilightMenu++, using DSiMode (enabled in per-rom settings). I didn't explain this correctly.

I'll test the Dummy bytes strategy tomorrow. Thanks for the suggestion!

 

[Pk11]

I didn't explain it in my post indeed, but I have TwilightMenu++ on my DSi.

If I run homebrew isDsiMode() returns true so I assume that is enough?

Anyways all homebrew I run is through the latest version of TwilightMenu++, using DSiMode (enabled in per-rom settings). I didn't explain this correctly.

I'll test the Dummy bytes strategy tomorrow. Thanks for the suggestion!

What exploit are you using to load TWiLight Menu++? (Memory Pit, Flipnote Lenny, Unlaunch, etc)

Only Unlaunch will work for Slot-1 access. isDSiMode() doesn't help here (beyond knowing if you should do the DS or DSi reset). You can check if the cart is inserted with REG_SCFG_MC != 0x11 or (REG_SCFG_MC & BIT(0)) == 0 (same check, later is more accurate but unnecessary since the 2nd DS card slot doesn't actually exist).

https://problemkaputt.de/gbatek-dsi-control-registers-scfg.htm

 

[xbmbmx]

What exploit are you using to load TWiLight Menu++? (Memory Pit, Flipnote Lenny, Unlaunch, etc)

Only Unlaunch will work for Slot-1 access. isDSiMode() doesn't help here (beyond knowing if you should do the DS or DSi reset). You can check if the cart is inserted with REG_SCFG_MC != 0x11 or (REG_SCFG_MC & BIT(0)) == 0 (same check, later is more accurate but unnecessary since the 2nd DS card slot doesn't actually exist).

https://problemkaputt.de/gbatek-dsi-control-registers-scfg.htm

I have unlaunch installed and am running TwilightMenu++ through unlaunch, I didn't mention this. Sorry for that.

I can only test the DummyByte method tomorrow so I can't comment on that yet.

 

[xbmbmx]

I'll have to take a deeper dive into GodMode9i's read_card.c code because I can't seem to get it to work.

I'm still a bit fuzzy on the cartridge protocol and the DSi's quirks (compared to the DS).

 

[xbmbmx]

Very old thread, but I want to share that I have found my mistake and have been able to solve it. In one of my attempts I called

disableSlot1();
enableSlot1();
// Logic

But that still returned zero bytes so I just assumed there was more to it. Now reading through GodMode9i source again I realize that a delay is inserted between the commands, making it this:

disableSlot1();
for(int i = 0; i < 25; i++) { swiWaitForVBlank(); }
enableSlot1();
for(int i = 0; i < 15; i++) { swiWaitForVBlank(); }

// Logic

The code now works as expected, and in combination with the suggested detection code above here, I can also anticipate if a cart is present or not.