Hacking [Q]Super Trim VC roms

[Mikecrowfone]

Using the current Card2romtrimtool, the lower limit file size after trimming is 64mb which is huge considering that the actual GBC/NES rom is only 2-5mb in size.

Apparently these Card2 VC roms can be super trimmed into a much smaller size ~7-15mb but it involves doing this

"modify the header to point to the new blank space"

Can anyone explain how we can do this i.e. modify the header allow for smaller trimmed VC roms?

 

[The Real Jdbye]

I am assuming it means the save file location, you can use a hex editor to do that. The address to edit is shown in the header info in 3dsexplorer I believe. I can't remember what exactly that part of the header is called on 3dsexplorer and I'm on my phone so I can't check now, but I've done it before.

 

[Mikecrowfone]

I am assuming it means the save file location, you can use a hex editor to do that. The address to edit is shown in the header info in 3dsexplorer I believe. I can't remember what exactly that part of the header is called on 3dsexplorer and I'm on my phone so I can't check now, but I've done it before.

So using 3dsexplorer you can determine the address to edit. Then you open the .3ds VC rom using a hex editor and edit it? Finally you trim it?

 

[The Real Jdbye]

So using 3dsexplorer you can determine the address to edit. Then you open the .3ds VC rom using a hex editor and edit it? Finally you trim it?

Look at Writable Address [media units] in the list in 3DSExplorer, that's the pointer to the NAND save. It seems to always be at 0x200 in the ROM. This info is no longer shown in 3DSExplorer 1.5.3.1 so you have to use 1.5.3.0 or older for that part.

