Closed GoogleCodeExporter closed 8 years ago
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 jcwit...@gmail.com
on 4 Jan 2009 at 11:04
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 lpfain...@gmail.com
on 4 Jan 2009 at 11:38
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 jcwit...@gmail.com
on 5 Jan 2009 at 2:26
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 lpfain...@gmail.com
on 5 Jan 2009 at 3:17
Attachments:
check your u8 and u16
Original comment by jcwit...@gmail.com
on 5 Jan 2009 at 3:54
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 lpfain...@gmail.com
on 5 Jan 2009 at 4:29
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 jcwit...@gmail.com
on 5 Jan 2009 at 11:58
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 jcwit...@gmail.com
on 5 Jan 2009 at 12:34
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 jcwit...@gmail.com
on 5 Jan 2009 at 12:42
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 lpfain...@gmail.com
on 6 Jan 2009 at 1:53
Current Patch, allows for perfect gcs import (Exported as gci and hex compared
with
the original), sav import currently not working
Original comment by lpfain...@gmail.com
on 6 Jan 2009 at 2:28
Attachments:
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 lpfain...@gmail.com
on 6 Jan 2009 at 2:53
Attachments:
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 jcwit...@gmail.com
on 6 Jan 2009 at 5:34
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 lpfain...@gmail.com
on 6 Jan 2009 at 6:19
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 jcwit...@gmail.com
on 6 Jan 2009 at 12:21
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 jcwit...@gmail.com
on 6 Jan 2009 at 12:42
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 sulokuTDCmago@gmail.com
on 7 Jan 2009 at 8:57
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 lpfain...@gmail.com
on 7 Jan 2009 at 9:10
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 jcwit...@gmail.com
on 7 Jan 2009 at 9:50
@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 lpfain...@gmail.com
on 7 Jan 2009 at 10:08
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 jcwit...@gmail.com
on 7 Jan 2009 at 10:37
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 lpfain...@gmail.com
on 13 Aug 2009 at 11:46
[deleted comment]
[deleted comment]
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 jcwit...@gmail.com
on 9 Dec 2009 at 8:57
Attachments:
Added to rev12
Original comment by sulokuTDCmago@gmail.com
on 27 Aug 2012 at 10:56
[deleted comment]
[deleted comment]
Original comment by sulokuTDCmago@gmail.com
on 27 Aug 2012 at 7:33
Original issue reported on code.google.com by
lpfain...@gmail.com
on 4 Jan 2009 at 9:31Attachments: