Correct me if I'm wrong, but how can we know who BBB or Contrast or Absktrat are? They don't even have public emails. So that theory of Gateway contacting them isn't plausible.
Correct me if I'm wrong, but how can we know who BBB or Contrast or Absktrat are? They don't even have public emails. So that theory of Gateway contacting them isn't plausible.
Does not mean BigBlueBox is someone who is fresh new on the scene for all we know it could be to do with the same ripper team as Contrast or Abstract but under a different name because they are ripping 3DSWare and also it is possibly a friend of Contrast or a close associate so he names himself BigBlueBox, mainly these rippers from each scene no each other, they all work out the same camp. They all do sometimes have there email addresses conected with there uploads somewhere down the line on some very private trusted only 100% torrent sites looking for rippers to join there camps, so company's like GW pick there email addresses from them and save them to be contacted when needed.
crazy hardware hacking! i wonder how long it took to make this one lol
to be honest, i guess if you have the 'know how', simply reading data from a chip is not that hard... but still, it's very cool
Ok bro. Nice theory. I laughed and all. But as I said before, you're just making things up. Unless you present this community some evidence of that.
crazy hardware hacking! i wonder how long it took to make this one lol
to be honest, i guess if you have the 'know how', simply reading data from a chip is not that hard... but still, it's very cool
That's what I mean I'm not trying to say they get a neat little Gateway cartridge package like we all see at home to put in the back of our 3DS's to dump a rom it would be in the very early beta stages of dumping and that picture is a perfect example, something like what you see here. I've said far to much anyway, I'm going to shut up now.
Just want to say something interesting. I trimmed the rom file to 10MB and change the save offset to 0x00600000, the game can load and save properly. I guess I could do that with CARD2 games too.
Edit: This indeed works with CARD2 games too. Tested with Pokemon X US version by changing the save offset to 0x6DAF7200 (0x200 bytes after the game data), and trimmed the rom file to 1756 MB (approximately 1754 MB game data, and 1 MB save data space after that).
Edit: This indeed works with CARD2 games too. Tested with Pokemon X US version by changing the save offset to 0x6DAF7200 (0x200 bytes after the game data), and trimmed the rom file to 1756 MB (approximately 1754 MB game data, and 1 MB save data space after that).
- Joined
- May 15, 2006
- Messages
- 878
- Trophies
- 1
- Age
- 36
- Location
- Bize Her Yer Trabzon
- Website
- www.HtheB.com
- XP
- 3,123
- Country
Hopefully we will see a flood of CIA to 3DS conversions although it may be a bit technical and scene groups typically don't release there dumping methods, so it probably only one person. If anyone has figured out or has a good idea who is behind the bigbluebox eshop conversion dumps, please don't post it anywhere. There are people complaining that devs who release some fairly technical tools relating to homebrew, are anti-piracy etc but the last controversy regarding some of the original 3ds dumps and these releases (if you figure it out, keep quiet, it has nothing to do with the prior dev related release cart dumps). If the dev possibly responsible is reading this "assuming" you used to host your work on old sites, etc make sure all of it is removed.
When I do that, the game stalls on "starting the game in progress, don't power off".
You probably did it after already creating a save game though... But the fact the 3DS tries to write on every part of the unused space when starting fresh makes me think it's not really safe to do your trick...
You probably did it after already creating a save game though... But the fact the 3DS tries to write on every part of the unused space when starting fresh makes me think it's not really safe to do your trick...
Make sure you do it right. The save offset is stored at 0x00000200, in media unit, 1 media uint = 0x200 bytes. So if you want to change the save offset to 0x00600000, it would be 0x00003000 media unit or 00 30 00 00 in hex editor view. The save data size is approximately 4 MB , so the trimmed file size should be 10 MB or bigger.
This can be done with rom that already has save data or does not have save data, it doesn't matter. If you do it right, the save data would show up at the specified offset, you can alway check that with a hex editor.
That's exactly what I did, and for some reason it tries to write at this offset fine, but also at other offsets (I can see that when untrimming the rom) since it's 128 MB (but if I try to make it 32MB, then the game can't even be mounted.
It should look something like this.
I wrote a small tool to change save offset to 0x200 after the game data and trim the rom to save offset + save data size
Usage:
Card2RomTrimTool [filename] [Optional: savedataspace in MB]
for example:
Card2RomTrimTool bbb-n-qa5p-rom.3ds 4
or
just drag the rom file onto Card2RomTrimTool.exe, it will choose 16 MB as default save data space.
Update:
Looks like the game will stuck during initializing save data the first time you run it after trimming (but the second time will load fine). Don't know what's the problem.
The tool is updated, now you need existing and valid save data to skip save initialization. You need to load the rom at least once before trimming. The tool will automatically scan for existing save data and transfer it to the new save offset before trimming.
Update2:
Fixed bug when transferring save data that are larger than 16 MB.
The updated tool and source code are included in the attachments.
Similar threads
