gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > dumpSRAM - possible solution to SC 1.7 QPC brokenness

#115845 - sinclair44 - Fri Jan 19, 2007 3:43 pm

This is my first homebrew program, dumpSRAM. It just writes the contents of the SRAM onto your libfat-supported device. Hopefully, this will help to replace the currently-broken QPC saving method on the firmware 1.7 SuperCards.

I've only tested this on my SCSD with firmware 1.63; I'll upgrade it to 1.7 later and try that too. Any card supported by libfat dated Dec. 25, 2006 should work; this may even be DLDI compatible, I'm not sure. Use at your own risk.

The method works similarly to the old QPC method. Put a blank 64k .sav file with the same name as the homebrew program. ALSO create a file dumpSRAM.ini in the root directory of your card with the path to each .sav file you want to use dumpSRAM with, e.g.

Quote:
/fungame.sav
/snes/snesEmulator.sav


Run the game, save to SRAM, whatever as usual. Then, to save to the card, QPC, but instead of going to the saver menu, run dumpSRAM instead. Use L and R to select the proper .sav file from the list in dumpSRAM.ini and then press START to dump it to the card. When it says "Done!" the save is complete.

-- Link to version 1.0 removed, see below for link to current version --

The file is in .tar.bz2 format, which is standard for Mac and UNIX. I'm on a Mac; not sure what will work on that for Windows. Sorry. Also, I deleted all the Windows-specific project files in the source code, since I cannot use them. Just run "make".

Feel free to post with any questions/comments. I'm interested to know if this helps anyone! (Feature requests are welcome too, but I probably won't do anything too difficult.)

Edit: Current version: 1.2
_________________
Inter arma enim silent leges


Last edited by sinclair44 on Sun Feb 11, 2007 2:36 am; edited 3 times in total

#115854 - josath - Fri Jan 19, 2007 6:32 pm

If you add a pause between reading SRAM and writing to cart, users of any libfat-supported device could use it for example to dump the SRAM from a commercial GBA game, via cart-swapping.

#115859 - sinclair44 - Fri Jan 19, 2007 8:24 pm

I'll look into that when I get home tonight, won't be too hard.
_________________
Inter arma enim silent leges

#115886 - dantheman - Fri Jan 19, 2007 11:16 pm

This is great news, as I too had to downgrade back to 1.63b in order to use QPC saving. I'm looking forward to using it.

#115888 - josath - Fri Jan 19, 2007 11:24 pm

does firmware 1.7 do anything useful the previous version doesn't?

#115894 - dantheman - Sat Jan 20, 2007 12:10 am

Actually, now that I think about it, not really. I think it offers greater compatibility for Yarrish activities, but aside from that, nothing that would interest us. However, many new users will upgrade as soon as they get their Supercards (like they are advised to do by many people) and will find that QPC saving doesn't work. It happened to me, which is why I had to downgrade again.

Oh, and then there's the fact that users of the Supercard Lite cannot downgrade to 1.63, so if QPC saving is broken for them, they're screwed. There are even new versions of the Supercard Lite that don't work with most homebrew using libFAT, so I don't even know if dumpSRAM will work for them. Perhaps if it was modified to use DLDI it would work better, since a new SC Lite DLDI driver was released from Moonlight that reportedly allows for full read/write access on the new devices.

#115906 - HyperHacker - Sat Jan 20, 2007 2:39 am

sinclair44 wrote:
The file is in .tar.bz2 format, which is standard for Mac and UNIX. I'm on a Mac; not sure what will work on that for Windows.

7Zip does that nicely.
_________________
I'm a PSP hacker now, but I still <3 DS.

#115935 - sinclair44 - Sat Jan 20, 2007 1:50 pm

sinclair44 wrote:
I'll look into that when I get home tonight, won't be too hard.


Bah, was having problems logging in, etc... I'll get to it tonight, I promise. If you want to modify it yourself, just add a while loop waiting on the keypress like the one waiting for START to be pressed, calling PA's vblank inside.

dantheman wrote:
Perhaps if it was modified to use DLDI it would work better, since a new SC Lite DLDI driver was released from Moonlight that reportedly allows for full read/write access on the new devices.


As I'm using a recent libfat, I think it automagically supports DLDI; the 1.21 patcher seemed to work properly on the .nds version (didn't like the .sc.nds version):

Quote:
./dlditool scsd.dldi dumpSRAM.nds
Dynamically Linked Disk Interface patch tool v1.21 by Michael Chisholm (Chishm)

Old driver: #
New driver: SuperCard (SD Card)

Position in file: 0xFFFFFFFF
Position in memory: 0x01CC0000
Patch base address: 0xBF800000
Relocation offset: 0x424C0000

Patched successfully


Does that mean I support DLDI... could someone with a broken device test please?

HyperHacker wrote:
7Zip does that nicely.


Good to know, thanks!
_________________
Inter arma enim silent leges

#116014 - sinclair44 - Sun Jan 21, 2007 3:50 am

Edit: link to version 1.1 removed; see first post for current version

Hold SELECT before you press START and it will pause each step of the way. This might be useful, as josath suggested, for dumping the SRAM of an official GBA cart by swapping it in and out with your flashcart/SuperCard. I've not tried that, it could seriously hurt stuff, I don't even know how libfat will handle having its filesystem pulled out from under it and then put back. Good luck, try at your own risk. :)

No other major changes in this release.
_________________
Inter arma enim silent leges


Last edited by sinclair44 on Sun Feb 11, 2007 2:37 am; edited 2 times in total

#116031 - dantheman - Sun Jan 21, 2007 6:17 am

Just for kicks, I tried it on Metroid Fusion. It's a game that uses SRAM, and I've already got the save file backed up to my PC via FlashManager, so I thought that if it didn't work I could always replace the savefile.

I created an asdf.sav file on the root of my card and edited the .ini file accordingly before starting dumpSRAM. I pressed R to get to asdf.sav, then held Select before pressing Start. I ejected the Supercard, popped in Metroid Fusion, pressed Start again so it read the SRAM, ejected Metroid Fusion, put in the Supercard, and... the DS rebooted due to FlashMe. =/

I don't know if all cards do this, but for right now using a slot-2 Supercard on a flashed DS will not let you backup GBA saves from official carts.

Hopefully an unflashed DS will not have this issue. On a positive note, the program works fine for me when testing with SnezziDS.

EDIT: forgot to mention that the Metroid Fusion save is fine. Nothing happened to it.

#116053 - sinclair44 - Sun Jan 21, 2007 1:26 pm

dantheman wrote:
put in the Supercard, and... the DS rebooted due to FlashMe. =/

I don't know if all cards do this, but for right now using a slot-2 Supercard on a flashed DS will not let you backup GBA saves from official carts.

Hopefully an unflashed DS will not have this issue. On a positive note, the program works fine for me when testing with SnezziDS.

EDIT: forgot to mention that the Metroid Fusion save is fine. Nothing happened to it.


Interesting. Did it reboot the second you put the new card in, or after you pressed START to continue? I wasn't aware of FlashMe or SuperCards having such a functionality, and there certainly isn't anything to do that in dumpSRAM (well, at least not intentionally).

I'm glad though that it's working for you for snezziDS. That being broken for firmware 1.7 is actually what gave me the initial incentive to write this.

Thanks for being a guinea pig :)
_________________
Inter arma enim silent leges

#116075 - dantheman - Sun Jan 21, 2007 6:58 pm

No, it's FlashMe itself, not your program. Whenever I take out my Supercard and re-insert it, the DS reboots immediately. I first discovered this when using HyperHacker's program, the one that adds a border around the screen before starting GBA mode. Since it apparently wouldn't boot the Supercard in GBA mode, I thought it might work if I ejected and re-inserted it, which caused it to reboot.

I completely forgot about it until I was in the middle of testing dumpSRAM, by which point I decided to try it anyway just in case.

#116098 - HyperHacker - Sun Jan 21, 2007 11:15 pm

Hm, this doesn't happen with my GBAMP. With my program did you select Unmount Memory Card first? Or does it even worth with Supercard? I know it's pretty old and could stand to be updated, but silly me didn't think to keep the original source around before adding a bunch of things to it that aren't yet finished, so it will take some time.

[edit] Kind of a waste of post 1337 :(
_________________
I'm a PSP hacker now, but I still <3 DS.

#116101 - Firon - Sun Jan 21, 2007 11:27 pm

I've never had that happen with my M3. I've accidentally removed and re-inserted the cart several times while using Moonshell and it's never rebooted (in fact, Moonshell doesn't even hang until you try to open a file or change folders). My Lite is FlashMe'd.

#116103 - tepples - Sun Jan 21, 2007 11:56 pm

The difference might have something to do with how the DS firmware, the SuperCard menu, and the program itself set up the Game Pak IRQ.
_________________
Driven from Tilwick by ice storms, couldn't fit in in Flower Bud...

Nintendo DS: With two ARMs, who needs legs?

#116109 - dantheman - Mon Jan 22, 2007 12:43 am

HyperHacker, I don't even see an "Unmount Memory Card" option at all. There's only start game, re-read cartridge, border, swap screens, backlight, sound amp, return to menu, and shut down.

I don't think it has to do with the pack being unmounted though. I pulled the Supercard out when the DS was off, started the Opera browser, and pushed the SC back in, prompting the reboot again. Same thing happens in any of the DS's built-in functions like Pictochat.

I think it's like Tepples said, a combination of several things interacting in certain ways.

#116119 - HyperHacker - Mon Jan 22, 2007 2:27 am

Ah yes, IIRC that option disappears when the card isn't mounted. That's certainly interesting though.
_________________
I'm a PSP hacker now, but I still <3 DS.

#116149 - SukkoPera - Mon Jan 22, 2007 4:28 pm

I've tested the eject/reinsert thing while running dumpSRAM, Moonshell, ReinMoon and my own MCTool, and the result was always the same: DS resetting when my SCL is pushed back in.

Actually, the same things even happens at the SC menu...

I've also tried bypassing FlashMe's autoboot SC feature holding select while powering up the DS: no change.

What about the opposite function: writing a file back to the cart's SRAM? That won't require the reinsertion of the SC, so it should work, if it's feasible.

Oh, and one more silly idea: what about copying the slot-2 SRAM to the slot-1 SRAM, using Rein's sources? Then, after rebooting we could use Rein to dump the slot-1 SRAM to file. Of course that would corrupt previous data in the slot-1 SRAM, but it can be easily backed up with Rein, too.

And what about launching dumpSRAM from a slot-1 flashcart?
_________________
Nintendo DS Lite (White) + Supercard Lite + R4 + Sandisk 1 GB MicroSD
Sony PSP + Firmware 3.03 OE-A2

#116172 - sinclair44 - Mon Jan 22, 2007 10:08 pm

SukkoPera wrote:
What about the opposite function: writing a file back to the cart's SRAM? That won't require the reinsertion of the SC, so it should work, if it's feasible.

Oh, and one more silly idea: what about copying the slot-2 SRAM to the slot-1 SRAM, using Rein's sources? Then, after rebooting we could use Rein to dump the slot-1 SRAM to file. Of course that would corrupt previous data in the slot-1 SRAM, but it can be easily backed up with Rein, too.

And what about launching dumpSRAM from a slot-1 flashcart?


Anything extra to do with Slot-1 is out of the question. I think libfat already supports it, so it will probably already read the SRAM out of Slot-2 and write it to a Slot-1 card, but anything other than that is way out of my area of expertise right now.

As for writing back to SRAM: that isn't hard, just a matter of changing around a handful of stuff. I think, at least - never actually tried. I may give it a look when I get some free time, but that could be a while. You're welcome to make the changes yourself (or make a start on them) and PM them to me; the source is included in the download.

That goes for any change - feel free to make it yourself. I'd appreciate it if you wouldn't start releasing your own versions though, to reduce users' confusion; please PM the changes to me or post the source in this thread.
_________________
Inter arma enim silent leges

#116208 - HyperHacker - Tue Jan 23, 2007 4:44 am

If you have a GBA Gameshark, you might try plugging your SC into that (with the code switch off so it doesn't break anything) and see if it reboots when removing it from the GS.
_________________
I'm a PSP hacker now, but I still <3 DS.

#116740 - sinclair44 - Mon Jan 29, 2007 1:09 am

I've refactored the code a lot (i.e. split stuff into functions with arguments, return values, and local variables instead of one monolithic main() and global variables). This will make it much easier to implement a load function as well as the current save function.

This still may take some time (very much dependent on my schoolwork and mood), but keep your eyes open.
_________________
Inter arma enim silent leges

#117168 - mr_jrt - Fri Feb 02, 2007 1:18 am

I just tried your utility with my v1 DS with the latest flashme, a SCSD, and KuruKuru Kururin (save data I'm not fussed to lose :P), and Metroid Fusion ( so I can see if its different between carts)

Removing the packs was no problem at all - I've never has a single reboot due to cart removal, maybe I'm just lucky I guess. Anyway, I'm not getting valid data back. I get the same data each time (both both games), suggesting that it is writing ok (the files were zeroed out beforehand), but probably just random data. I can supply the .sav if it'd help.

#118020 - Tomy Sakazaki - Fri Feb 09, 2007 3:43 am

I tried the utility, only the dumpsram.sc.nds was patcheable by DLDI patcher for SuperCard Lite, but before the patching, it doesn't recognize any compatible signature on it. But this one freezes on my DS.
But the only version that runs on my DS + SC Lite is the dumpsram.nds, and it seems that the dumpsram was unable to read my dumpsram.ini
Also I couldn't find the patching options in supercard patcher to enable the save in SRAM for Final Fantasy VI without marking it to restart and it is the point that makes all the slowdowns.
What are the correct options into supercard patcher2.58?


Quote:

/gba/ffvi.sav
/gba/sbattle.sav
/gba/rtengoku.sav

#118030 - Doom5 - Fri Feb 09, 2007 5:36 am

Dumpsram is not DLDI compatible unless you recompile it with a newer version of devkitARM.

#118101 - Tomy Sakazaki - Sat Feb 10, 2007 4:44 am

Well, waiting for a version compatible with supercard lite.
The idea is great! Hope that it will get updated soon.

#118102 - sinclair44 - Sat Feb 10, 2007 5:08 am

Writing back to SRAM is still not complete (have been busy with other stuff... haven't even started on it). I'll try and get devkitARM r20 up tomorrow and recompile a new version; hopefully that will enable DLDI properly.
_________________
Inter arma enim silent leges

#118106 - dantheman - Sat Feb 10, 2007 5:46 am

Just a quick update: I managed to reinsert the Supercard without rebooting by pressing the right side in first (probably not good for the contacts) and going really slowly. It wrote the save file and all, but like mr_jrt I found that the output file is not valid. Ah well, it was worth a shot.

#118218 - sinclair44 - Sun Feb 11, 2007 2:40 am

Version 1.2 is available

No major changes since last version. The source has been greatly cleaned up, but that has nothing to do with the actual functionality. It was recompiled with the new PAlib and devkitARM r20, so hopefully it will be DLDI compatible now.

This version has not received extensive testing. (Not that any of them have, but all I did for 1.2 testing was: I recompiled, did a dump, and checked the md5 against the known-good dump.)

Enjoy.
_________________
Inter arma enim silent leges

#118243 - Doom5 - Sun Feb 11, 2007 2:06 pm

Keep up the good work! :)

#118248 - Tomy Sakazaki - Sun Feb 11, 2007 3:00 pm

Tried with 1.2 onto a SuperCard Lite.
This time it shows the ini perfectly.
Quote:
/gs2.sav


But anyway, I couldn't use QPC, since apparently there's no way to save something to SC Lite SRAM without activating the "enable restart" in the patcher, and it's the source of slowdowns with gba games in supercards.
:(
Tried with Enable Save and Enable Saver Patch, but no success to send the save to SRAM of supercard lite.
EDIT: Tricked by not seeing something like GYAK2 (in card)! It seems to work! I'll try with Final Fantasy VI and report later.
EDIT2: Tested with FF VI too, it works, however the game seems to be a bit slower on SuperCard, the intro has a little desync.

In order to use I've patched dumpSRAM.sc.nds with the DLDI patcher for SuperCard Lite.

Thanks sinclair44, it is a great application :D

#118254 - Doom5 - Sun Feb 11, 2007 4:32 pm

Tomy: So is it possible to do QPC without the "Enable Restart" patch?

#118259 - sinclair44 - Sun Feb 11, 2007 5:40 pm

Doom5 wrote:
Tomy: So is it possible to do QPC without the "Enable Restart" patch?


It should be. Just don't patch at all and it will save to SRAM by default. QPC and use dumpSRAM to write that to the card. I've not tried this though, I've only tried with NDS games.
_________________
Inter arma enim silent leges

#118269 - MasterMan - Sun Feb 11, 2007 7:32 pm

Flashed DS phat, SCCF 1.7 FW, 1GB Sandisk CF.
Patched 2689 - Final Fantasy Advance VI (US).gba with "Enable saver patch" only and moved it in CF's root. Alongside the 2689 - Final Fantasy Advance VI (US).sav i have using in Visualboy Advance (saved in South Figaro).
Copyed %ProgramFiles%\SC\save.sav to \dumpSRAM.sav. Wrote \dumpSRAM.ini with /2689 - Final Fantasy Advance VI (US).sav and put \dumpSRAM.sc.nds in card, everything on the root.

In game, i go to a save point and save the game normaly. Then i turn the DS off and on realy fast. Boot dumpSRAM.sc.nds, the lower screen shows "/2689 - Final Fantasy Advance VI (US).sav", i press START, it says done.

When i try to resume playing, my save is lost, there's only "new game" option.
DumpSRAM corrupts my save :(

Code:
>fc /b J:\2689 - Final Fantasy VI Advance (US).sav e E:\EMULADORES\GBA\SAV\2689 - FINAL FANTASY VI ADVANCE (US).SAV
00000002: AA 33
00000003: 55 3E
00000004: 00 4B
00000005: 00 4B
00000006: 00 3A
...
all the way down
...
00002FFE: 00 6C

#118275 - tepples - Sun Feb 11, 2007 8:05 pm

MasterMan wrote:
Flashed DS phat, SCCF 1.7 FW, 1GB Sandisk CF.
Patched 2689 - Final Fantasy Advance VI (US).gba with "Enable saver patch" only and moved it in CF's root.

Why would you put a commercial .gba program on a SuperCard?

pie rut?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#118281 - sinclair44 - Sun Feb 11, 2007 8:37 pm

MasterMan wrote:
...with "Enable saver patch" only...


Try it without the saver patch. dumpSRAM basically replaces that functionality anyways. I'm not sure how it works; if the SC firmware holds the SRAM in memory before writing it to the card, then dumpSRAM will read the SRAM (which would be junk) and write that.
_________________
Inter arma enim silent leges

#118288 - MasterMan - Sun Feb 11, 2007 10:11 pm

sinclair44 wrote:
MasterMan wrote:
...with "Enable saver patch" only...


Try it without the saver patch. dumpSRAM basically replaces that functionality anyways. I'm not sure how it works; if the SC firmware holds the SRAM in memory before writing it to the card, then dumpSRAM will read the SRAM (which would be junk) and write that.

Tried again with no options checked in patcher, still no luck.

Thanks for your effort anyways.

#118323 - Tomy Sakazaki - Mon Feb 12, 2007 3:50 am

Doom5 wrote:
Tomy: So is it possible to do QPC without the "Enable Restart" patch?

The idea in doing QPC is to avoid the "Enable Restart" patch. But lazy guys that run games without slowdowns with that option turned on use the"enable restart" to make fakes QPCs.

#118508 - MasterMan - Wed Feb 14, 2007 12:36 am

Any news?

#118510 - sinclair44 - Wed Feb 14, 2007 12:47 am

MasterMan wrote:
Any news?


I've got no clue why it isn't working; it should. But dumpSRAM was built for an intended for usage for NDS games that save to the SRAM, not GBA games. It seems to work for that purpose, and since you can use the SuperCard patcher anyways, I'm not too worried about it.

Feel free to investigate yourself (or anyone, feel free) and send me info that I can work from, or ever better, a patch.
_________________
Inter arma enim silent leges

#118523 - Tomy Sakazaki - Wed Feb 14, 2007 2:05 am

What NDS games or homebrews needs a QPC to save the content of SRAM?
I thought that dumpSRAM was created to use with GBA games. And try to run Final Fantasy VI or V with the patching needed to save them using L+R+A+Select in firmware 1.7 on (enable restart, enable save, enable saver patch) and without (possible with dumpSRAM), you will see that dumpSRAM will be most used to GBA games.

#118526 - Doom5 - Wed Feb 14, 2007 2:30 am

Tepples doesn't like any posts that discuss... you know...

#118534 - dantheman - Wed Feb 14, 2007 2:57 am

SnezziDS saves to SRAM, so QPC saving is necessary. I've seen several people attest that DumpSRAM works on GBA stuff too, so I'm not sure what the issue is.

#118542 - tepples - Wed Feb 14, 2007 4:42 am

But is there any Super NES homebrew that needs to save?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#118548 - dantheman - Wed Feb 14, 2007 5:09 am

Probably not. Even still, the utility can still be used for non-yarrish activities, since it theoretically should work with GBA saves as well. GBA homebrew uses the SRAM extensively, right?

#118594 - sinclair44 - Wed Feb 14, 2007 2:00 pm

dantheman wrote:
Probably not. Even still, the utility can still be used for non-yarrish activities, since it theoretically should work with GBA saves as well. GBA homebrew uses the SRAM extensively, right?


Actually, the catylist for me to write dumpSRAM was Whee DS, which can only save to SRAM.

But yes, GBA homebrew uses SRAM as its only method of saving. I've not tried it, but there's no reason it shouldn't work.
_________________
Inter arma enim silent leges

#118633 - dantheman - Thu Feb 15, 2007 12:49 am

I've heard from one user on SCdev that QPC saving actually works on affected Supercards with 1.7 when rebooting into GBA mode to use the Saver tab, not DS mode. Obviously, this wouldn't help the Rumble series, but it's an interesting idea nonetheless. Anyone care to test it and see if this is accurate?

#118693 - MasterMan - Thu Feb 15, 2007 4:41 pm

dantheman wrote:
I've heard from one user on SCdev that QPC saving actually works on affected Supercards with 1.7 when rebooting into GBA mode to use the Saver tab, not DS mode. Obviously, this wouldn't help the Rumble series, but it's an interesting idea nonetheless. Anyone care to test it and see if this is accurate?

Hell yeah, it works.
Note anything shows "in cart", but go to saver tab and save it anyways. Only when booting in GBA mode.

#118718 - Tomy Sakazaki - Fri Feb 16, 2007 2:12 am

Nobody tried using the gba mode to save the SRAM contents or who tried it before doesn't spread the word?
Will it work with Whee DS and other DS homebrews that use SRAM?
To GBA programs, not only yarrish activities, it works flawless.

#118833 - dantheman - Sat Feb 17, 2007 6:06 am

This is rather off-topic, but I found out something interesting. Back on the front page, I mentioned that I first discovered the whole "Supercard resets DS upon reinsertion" thing when testing Hyperhacker's program to launch the GBA cartridge with a border. I stated that since when launching the Supercard itself from his program, the Nintendo logo was corrupted, I thought that ejecting and re-inserting the Supercard might make it work.

Like I stated before, it's possible to re-insert the Supercard if you push the right side in first and go slowly. I just now tested this method with his program and found to my amazement that I was right. Nothing I do after first launching his program will work, but after I eject and re-insert the Supercard, it launches fine. How interesting.

But back on-topic, it's good to hear that QPC saving does actually work in 1.7 through GBA mode. Granted, SC Rumble users are still out of luck, but it's at least a step in the right direction.

#118834 - tepples - Sat Feb 17, 2007 6:12 am

Does the reset upon insertion still happen if you disable the Game Pak IRQ?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#118910 - HyperHacker - Sun Feb 18, 2007 5:22 am

Gameshark Advance has a similar problem, which was actually the inspiration to make that program. It seems the DS firmware does some dummy reads from the GBA slot, which triggers the GSA to switch from pass-through mode (in which cartridge ROM is readable) to normal mode (in which GSA ROM is readable), and since the GSA ROM has no logo, it won't launch. I figured I'd write a program specifically to launch the GSA by switching it back into pass-through mode, but I later realized you could simply pull it out and back in. The firmware will freeze when you do this (remove or insert anything in either slot), but homebrew doesn't seem to; I suspect they implemented this on purpose.

I'd guess the Supercard does something similar when launching an NDS app, so trying to boot it in GBA mode from there does no good. Reinserting it resets the card. My program doesn't use the Game Pak IRQ, so tepples may be on to something there.
_________________
I'm a PSP hacker now, but I still <3 DS.