TCCPhreak

Hi, maybe BulbapediaTalk isn't the right site for lengthy discussions. I almost forgot I had an account here. I have two cartridges that had their battery run out, replaced and RTC patched to work again. Both had contact with VBA (1.8.0 SVN926 - farming items is much easier with a memory viewer and savestates) so both had the "last saved value" somewhere in 2014. Furlock included the source so it should be possible to port it to DS flash carts. It's been some time since I compiled DS-stuff (Pokreader DS; never took the time to translate the page from german) so don't hold your breath but maybe I'll try someday. Did you manage to get berries growing in the savefile that seems to be "forever corrupted" by VBA? Does the clock in the player's room still move? Did you try "transplanting" the savefile to another cartridge? If you send my a copy, I could try sending it to one of my cartridges and see if I can find out anything. Regards, TCC

Does the ARDSi offer a possibility to run homebrew code on it? If it does, do you have any information on how to access the SD Card slot? Even if the ARDSi is only useful for injecting data into memory (also called: cheating), you could still write a program (in cheatcodes) that allows you to read from and write to the the EEPROM. If there's no connection to the PC, you'd have to copy it "by hand" from DS screen to PC HexEdit (or vice-versa). It'd be a lot of work (writing a program in cheatcodes) and a lot of work (copying 512K from screen to screen) but technically, this should work. Of course, as pokedoc's tool is homebrew, the main requirement for it is a device to run homebrew from it. A cheatcoded Hexviewer/Writer seems far beyond the scope of it. TCC

Hello, I know I'm new here and may not seem very "qualified" to join into this discussion. Still I hope that my idea sounds plausible. PokeDoc already released the source under GPLV2, marc_max forked a slot2-dldi-only-version and by browsing over this thread I also saw another patch (DSTT?).. so this already looks like an open-source-project.. So why not officially make it one? There are too many nice NDS-homebrews that were published as a simple binary long ago, compiled against long-forgotten librarys and even if the binary itself can still be found, it sometimes just won't work with lots of hardware (hardcoded to a single slot2-solution, nds.gba,...). Even Rudolph's backup tools can occasionally be hard to find. On 31st of march, this "project" was lost for a short time, too, as this site was switched to april fools. And I think that this tool is too important to be lost.. or hidden in a single forum thread. I was thinking about creating a Google Code project, replaying the previous versions from pokedoc into the svn-repository, putting marc_max's fork back in,... When I saw the code, I already felt the urge to document (doxygen) a lot of it to understand more of it but I don't want to do that only for a local copy.. or interfere with PokeDocs coding process.. or do my own fork. Issues could be reported in the project issue tracker (instead of being spread over "nineteen-and-running"-pages here), the wiki could provide more information on how the SPI-IR problem was solved and the starting page might be much easier to find... Honestly: First, I had trouble finding out that this tool even exists. Then I knew it could be found somewhere but still had trouble finding it, again.. And then I had a link from somewhere else but it was japanese april fools, so I couldn't access it either. I'd also like to suggest two changes: * I've never gotten the original pokedoc-binary to work (only the slot2-dldi-one), so maybe this has already been done: As this tool imitates rudolphs behaviour and that gui is rather nice (selecting the file to backup to or restore from), I think it might be nice to make it look similar. * I really respect the idea to have this tool as a "swiss army knife" but I see a real problem with the "auto-detection" for Slot2/3-in-1/DLDI/FTP. I guess that it fails to work on my hardware because some things are detected wrong and thus crash the program. Also, DLDI-support is wasted if you only want FTP whereas libwifi is not needed if you use slot2/dldi. So I think tha like in rudolph's tools, Slot2/FTP/whateverelse should be seperate tools, but sharing common source, being compiled from mostly the same sourcefiles (apart from the DirList, Save and Load-functions different for different architectures) and also always being distributed in the same zipfile. I've already contacted marc_max and he was okay with it. I'm still waiting for pokedoc's reply. I don't want to take anything away from them - it's still their program (and lots of thanks to pokedoc for cracking the savegame-knot), but I think that this is a tool (not only for pokemon) well worth taking more "global". What do you think? Is it a foolish idea or could it attract more developers? TCC PS: English is not my native language so excuse me if some things are "strange" PPS: Some "proof" I have done DS-coding, before: http://tccphreak.shiny-clique.net/pokreaderds/_index.htm (sorry, german page, but the tool is english) It won't work with DSi. The IR-problem kept me from implementing Johto or Unova. If OpenDSSavegameTool (or whatever name is chosen) goes online, I'd like to import the Savegame-reading from there.. - or even better: make "Pokemon Browsing" another target next do FTP and DLDI.