MemcardRex 0.5 released

[ShendoXT]

Changelog:

• Fixed error with the Shift JIS to ASCII conversion where 'b' character would come out as "bb".
  
• Added icon editor per TheCloudOfSmoke's suggestion.
  
• Added preferences dialog where user can change settings.
  
• Added support for Memory Juggler single saves.
  

Revision 2:

• Fixed a major bug in the card formatting function.
  
• Fixed error with import save function for Memory Card 2.
  
• Fixed error with the grid line settings for Memory Card 2.
  
• Added command line support per RedawgTS's suggestion.
  

You can download the application here.

[Gamesoul Master]

Works well from what I've tested so far. I do have a somewhat general question though...

I stumbled across this curiousity when I noticed that the second half of a linked save was incorrectly labeled in the file's header as a FFIX save (it was the second half of a FFIV save, in case you're curious). So I copied the save itself and created a new (empty) memory card, pasted the save in there, and then saved it. Checking the new file, the Game ID in the header was corrected as I had hoped, but I noticed something instantly. The Game IDs were still present for all the other saves that were on the memory card I copied the FFIV save off of. Most (if not all) of the actual data for them was gone of course, but I thought it rather odd that a fresh memory card would have that information on it. Wondering if maybe it was some matter of grabbing too much data from the card being copied from.

On a different note, I see MemcardRex still doesn't support .mcs single slot saves (I unsuccessfully tried to load one manually, just in case MemcardRex simply didn't like the extension). It's a rather simple format to support, and I noticed you had support for PSXGameEdit's full memory card format, so I'm wondering if you intend to implement its single-slot save format as well (with that, I can fully switch to using MemcardRex, since I convert PS3 saves to .mcs format for lack of knowing an easier/better format to change it to).

With that... I'm gonna go back to testing it some more...

Edit: I was looking at some of my clean (not modified/edited in any way) memory cards, and I notice that linked slots don't seem to normally have a Game ID in the header, leaving that only to the first slot save. Relating to that and what I mentioned earlier, would it be possible to have MemcardRex "clean up" a memory card when it saves it so that it isn't full of junk from repeated edits and deletions, amongst whatever else may clutter up a memory card?

[ShendoXT]

Actually MemcardRex supports .mcs since version 0.3, just go to import save (you first have to select a slot you wish to import to).

As for other question how you copied the save to other card?
By copy to temp buffer, another editor or emulator?

[Gamesoul Master]

It was all done through MemcardRex (copy to temp buffer). I simply highlighted the first slot of the double-slot save, copied it through the program, hit New to create a new memory card, and pasted the save into it. I wouldn't have reported it if I wasn't doing it all through your program...

Ahh yes... sorry about missing the single-save thing. For some reason, I was thinking it'd be under the same list as the full memory cards (which, thinking about it, doesn't make much sense since I'm used to using a different command in PSXGameEdit to load individual saves, but I guess I'm a tad slow at times... XD). Now I actually sort-of feel stupid for missing something so simple... LOL.

Edit: I should note that MemcardRex isn't necessarily *creating* any kind of extra clutter or header information... It just seems to like copying over more information than it should be when it's only supposed to be copying a certain number of slots. And my final suggestion mentioned in my first post is pretty much just a matter of cleaning up garbage/clutter information that doesn't belong, in the spirit of making it easier on people (like me) who work with memory cards in hex editors. Though I'd imagine that clutter building up over time could eventually lead to corrupt saves or even the whole memory card, if enough edits/changes are made to it (most likely noticeable only with saves for games that are a bit more picky about how they like their saves).

[ShendoXT]

Oh damn, formatting function is not working properly, I will fix that, thanks for the headsup.
"Copy to temp buffer" is working properly, though.

[Gamesoul Master]

