Emulator

here is a patch for this, havent actually looked at it yet :p

Some improvements on the patch.

here's my version of gigaherz's patch, I made it look a bit better and corrected the
fileselector so it actually sees .gci files :)
note: I tested it out, and you can't load imported GCIs ingame, and trying to export
as a gci crashes dolphin. probably a problem with gcmemcard class itself :<

I've tested out the changes that you added and I am still able to export as a gci.
Depending on which the memory card file, some cards always crash, some cards work
correctly, and some will work except the last entry will crash
I think the export problems are related to the gcmemcard class
I have uploaded a memory card that seems to work correctly
I have not been able to determine if the import function is at fault, for loading
ingame, or if it is the gcmemcard class

the memcard you uploaded appears corrupted to both ssbm and pikmin2(both ntsc). Just
wondering if you see the same effect. also, are you on irc or some other faster
communication? :p

p.s.- you are correct in saying that it has a problem exporting the last save. odd :s
looks like it might be time to try and get the gcmemcard class correct....

The memcard will show up corrupt in dolphin as both save files were imported gci files
if you export the saves as gci they should match the files i have uploaded,
the original memcard they came from is not available to me currently, original was
dumped to raw by ctr-gcs and it also shows up as corrupt,
I believe it shows as corrupt in dolphin because of certain data in
hdr,dir entry 128, dir backup, or bat/bat backup
I wont have access to faster communication until after 6pm pst

you should try getting a real raw memcard dump, and importing a gci, deleting it,
then comparing resulting memcard with the original raw dump. here is an example of
just loading a real raw dump and then closing it (supposedly not making any
changes...). seems to support what you're saying.

Files are different after testing originals and closing as well as taking the
original and importing a raw file and deleting it, I don't have HexDiff to make a txt
file but I have verified that the files are different.

As far as exporting the last save file if you attempt to copy the last save file from
slot A -> B or B -> A crash occurs at the same point
line 256/257 of GCMemcard.cpp

int nextblock=bswap16(bat.Map[block-5]);
assert(nextblock>0);
I am still looking into why this happens

Correct me if I am wrong but the function
GCMemcard::GetFileData on line 248 of GCMemcard.cpp
checks for the block after the current block it is copying
the reason it is failing on the last save is that it is copying block 64/256
and then reading the memory after that which is not allocated for the memcard
but does not equal 0xffff so the function continues and fails at assert(nextblock>0);

A fix for the GCMemcard::GetFileData function
Fixes the issue copying or exporting last save on a memcard

commited. I'm going to leave this issue open for a bit, maybe it can become a place
to improve GCMemcard ;)

p.s. thanks a lot! ask for svn access if you want to commit more, I don't want to
trod on your toes, so to speak.

I'm happy to help where I can, I would like svn access, I am currently trying to fix
GCMemcard::ImportFile, as well as I'd like to add Gameshark "gcs" and Max Drive "sav"
formats to importgci

lpfaint99, you got it.

wow, about the update counters, i literally facepalmed when i realized this:
the backup counter is always one less than the main counter, because when the card
was new, it was only written to the main, not the backup!

as for the increments, i noticed PSO (pal if that matters) doing +2 to the counters,
zelda:ww (ntsc) doing +4, and ssbm(ntsc) does +2. probably just has to do with how
the games do saving. I'm not sure what the bios memcard manager would increment, will
have to ask you (lpfaint99) or daco to check that out.

more notes:
the memcard file dolphin creates has 0xFFFF as both counters before a game saves to
it. maybe dolphin just writes all 0xFF?

after ssbm formats the card (before creating game data), the values are 0x0001 and
0x0000. There is my theory in action!! :D

after ssbm creates game data, 0x000E and 0x000D

I will format a memcard to 0xFF, format it with ssbm, dump it, create save data with
ssbm, and dump it again. Is it PSO 1&2 or PSO 3, I will test those as well as zww.

theory with increments. Possibly updating counters every memcard write
how far ingame did you go with each of the games

as far as dolphin writing all 0xFF code for this is done on line 114 of
Exi_DeviceMemoryCard.cpp

"I will format a memcard to 0xFF, format it with ssbm, dump it, create save data with
ssbm, and dump it again. Is it PSO 1&2 or PSO 3, I will test those as well as zww."
That will be helpful, but I meant dumping a memcard, performing a change to the
memcard in the gc bios, and then dumping it again. (this could help with ImportFile
too). I used PSO I&2.

"theory with increments. Possibly updating counters every memcard write
how far ingame did you go with each of the games"
For each of the games, I stopped after "wrote to memcardA" was printed to the gfx
output. I know dolphin only flushes the memcard data in ram to disk every now and
then, this could be the reason for the different increments.

