Maybe when the work in progress is no longer A work in progress but completed
Also Post #4000 in this topic
Ah, but Emunand9, Godmode9, FBI, et al, keep getting updates, therefore everything is WIP. And if everything is WIP, then nothing is WIP.
Ah, but Emunand9, Godmode9, FBI, et al, keep getting updates, therefore everything is WIP. And if everything is WIP, then nothing is WIP.
Decrypt9 WIP (work-in-progress) by d0k3Ah, but Emunand9, Godmode9, FBI, et al, keep getting updates, therefore everything is WIP. And if everything is WIP, then nothing is WIP.
This is a work in progress fork of Archshifts original Decrypt9, including bleeding edge new features. Note that the names of the exectuable files for this are Decrypt9WIP.* instead of Decrypt9.*. New features introduced in this will eventually get pulled into Archshifts repo.
You may discuss this work in progress version, help testing, participate in the development and on GBAtemp.
Decrypt9, Decrypt9WIP, Decrypt9UI - which one to use?
There are at the present time, three main versions of Decrypt9 available:
- Decrypt9 by Archshift: This is the original version of Decrypt9 by Archshift. New features are pulled into this once they are thoroughly tested. This is as stable as it gets, but may also miss some of the newer features.
- Decrypt9 WIP by d0k3: This is the work in progress fork of Archshifts original Decrypt9. It contains the newest features and is always up to date. Releases in here can be considered tested beta versions.
- Decrypt9 UI by Shadowtrance: This is a themed version of Decrypt9 WIP created by Shadowtrance. It contains a nice graphical user interface (instead of text only as the other two versions), but may not be up to date at all times
That why this one is WIP
Funny... Somehow my working "folder" is set up as the root for Decrypt9. I have no folders. It even says "Working directory: /" so I don't think that's it.I think maybe it should be in d9game, or decrypt9 folder since those are the two primary folders the program uses.
--------------------- MERGED ---------------------------
Yeah i was right, i dumped the Save data from nand, it was found in decrypt9 folder. so it belongs in there.
Then do what i did. Dump a save from decrypt9 and find the directory it is in. Then that is the one you use.
I was right. It dumps to the root directory. Therefore, I must be doing something else wrong, as I was putting the save inject in the root as well.Then do what i did. Dump a save from decrypt9 and find the directory it is in. Then that is the one you use.
I think the name should be *gbavcsave*.bin. If you are unsure, just dump the savegame and take note of it's name and location.
I think maybe it should be in d9game, or decrypt9 folder since those are the two primary folders the program uses.
--------------------- MERGED ---------------------------
Yeah i was right, i dumped the Save data from nand, it was found in decrypt9 folder. so it belongs in there.
/files9 is the recommended work folder now, and most stuff works without a work folder, too.
thank you. just want have a try.
--------------------- MERGED ---------------------------
hi @d0k3 I force restore the nand from the brick n3ds to the work n3ds's emunand but I find I can not dump the file you mentioned. d9 just say conld't find it the system infor file on the emunand. I want to fix the ctr part of my brick n3ds then inject the nand back to the bricked n3ds. Or do i have any other chance to save my bricked n3ds?thank you for you help
Last edited by fateg,
@d0k3
I have a feature to request. How technically possible it is, is something that I don't know.
Something the scene keeps discussing every now and then, is bad tickets. Recent topic here:
http://gbatemp.net/threads/ctrnand-...db-etc-it-can-remove-your-bad-tickets.439802/
Is it possible to implement a simple way into D9 (or GM9?) to clean out the bad tickets from ticket.db
The thread above explains how it's currently possible using the ctrnand transfer, and why this method is better than FBI's method.
FYI, I have been hearing conflicting reports about FBI. People say FBI marks them for deletion and they are deleted from the db on the next installation of whatever, and people like in the thread above say it just disables them.
Anyway, it would be great if a better solution can be implemented for this
I have a feature to request. How technically possible it is, is something that I don't know.
Something the scene keeps discussing every now and then, is bad tickets. Recent topic here:
http://gbatemp.net/threads/ctrnand-...db-etc-it-can-remove-your-bad-tickets.439802/
Is it possible to implement a simple way into D9 (or GM9?) to clean out the bad tickets from ticket.db
The thread above explains how it's currently possible using the ctrnand transfer, and why this method is better than FBI's method.
FYI, I have been hearing conflicting reports about FBI. People say FBI marks them for deletion and they are deleted from the db on the next installation of whatever, and people like in the thread above say it just disables them.
Anyway, it would be great if a better solution can be implemented for this
I think there's some sort of misunderstanding with that issue regarding GBA VC EEPROM saves.
Yes, it is true that some games with EEPROM save type won't be able to save properly unless patched to SRAM.
But it's not true that AGB_FIRM doesn't support EEPROM at all.
Two of the official Ambassador GBA VC have that save type and their roms aren't patched.
And I can name couple more games that can save without any patches.
The problem is: Decrypt9 can't properly dump nor inject saves of those working games with EEPROM save type.
I really would like to see support for EEPROM saves in Decrypt9.
Sure, I can still dump them with Agbsave9, but its method for injecting saves is not so convenient.
Also, it's always better to have one tool for everything, than a bunch of individual apps for every task.
Yes, it is true that some games with EEPROM save type won't be able to save properly unless patched to SRAM.
But it's not true that AGB_FIRM doesn't support EEPROM at all.
Two of the official Ambassador GBA VC have that save type and their roms aren't patched.
And I can name couple more games that can save without any patches.
The problem is: Decrypt9 can't properly dump nor inject saves of those working games with EEPROM save type.
This is a save of Zelda: A Link to The Past dumped with Decrypt9
And here is the same save dumped with Agbsave9. That one is proper dump and it works with any emulator.
And here is the same save dumped with Agbsave9. That one is proper dump and it works with any emulator.
Sure, I can still dump them with Agbsave9, but its method for injecting saves is not so convenient.
Also, it's always better to have one tool for everything, than a bunch of individual apps for every task.
The agbsave9 dump is 64-bit byteswapped. (Notice how every block of 8 bytes is backwards in the agbsave9 dump compared to the Decrypt9 dump.)And here is the same save dumped with Agbsave9. That one is proper dump and it works with any emulator.
I find it interesting that the "correct" version is byteswapped while the version Decrypt9 is dumping isn't.
Don't know if this would be close to what you was talking about but here's this
https://gbatemp.net/threads/release-tiksweep-remove-unused-tickets.437438/
It removes unused tickets. As for bad tickets I assume something would have to be programmed to leave games alone that are cart dumps.
That's just an educated guess though.
That just deletes unused tickets (bad or legit) .. Doesn't delete anything from the db.. You can see my post about it in the second page lol
Yeah. But again, if something was programmed it would have to ignore any games that are made from cart dumps unless you plan to replace them with good tickets.
Hmm, can it be possible that AGB_FIRM handles EEPROM saves in different way than emulators (and maybe even real GBA)?
Previous versions of Agbsave9 did dump those saves in exact same way as Decrypt9 does it now (non-byteswapped).
I can be wrong, but I think that Agbsave9 just performs byteswapping when it dumps/inject saves,
for the sake of compatibility with emulators and GBA flashcards, for transferring saves between them and VC injects.
If that's true, maybe it can be implemented in Decrypt9 too?
Soooo, before going to A9LH I dumped my GBA VC Save from 9.0 Sysnand. I did A9LH, injected my Emunand into Sysnand, and now when I try to inject GBA VC data, it says AGBSAVE is corrupted or empty.
Any ideas?
--------------------- MERGED ---------------------------
Also, on a second note,
I can't start Decrypt9WIP with Homebrew Launcher anymore. Worked on 9.0, doesn't work on 11.0 A9LH. Just shows two red screens, then returns to HBL menu. Other homebrew works. I can only start it with a A9LH payload.
--------------------- MERGED ---------------------------
Also, on a second note,
I can't start Decrypt9WIP with Homebrew Launcher anymore. Worked on 9.0, doesn't work on 11.0 A9LH. Just shows two red screens, then returns to HBL menu. Other homebrew works. I can only start it with a A9LH payload.
Any ideas?
--------------------- MERGED ---------------------------
Also, on a second note,
I can't start Decrypt9WIP with Homebrew Launcher anymore. Worked on 9.0, doesn't work on 11.0 A9LH. Just shows two red screens, then returns to HBL menu. Other homebrew works. I can only start it with a A9LH payload.
--------------------- MERGED ---------------------------
Also, on a second note,
I can't start Decrypt9WIP with Homebrew Launcher anymore. Worked on 9.0, doesn't work on 11.0 A9LH. Just shows two red screens, then returns to HBL menu. Other homebrew works. I can only start it with a A9LH payload.
try playing a gba game first, then inject.
this is normal. it can only be run from hbmenu on 9.2 or lower.
I think only applies to emulator saves. Most Actual cart dump saves maybe don't need it. But i think is mostly trimming to fit appropriate file size. Other than that, dump game cart save, then change to GBAVCSAVE.BIN And inject
But I only want to inject 1 save, and i have multiple gba games on my 3ds.I think only applies to emulator saves. Most Actual cart dump saves maybe don't need it. But i think is mostly trimming to fit appropriate file size. Other than that, dump game cart save, then change to GBAVCSAVE.BIN And inject
If i renamed it and inject my save, wont that erase the others?
Similar threads
Help Roms To Heal 
