GCS / SAV support

[suloku]

GCS / SAV support

[GoogleCodeExporter]

I updated the the max drive save converter to v1.01. It can now convert back 
and 
forth between sav,gvs, and gci. You can download it here:
http://gbatemp.net/index.php?download=4072

It includes source code. The authors are permitted to include it under GPL. You 
can 
also use the source to figure out your problem with the patch. 

Original comment by [email protected] on 4 Jan 2009 at 11:04

[GoogleCodeExporter]

found the issue, I was using devkitppc16, and I was also using handle instead of
filename, should have a working patch soon

Original comment by [email protected] on 4 Jan 2009 at 11:38

[GoogleCodeExporter]

It should be while(i<10) - Otherwise it will swap 11 pairs. This was one of the 
changes I made to the max drive save converter 1.0.

while(i<=10)
+           {
+               u8 temp = (&FileBuffer + 0x2C + i*2);
+               memcpy((&FileBuffer + 0x2C + i*2),(&FileBuffer + 
0x2C + i*2+1), sizeof(u8));
+               memcpy((&FileBuffer + 0x2C + i*2+1),&temp,sizeof
(u8));
+               i++;
+           }

Original comment by [email protected] on 5 Jan 2009 at 2:26

[GoogleCodeExporter]

thanks, I did notice that typo :p
updated patch, selection screen now shows correct values for gcs/sav but restore
still doesnt work

Original comment by [email protected] on 5 Jan 2009 at 3:17

Attachments:

• gcs2.patch

[GoogleCodeExporter]

check your u8 and u16

Original comment by [email protected] on 5 Jan 2009 at 3:54

[GoogleCodeExporter]

that was another problem that i was still trying to figure out where i messed 
up,
thanks, even changing it to the correct | it is code elsewhere that does not 
use the
offset for gcs/sav files, and causes restore to fail

Original comment by [email protected] on 5 Jan 2009 at 4:29

[GoogleCodeExporter]

Not sure what you mean by restore. I assume you are not making a gci file first 
then 
trying to restore the converted gci file to mc. That would be easier to 
troubleshoot.

Original comment by [email protected] on 5 Jan 2009 at 11:58

[GoogleCodeExporter]

Block Offset (0036h - 
0037h)..........................................................................
.....
...0x02 Bytes
These two bytes store a 16-bit integer which specifies the block offset, from 
the 
first position on the card (0000 0000h), that this particular file begins at. 
This 
can be set to any value when backed up, as it has no significance when the file 
is 
not stored on a memory card, and the SAVER FAVORITE application (and any other, 
including the GameCube) has to alter it to reflect the current offset whenever 
it is 
uploaded, copied or moved.

Original comment by [email protected] on 5 Jan 2009 at 12:34

[GoogleCodeExporter]

The GameCube may not correctly read or store save files that are not exactly 64 
bytes plus X bytes, where X is a multiple of one block. One block usually 
equals 8K 
(8,192 bytes).

Original comment by [email protected] on 5 Jan 2009 at 12:42

[GoogleCodeExporter]

The main issue now is using the offset for gcs/sav everywhere, I believe it is
creating the header for the wrong location, I just need to find all the places 
to add
the offset

Original comment by [email protected] on 6 Jan 2009 at 1:53

[GoogleCodeExporter]

Current Patch, allows for perfect gcs import (Exported as gci and hex compared 
with
the original), sav import currently not working

Original comment by [email protected] on 6 Jan 2009 at 2:28

Attachments:

• gcs.patch

[GoogleCodeExporter]

patch with both gcs and sav working, (forgot to byteswap in both places for sav)
checks full filename (gamecode+filename), so that you can have pal + us saves 
for the
same game

Original comment by [email protected] on 6 Jan 2009 at 2:53

Attachments:

• gcs.patch

[GoogleCodeExporter]

So, if they have a sav or gcs file on their sd card and want to send it to the 
memory card it correctly converts it to gci now. But backing up to sd card is 
always 
in gci format I assume or are you somehow keeping track of the original format 
that 
they sent it to the memory card (if ever) to determine what format is stored on 
sd 
card? If it was never sent to memory card via gccm then the format would always 
be 
gci.

Can you add a patch for a byte-for-byte representation of all data stored on 
the 
memory card for restore and backup (gcp format)? Would this format permit a way 
of 
backing up private saves?

I thought of a way to try to use the program on the wii with original nintendo 
memory cards - by using Mega Man's gamecube homebrew loader (since it works in 
gamecube mode). I tried testing it with the gamecube dol but it couldn't detect 
the 
sd card in the front slot.

Original comment by [email protected] on 6 Jan 2009 at 5:34

[GoogleCodeExporter]

yes, it can import from all 3, will only export as gci. If you were running 
through
the gamecube homebrew loader you would need a sdadapter in slotA as Mega Man's 
loader
only starts from front sd and than the front sd slot is disabled. As far as gcp
backup\restore, I may look into it, but most of my free time is spend working on
dolphin. What information do you have on private saves? fireemblem seems to 
work no
matter which memory card I restore it to

Original comment by [email protected] on 6 Jan 2009 at 6:19

[GoogleCodeExporter]

I used this documentation to update the maxdrive save converter 1.0:

http://members.iinet.net.au/~theimp/gci/GameCube%20GCI%20Memory%20Card%20Save%20
File%
20Format%20Specifications.pdf

This was more informative on the situation:

http://www.tehskeen.com/forums/showthread.php?p=25464