"as far as dolphin writing all 0xFF code for this is done on line 114 of
Exi_DeviceMemoryCard.cpp"
ah yes, i just went to bed instead of looking for the line :)

"dumping a memcard, performing a change to the memcard in the gc bios, and then
dumping it again." I have done this and I will try and upload tonight

I should have been more specific, I am going to use ctr-gs to write 0xFF to my
original memcard and format it with original ssbm disc in my gamecube, dump it to
raw, create save data with on gamecube and dump it again.

Could not find ZWW, have to get back to work but will look at saves later

Dolphin will not load a memcard formated by gc memcard manager, or formated by ssbm
on real hw, don't know if it is noteworthy but thought id post it

anyways here is what i gather from formatBygcIPL.raw. When formatting a memcard the IPL:

backs up block allocation table
backs up directory

writes 0xFF from 0x2000 to 0x3FF9
updates/uses default directory counter and checksums (0x3FFA through 0x3FFF)

updates/uses default BAT counter, checksums and info (0x6000 through 0x6009)
writes 0x00 from 0x600A to 0x7FFF

It doesn't appear to touch actual file data at all, and there are 0s where ever there is no data.

p.s. that memcard (formatBygcIPL.raw) seems to be a bad test case, as it was/is an action replay card, and therefor has
a lot of stuff on it which although interesting (seems like it hijacks some stuff at boot? :) ), gets in the way of
finding out what a "real" formatted card looks like.

after looking at more dumps, i've come to a conclusion that line 857 should just be taken
out of GCMemcard, because the backup counter being larger than the dir counter does not necessarily mean that the backup should be copied to the dir.
Perhaps the GC uses some other means to check if a memcard operation has been completed
successfully?

"p.s. that memcard (formatBygcIPL.raw) seems to be a bad test case, as it was/is an
action replay card, and therefor has
a lot of stuff on it which although interesting (seems like it hijacks some stuff at
boot? :) ), gets in the way of
finding out what a "real" formatted card looks like."
the formatbyssbm memcard should be similar to what the ipl formats at, but i will
format the card with 0xff again and format it with the ipl instead of ingame.

the memcard has codes for AR to modify itself and look for dol files on the memcard
and if there is just one it will launch it otherwise it will list them to be chosen from

Card formated with all 0xff again and then formatted by the ipl

sorry, I had overlooked the ssbm formatted card before.

I have found that I can use real raw dumps in dolphin if I replace the first 0x13 bytes of the file
with this:
0x0750B25EC2A150A9E2047343000000000B1B595C
and then recalc the header checksums

this is the unknown (according to yagcd) data, and the OSTime
I think this is could be because dolphin does not have proper timekeeping implemented.
However, that can't be the only reason, since the unknown data is needed too.

thoughts? :p

p.s. i commited a fix for gcmemcard so that fix checksums button also fixes the checksum of the
header.

I wonder, since at 0x0C is the time of formatting, if the first 0x0B bytes also is a
variable from the time of formatting?

Possible, 2 headers created by the same memcard are interchangeable on the same
memcard, but if you take a header from a different memcard and write it to a memcard
it shows as invalid, where did you come up with the byte string?

formated memcard around 0:0:10 1/1/00

started work on adding updates to the bat.Map
files are still showing as corrupt after importing a file, but getting closer i think
patch includes various other fixes and the hdr fix function

Ingame with imported gci, patch sometime tomorrow when i can clean the code up
import file fixed, remove file still broken

awesome that you fixed importfile :)
as far as the unknown header on the memcard, it seems to deal either with the bios or
something else on the IPL.
I'm not really sure how to go about this, but I am trying :p

Patch here, code still wip, can you try it out with a memcard
havent had a change to test it in all cases,
took a memcard formated with ssbm in dolphin
added ssbm savedata, imported gci file for pikmin 2 and went back to ssbm
ssbm loads without asking to format, went to pikmin 2, and pikmin 2 loads without
asking to format either
Import file will almost certainly not work without having at least one save on the
memcard, and it may not work in all cases more testing is needed

Correction- convert to gci is broken not export

Patch works with up to 3 imported gci files, any more and the memcard is corrupted
according to games, maybe we instead of updating bat.map we should clear it and
create it again?

hmm i was just keeping this issue around as a place to talk with lpfaint...

Sorry, I didn't mean to disappear, I've been busy with other things, and haven't had
time to figure out what makes import file only work for 3 gci's with my patch. I'll
try to get on irc when I have a chance

Very messy patch, fixes importfile 100%(i think), I was able to import 126 files into
a memcard that already had one save and was able to get ingame needs further testing
as I do not have 127 different games to test may need to add check for existing save
game for a title, removefile at about 50% i would say, removes the file and does not
corrupt 0xA000-end, but something messes up somewhere 0x2000-0x9FFF i think its more
likely to be in 0x6000-0x9FFF, needs more research