ShendoXT
Full Member
Prototype
Posts: 124
|
Post by ShendoXT on Apr 17, 2008 17:37:48 GMT -5
Changelog: - Memory Card open function rewritten, files should load a lot faster now.
- Fixed a small error when editing icon of the save on Memory Card 2.
- Old DexDrive cards (with missing slots) and the ones with corrupted header are now supported.
- Requirements have been dropped down to .NET Framework 2.0.
- Right click menu added per Hard core Rikki's suggestion.
- Added save cards prompt upon closing if memorycards have been edited.
- Added occupied slots indicator in save information dialog.
 You can download the application here |
|
|
|
Post by Gamesoul Master on Apr 17, 2008 22:40:52 GMT -5
Deleting any saves and saving it as a new card still leaves the Game IDs of all the other saves in the header. By "delete", I mean the option to remove the save and format the slot. Also, the program still carries over an error that is originally not its fault. I notice that with some of my saves that take up more than one slot, that second slot has an incorrect Game ID in the card's header (for instance, the second slot of my FFIV save has a Game ID of FFIX (a save of which *does* exist on the card, but obviously is a single-slot save). Now MemcardRex has always been able to see that the slot belongs to the FFIV save (which is good), but if I copy the FFIV over to a new card, when the new card is created, it still has the bad/incorrect header on the second half of the save. It works fine for usage, so this isn't a major problem by any means. Is there any way for it to pull or calculate the correct Game ID though? Somewhat related to that issue (as fixing that would more easily enable this request), would it be possible to have MemcardRex show the Game ID of a linked slot? If not that, would it be possible for you to have it move those slots to be in order with the save they belong to? I realize that might be a pain in the ass, but no memory card editor seems to have that particular feature. So if it's possible, that would be an awesome feature to have. If there's major difficulty in doing something like that, I'd like to know why (since *no* program seems to do it, I could imagine that it might just be difficult to do). Of course, were you to do something like that, it'd be best left as an option instead of something it just does. An option like "Optimize save slot order" would certainly be a neat and unique thing to have for this program...  Also, the "Remove save (format slot(s))" command doesn't really seem to work like it should. The information is pretty much all still left there, except that the "Restore save" command doesn't work (which it shouldn't normally, except that since the data is still pretty much all there, it actually *should* be able to restore it). When I took a quick look through (I deleted all but my first two saves), the whole second half of the cards (one with all 15 slots full and one with just the two) looked identical. Maybe a really close look would've shown a small difference here and there, but a quick look revealed none. Besides that, everything else seems to work as intended (I'll keep looking of course). Memory cards don't seem to open any faster than they used to though. Maybe that's just for me though. The program itself still opens a little slower than any similar editor I have, but only by about 1-2 seconds. |
|
ShendoXT
Full Member
Prototype
Posts: 124
|
Post by ShendoXT on Apr 21, 2008 14:30:26 GMT -5
Deleting any saves and saving it as a new card still leaves the Game IDs of all the other saves in the header. By "delete", I mean the option to remove the save and format the slot. Will fix  Also, the program still carries over an error that is originally not its fault. I notice that with some of my saves that take up more than one slot, that second slot has an incorrect Game ID in the card's header (for instance, the second slot of my FFIV save has a Game ID of FFIX (a save of which *does* exist on the card, but obviously is a single-slot save). Now MemcardRex has always been able to see that the slot belongs to the FFIV save (which is good), but if I copy the FFIV over to a new card, when the new card is created, it still has the bad/incorrect header on the second half of the save. It works fine for usage, so this isn't a major problem by any means. Is there any way for it to pull or calculate the correct Game ID though? Possible but useless, link slots aren't supposed to have prod code, identifier and region. Linked slot is connected to initial slot by other method. The error probably appeared because of the bug in the game, sorry but I can't add feature to fix headers as it would maybe corrupt some saves. Somewhat related to that issue (as fixing that would more easily enable this request), would it be possible to have MemcardRex show the Game ID of a linked slot? If not that, would it be possible for you to have it move those slots to be in order with the save they belong to? I realize that might be a pain in the ass, but no memory card editor seems to have that particular feature. So if it's possible, that would be an awesome feature to have. If there's major difficulty in doing something like that, I'd like to know why (since *no* program seems to do it, I could imagine that it might just be difficult to do). Possible but it would mess up things really bad. Each list index correspond to each save slot (0-F), resorting the list you would access the wrong slot. |
|
|
|
Post by Gamesoul Master on Apr 21, 2008 23:00:32 GMT -5
What about the first part of my last request? The part about showing the Game ID of the linked slot? It would of course be read-only, and the other information really doesn't matter. But just so a person actually knows what the linked slots belong to (since apparently the PS1 is too stupid to keep them with the saves they belong to). I'm actually having that problem right now (can't figure out what two linked slots belong to on my memory card). That way, if it at least shows what game it belongs to, I can just put the Game ID into the header of the linked slots myself.
Since you mentioned linked slots not having any of that header information, I looked for more saves and noticed you were right. Thanks for clearing that up. As for the last bit of info... Now it just makes me curious about how that works, so I'm going to go look into more information. Maybe if the news looks good, I'll code something to see if any optimization can be done on files (likely doubtful, but I'm pretty stubborn and it's my own time anyway, right? XD).
|
|
ShendoXT
Full Member
Prototype
Posts: 124
|
Post by ShendoXT on Apr 22, 2008 16:06:16 GMT -5
I suggest that you read this article which i also suggested to kirbiboy. Every part of the memorycard format is explained in detail. |
|
|
|
Post by Gamesoul Master on Apr 23, 2008 4:08:28 GMT -5
You know... I keep losing that link, which is bad. Because every time I've looked at that article/document, it's always been quite interesting (and every time I read it, I love reading the DexDrive section, specifically the part about communicating with the DexDrive). I'm going to store that link someplace safe now, so that I can take a close look at it soon.
And thanks again. You've been a great help, both with your binary contributions and with information... ^^
|
|
hanman
Full Member
Irvine "Super-Pimp" Kinneas
Posts: 142
|
Post by hanman on May 12, 2008 11:48:30 GMT -5
i seriously LOLd at that. it's a good thing my co-workers already think i'm strange. do you think pSX Author could use this info to implement DexDrive support into pSX? i think it would be awesome to save directly to a real PSX memcard. btw, this app is awesome and just what i was looking for. much more usable than the 5-10 year old apps out there. all it needs feature wise is DexDrive support! |
|
|
|
Post by Gamesoul Master on May 12, 2008 14:36:45 GMT -5
Well, DexDrive device support tends to be a low priority with how few people out there actually have one (I'm proud to say I do, and it only cost me $12 at the time, brand new).
Every time I read that document, I laugh at that too... ^^
The document would be easily useful for adding support. In fact, it would be the only needed source, as it pretty much tells exactly how to do it. But as I said, support for the device itself is rather low-priority. Besides, he'd need to at least implement support for the memory card format first... lol.
|
|