Basically, it uses the serial # from the memory card (which changes when you 
reformat the card). Now, a gcp i figured could be used to restore it back to 
any 
memory card, assumming it copies the serial # with it. I am assumming the 
serial # 
is located in the 5 missing blocks of the memory card (why you have a 59 block 
instead of 64 block, and why u have a 251 block instead of 256 block). Its 
probably 
located in the first byte array 0000h - 1FFFh.

A protected save would at least have to have:
block offset changed to be at the same location on mc when restored
checksum changed
permission key changed
serial # changed in save file

There is an assumption that part of the save file is encrypted. In that case, 
changing the serial # on the mc would be a better possible solution. But not 
all 
info on those 5 blocks are known, so who knows if something else would need to 
be 
changed in those 5 blocks if the serial # is changed. 

The best solution appears to be gcp support.

Original comment by [email protected] on 6 Jan 2009 at 12:21

[GoogleCodeExporter]

Forgot to mention:

A protected save is not overwritten when you save a new game. A new copy is 
saved 
onto the memory card then the old one is deleted. So, if a save is 30 blocks, 
it 
would need a 251 block and 30 blocks free to save again. (A 59 block would be 
to 
small since it would need 60 avaialable when saving) 

Original comment by [email protected] on 6 Jan 2009 at 12:42

[GoogleCodeExporter]

I'm pretty much sure that gamecube always stores the files that way (create 
new, then
delete the old one) in order to prevent losing data.

I don't have many free time to look into you sav/gcs support, but as soon as I 
can
check it out it will be added, as it is useful so the user doesn't need to mess 
up
with pc tools. Canching the region may also be possible as it only consist in
changing the 4th gamecode character (though this won't work for all games).

About gcp format, I've already acomplished backuppinga byte to byte image, but
restoring does only seem to work if I write only a page (128 bytes) at the 
beggining
of a block.

I've bought a bba so I can do some tests with gcp images and protected saves on 
my
gamecube with ctr-gcs, as softdev's mctool (closed source) only can restore 
images to
the card it was made from.

Anyway restoring a gcp image to another card corrupts it (though all files are
accessible and working) so that makes me think that the assigned serial is 
elsewhere
in the mc.

You have info about the 5 nintendo reserved blocks in yagd. I pressumed that the
first 8 bytes where the serial, but the leaked nintendo mc tool that shows the 
serial
doesn't correspond.

Original comment by [email protected] on 7 Jan 2009 at 8:57

[GoogleCodeExporter]

Take your time looking at the latest patch, should be complete but I may have 
missed
something. Region changing is not an intended part of the patch, but my test 
gcs/sav
files are for pal ssbm, and since the original code only looked at the filename
rather than the full name that the gamecube checks. ie import pal save for ssbm 
when
a US save already exists. Most of what I have found is included in the Dolphin 
source
code 

http://code.google.com/p/dolphin-emu/source/browse/trunk/Source/Core/DolphinWX/S
rc/MemoryCards/

with my tests for gcp's using ctr-gcs I have only been able to restore to the
original card that it was from, and other card will show as corrupt.

as far as protected saves I am looking for a used copy of the games that use 
them so
that I can do further research

Original comment by [email protected] on 7 Jan 2009 at 9:10

[GoogleCodeExporter]

This is the information I have on the filesystem. The first byte array was just 
a 
guess for the serial number.

The File System
Offset/Range     Data Type    Bytes   Used For          More Info
0000h - 1FFFh    Byte Array   8,192   *Unknown          Unknown at this time.
2000h - 3FFFh    Byte Array   8,192   Master File Table Stores file names & 
data.
4000h - 5FFFh    Byte Array   8,192   Backup File Table Backup of file names & 
data.
6000h - 9FFFh    Byte Array   16,384  *Unknown          Unknown at this time.
A000h -Variable  Byte Array  Variable User Data Area    Game Data blocks.

The serial number could also be the 128th record in the master file table 
(3FC0h - 
3FFFh). only 127 records are allowed and manually editing the data in the 128th 
record location corrupts the memory card. Since reformatting a card changes the 
serial number it has to be located in these 5 blocks.

Original comment by [email protected] on 7 Jan 2009 at 9:50

[GoogleCodeExporter]

@jcwitzel
The document that you are using is a bit out of date, check YAGCD / Dolphin 
source
for more up to date information on what is known

Original comment by [email protected] on 7 Jan 2009 at 10:08

[GoogleCodeExporter]

I actually used that info to change God`s Game Suppliers Action Replay v1.09 
binary 
file (ggs-ar1.09.bin) to a dol. I didn't find it very useful though for 
gci/gcp/sav/or gcs info. I do see more complete info on the 5 block filesystem 
info. 
it doesn't mention anything about the 128th record.

Original comment by [email protected] on 7 Jan 2009 at 10:37

[GoogleCodeExporter]

there is an additional byte pair that should be swapped for sav files
0x06 and 0x07 (reserved01 & banner_fmt)
i forgot to update the patch when I discovered this

Original comment by [email protected] on 13 Aug 2009 at 11:46

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

lpfaint99:

The project has already updated their files with your previous patch data so I 
compiled sdsupp.c with that additional byte pair in the 2 locations that needed 
it. 
It seems to have fixed the icon corruption in the Gamecube Save data screen. 
Nice 
Work!
I released an unoffical version (Wii dol only) on eurasia.nu. I gave both of us 
credit. I hope this is OK. I am currently trying to get someone to help me 
track 
down the Official Nintendo gamecube memory card not working in Wii mode bug now.

Original comment by [email protected] on 9 Dec 2009 at 8:57

Attachments:

• sdsupp.c

[GoogleCodeExporter]

Added to rev12

Original comment by [email protected] on 27 Aug 2012 at 10:56

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by [email protected] on 27 Aug 2012 at 7:33

• Changed state: Fixed