You can super trim the ROM first, add blank space equal to the size of the save to the end of the ROM (you'll have to know this beforehand, can be checked by saving first and then looking at the save area in a hex editor, or to be safe just add a few MBs), and point that address there. The address is in media units which is in blocks of 0x200, so setting that to 0x1374 for example would point the save file location to 0x26E800.
If you already have a save, you can also copy that before super trimming and paste it into the new blank area (or simply paste it at the end of the ROM and point the Writable Address there, that might be easier)

No guarantees on whether it will work but it should.

 

[Mikecrowfone]

Look at Writable Address [media units] in the list in 3DSExplorer, that's the pointer to the NAND save. It seems to always be at 0x200 in the ROM. This info is no longer shown in 3DSExplorer 1.5.3.1 so you have to use 1.5.3.0 or older for that part.

You can super trim the ROM first, add blank space equal to the size of the save to the end of the ROM (you'll have to know this beforehand, can be checked by saving first and then looking at the save area in a hex editor, or to be safe just add a few MBs), and point that address there. The address is in media units which is in blocks of 0x200, so setting that to 0x1374 for example would point the save file location to 0x26E800.
If you already have a save, you can also copy that before super trimming and paste it into the new blank area (or simply paste it at the end of the ROM and point the Writable Address there, that might be easier)

No guarantees on whether it will work but it should.

How do you add blank space to the end of the rom? With my current level of understanding, it appears that I need to add a bunch of 0s but how many zeroes correspond to a mb?

 

[The Real Jdbye]

How do you add blank space to the end of the rom? With my current level of understanding, it appears that I need to add a bunch of 0s but how many zeroes correspond to a mb?

1048576 bytes in a MB
Adding the right amount of blank space may not be straightforward in your hex editor, you may need to copy and paste the 00s over and over if there's no function for inserting 00/FFs.

 

[Mikecrowfone]

1048576 bytes in a MB
Adding the right amount of blank space may not be straightforward in your hex editor, you may need to copy and paste the 00s over and over if there's no function for inserting 00/FFs.

Is that the correct address? I'm using BBB's Pokemon Silver as an example.

Also, my hexeditor has the following function.

Is the above correct for inserting blank space?

All that's left is that I do not know where to find and how to edit the pointer. I also do not know where the save is located.

 

[The Real Jdbye]

Is that the correct address? I'm using BBB's Pokemon Silver as an example.

Also, my hexeditor has the following function.

Is the above correct for inserting blank space?

All that's left is that I do not know where to find and how to edit the pointer. I also do not know where the save is located.

That's the current pointer, in media units (of 0x200 each), so the actual address of the NAND save is 0x2578 * 0x200 = 0x4AF000.
The pointer itself is located at 0x200 as mentioned by 3DSExplorer.
That function can do what you need.

 

[Mikecrowfone]

That's the current pointer, in media units (of 0x200 each), so the actual address of the NAND save is 0x2578 * 0x200 = 0x4AF000.
The pointer itself is located at 0x200 as mentioned by 3DSExplorer.
That function can do what you need.

Ok, so I have found the save location. Where does the save end?

 

[The Real Jdbye]

Ok, so I have found the save location. Where does the save end?

Look for where the save data ends and the 00 data starts. But generally speaking 2 MB should be enough for a NAND save.

 

[idunoe]

Ok, so I have found the save location. Where does the save end?

why don't you check the decrypted exheader to find the save size?

 

[Mikecrowfone]

Look for where the save data ends and the 00 data starts. But generally speaking 2 MB should be enough for a NAND save.

So the save ends here?

So 0x200 is the pointer. The value of the offset is 78 25 etc etc. How does this translate to the save location? How would I define the new save location at the new offset?

why don't you check the decrypted exheader to find the save size?

Because I am looking for the segment that is the save.

 

[idunoe]

Because I am looking for the segment that is the save.

um... card2 save offset + save size = the point where you trim the rom

 

[Mikecrowfone]

um... card2 save offset + save size = the point where you trim the rom

What happens if there is padding in between the rom and the save offset?

why don't you check the decrypted exheader to find the save size?

Also, I am hex editing the .3ds file, have not yet unpack the rom yet.

 

[idunoe]

What happens if there is padding in between the rom and the save offset?

with the exception of the first few vc roms, they all have the save offset after the last ncch file.

edit:

Spoiler: spoiler alert

they all have a save size of 1M

 

[The Real Jdbye]

So the save ends here?

So 0x200 is the pointer. The value of the offset is 78 25 etc etc. How does this translate to the save location? How would I define the new save location at the new offset?


Because I am looking for the segment that is the save.

You want to make a new save location at the end of the ROM, so for explanation's sake let's say the ROM is 10494280 bytes, just over 10 MB.
Since the save pointer is in units of 0x200 each the save location needs to be dividable by 0x200. So the save has to be placed at 0xA02200, or 10494464 bytes into the ROM, I calculated this by dividing the trimmed size by 0x200 in the Windows calculator's programmer mode (as hex) and adding 1 to that number. The resulting number is the value you need to write to the header. In this example, that value would be 0x5011, but since the byte order is reversed in the ROM, the bytes written to the header would be 11 50. Replace the two bytes at 0x200 with that value.

As the VC saves are 1 MB according to the person above me, that's how many bytes you should insert at the end (after calculating the pointer you need to insert in the header)

I don't think I can explain any better than this.

 

[Mikecrowfone]

You want to make a new save location at the end of the ROM, so for explanation's sake let's say the ROM is 10494280 bytes, just over 10 MB.
Since the save pointer is in units of 0x200 each the save location needs to be dividable by 0x200. So the save has to be placed at 0xA02200, or 10494464 bytes into the ROM, I calculated this by dividing the trimmed size by 0x200 in the Windows calculator's programmer mode (as hex) and adding 1 to that number. The resulting number is the value you need to write to the header. In this example, that value would be 0x5011, but since the byte order is reversed in the ROM, the bytes written to the header would be 11 50. Replace the two bytes at 0x200 with that value.

As the VC saves are 1 MB according to the person above me, that's how many bytes you should insert at the end (after calculating the pointer you need to insert in the header)

I don't think I can explain any better than this.

I almost understand everything now. Only thing that I don't understand is how did you arrive at 0xA02200 from 10494280 bytes


EDIT: Mods please delete my accidental multiposts.

 

[Mikecrowfone]

You want to make a new save location at the end of the ROM, so for explanation's sake let's say the ROM is 10494280 bytes, just over 10 MB.
Since the save pointer is in units of 0x200 each the save location needs to be dividable by 0x200. So the save has to be placed at 0xA02200, or 10494464 bytes into the ROM, I calculated this by dividing the trimmed size by 0x200 in the Windows calculator's programmer mode (as hex) and adding 1 to that number. The resulting number is the value you need to write to the header. In this example, that value would be 0x5011, but since the byte order is reversed in the ROM, the bytes written to the header would be 11 50. Replace the two bytes at 0x200 with that value.

As the VC saves are 1 MB according to the person above me, that's how many bytes you should insert at the end (after calculating the pointer you need to insert in the header)

I don't think I can explain any better than this.

I almost understand everything now. Only thing that I don't understand is how did you arrive at 0xA02200 from 10494280 bytes

 

[Mikecrowfone]

You want to make a new save location at the end of the ROM, so for explanation's sake let's say the ROM is 10494280 bytes, just over 10 MB.
Since the save pointer is in units of 0x200 each the save location needs to be dividable by 0x200. So the save has to be placed at 0xA02200, or 10494464 bytes into the ROM, I calculated this by dividing the trimmed size by 0x200 in the Windows calculator's programmer mode (as hex) and adding 1 to that number. The resulting number is the value you need to write to the header. In this example, that value would be 0x5011, but since the byte order is reversed in the ROM, the bytes written to the header would be 11 50. Replace the two bytes at 0x200 with that value.

As the VC saves are 1 MB according to the person above me, that's how many bytes you should insert at the end (after calculating the pointer you need to insert in the header)

I don't think I can explain any better than this.

I almost understand everything now. Only thing that I don't understand is how did you arrive at 0xA02200 from 10494280 bytes

 

[Mikecrowfone]

You want to make a new save location at the end of the ROM, so for explanation's sake let's say the ROM is 10494280 bytes, just over 10 MB.
Since the save pointer is in units of 0x200 each the save location needs to be dividable by 0x200. So the save has to be placed at 0xA02200, or 10494464 bytes into the ROM, I calculated this by dividing the trimmed size by 0x200 in the Windows calculator's programmer mode (as hex) and adding 1 to that number. The resulting number is the value you need to write to the header. In this example, that value would be 0x5011, but since the byte order is reversed in the ROM, the bytes written to the header would be 11 50. Replace the two bytes at 0x200 with that value.

As the VC saves are 1 MB according to the person above me, that's how many bytes you should insert at the end (after calculating the pointer you need to insert in the header)

I don't think I can explain any better than this.

I almost understand everything now. Only thing that I don't understand is how did you arrive at 0xA02200 from 10494280 bytes

 

[Mikecrowfone]

You want to make a new save location at the end of the ROM, so for explanation's sake let's say the ROM is 10494280 bytes, just over 10 MB.
Since the save pointer is in units of 0x200 each the save location needs to be dividable by 0x200. So the save has to be placed at 0xA02200, or 10494464 bytes into the ROM, I calculated this by dividing the trimmed size by 0x200 in the Windows calculator's programmer mode (as hex) and adding 1 to that number. The resulting number is the value you need to write to the header. In this example, that value would be 0x5011, but since the byte order is reversed in the ROM, the bytes written to the header would be 11 50. Replace the two bytes at 0x200 with that value.

As the VC saves are 1 MB according to the person above me, that's how many bytes you should insert at the end (after calculating the pointer you need to insert in the header)

I don't think I can explain any better than this.

I almost understand everything now. Only thing that I don't understand is how did you arrive at 0xA02200 from 10494280 bytes

 

[Mikecrowfone]

You want to make a new save location at the end of the ROM, so for explanation's sake let's say the ROM is 10494280 bytes, just over 10 MB.
Since the save pointer is in units of 0x200 each the save location needs to be dividable by 0x200. So the save has to be placed at 0xA02200, or 10494464 bytes into the ROM, I calculated this by dividing the trimmed size by 0x200 in the Windows calculator's programmer mode (as hex) and adding 1 to that number. The resulting number is the value you need to write to the header. In this example, that value would be 0x5011, but since the byte order is reversed in the ROM, the bytes written to the header would be 11 50. Replace the two bytes at 0x200 with that value.

As the VC saves are 1 MB according to the person above me, that's how many bytes you should insert at the end (after calculating the pointer you need to insert in the header)

I don't think I can explain any better than this.

I almost understand everything now. Only thing that I don't understand is how did you arrive at 0xA02200 from 10494280 bytes

 

[Mikecrowfone]

You want to make a new save location at the end of the ROM, so for explanation's sake let's say the ROM is 10494280 bytes, just over 10 MB.
Since the save pointer is in units of 0x200 each the save location needs to be dividable by 0x200. So the save has to be placed at 0xA02200, or 10494464 bytes into the ROM, I calculated this by dividing the trimmed size by 0x200 in the Windows calculator's programmer mode (as hex) and adding 1 to that number. The resulting number is the value you need to write to the header. In this example, that value would be 0x5011, but since the byte order is reversed in the ROM, the bytes written to the header would be 11 50. Replace the two bytes at 0x200 with that value.

As the VC saves are 1 MB according to the person above me, that's how many bytes you should insert at the end (after calculating the pointer you need to insert in the header)

I don't think I can explain any better than this.

I almost understand everything now. Only thing that I don't understand is how did you arrive at 0xA02200 from 10494280 bytes

 

[kyogre123]

Wow, septuple post.

 

[Mikecrowfone]

Wow, septuple post.

Yeah, I had no idea how that happen though. Firefox froze for a moment, refreshed and I saw the multiposts.