Glad to be of service. It's hard to catch everything by yourself, you know? As I go along, I'll be continuing to look for little things that might help you make the program robust and perfect... ^^ (I'm very picky about making my programs as robust and perfect as possible).

[kirbyboy]

Shendo, are you the autor of the program?, my english is not very good so i understand that you are, if you are not, sorry.
I would like to know how to read a ps1 memory card data, icons, etc, like your program does, where could i find information about that?, thanks.

[ShendoXT]

Yes, I am the author of the program.

For information about the PSX Memory Card format you can check out this article.
If you need any additional help just ask.

[kirbyboy]

Thanks, i'm not going to really use that information, i don't have time or enough skill to make a program, i like read those things, but who knows, perhaps some day....

[Gamesoul Master]

Found a problem. I tried opening a memory card file that a person requested me to convert. This is the memory card file (.gme format). I only have MemcardRex v0.4 to v0.5r2... none of them will open it, instead giving an error that the "Memory Card is not valid". PSXGameEdit was able to open it with no problems.

Edit: Once the card is opened and resaved with PSXGameEdit, MemcardRex will open it just fine. So I take that to mean MemcardRex is having problems with something found in original .gme files (ones right from the DexDrive I mean). I tested some of my memory cards that came straight from my DexDrive, and MemcardRex was able to open 6 out of 8 of them.

If you end up needing them, I can upload some of my originals (a couple that work and a couple that don't).

[ShendoXT]

That card is actually not valid.
Look with the Hex editor, GME signature (123-456-STD) is missing.

Seems like PSXGameEdit is more tolerant and simply guess the format.

On a similar note, some versions of DexPlorer simply cut out the last part of the card if those slots are free
and MemcardRex will refuse to open those files,
that could be the problem you have with your cards.

Anyway I will fix that in the next release. Thanks again for the support.

[Gamesoul Master]

You are correct it seems. I hadn't looked that closely, because I knew that the files were still readable either way, so one way or another, your program should be able to also.

It seems to use some kind of system where, starting at 0x15, it puts an M, and then a letter for each slot used on the memory card (I can see that a Q is a first/single slot, and if the save is multi-slot then it puts an R for every slot used that isn't the first or last of the save, and an S for the last slot used by a save). Very interesting indeed. I wonder what actually makes use of that system (since reading cards without any header information like that works perfectly fine).

Not sure if you want/need any advice on it, but I think the easiest way to handle it would be to have a fallback function where, if someone tries to load a .gme memory card, and the program says it's invalid, instead of just throwing that error, it calls a function to check at 0xF40 to see if the "MC" string is at that address, and if it is, to read from that point and ignore all the .gme header information.

You could even have a message pop up saying that the .gme header was corrupt/incorrect, but that the contents of the memory card were still loaded successfully.

[ShendoXT]

Great idea. I will definitely add that feature.

Btw: GME header is built like this (note that MemcardRex has a function to create authentic GME header ):

The InterAct GME file format consists of three basic parts.

* A header (64 bytes)
* Fifteen 256-byte save descriptions (3840 bytes)
* The memory card data itself (131,072 bytes)

The 64-byte header contains only nine actual data fields, some of which are unknown but apparently unused.

* 16 bytes, the string "123-456-STD" followed by five 0x00 characters.
* A 16-bit value, always 0
* A 16-bit value, always 1
* An 8-bit value, always 1
* 16 bytes, the bottom 8 bits of each directory entry's block type
* 1 byte unknown value, varies but modification never seems to change anything
* 16 bytes, the bottom 8 bits of each directory entry's next block pointer
* 1 byte unknown value, varies but modification never seems to change anything
* 9 bytes, unused

[Gamesoul Master]

Thank you for that. I know I had seen that someplace, but I couldn't remember where. Now at least I understand a lot more what all that crap in the header is...

What I have to wonder is what the other 3,839 bytes are that come before the actual memory card data. With all my "good" DexDrive files, it's all just filled completely with zeroes (the ones containing corrupt header data have it filled with random jumble), so I have no idea why it'd be there in the first place, except maybe to provide a definitive size difference between DexDrive memory cards and standard non-headered memory card files.

But either way, I'm just glad the whole thing will be sorted out. Since your program creates authentic DexDrive headers, I assume you're just going to have the function regenerate a proper header for the file upon loading?

[Sune]

HEY!!! Get a room you two, or I'm going to alert an admin.

oh, wait..

seriously though, :thumbs up: