ps1 raw saves conversion tool ready ;)

[dlanor]

----- snip ----- re: PSXMemTool problems with multi-slot saves

I've experimented a bit with this problem myself tonight, and I have to agree with you that PSXMemTool is completely unsuitable for working with multi-slot saves.

the .GME is cool since if it's opened directly from psxmemtool the 3blocks are there.

That is only because ".GME" is a full memcard file type. You get the same result with any other full card type, like ".mcr" or similar. The problem appears to be that Simon didn't implement routines to reassign slot positions and recreate directory headers for non-first slots of a save.

Let's clarify that a little:
In the case of a three-slot save, for example, the header from the ".mcs" file must be modified to indicate which slot is to be the second of this save (depends on what is free at import time), before that header can be placed in the directory section. Then a middle-slot header must be created for that 2nd slot, and it must in turn indicate which the third slot is, and that must be given a final-slot header in the directory section. And of course, for a four-slot save there would be two middle-slot headers instead of just one, and so on for larger saves.

if somoene can confirm that and maybe report the bug.
PSXRC is not at fault, can't fix the problem.
the most unbelievable thing is how can that bug hasn't been reported yet.

Actually I think that Simon Mallion has dropped development of this tool. Version 1.19b has been around for quite a while now, and I know that he is aware of the lacking support for multi-slot saves, because if you try to export a multislot save you get an error message stating that this simply isn't supported for multi-slot saves yet.

But the behaviour for import of such saves is indeed a bug, as the program clearly ignores the save size field in the header structure. It should at least have detected the size and refused the import, if he couldn't implement it properly at that time.


To change the subject to something brighter, I was wondering if you'd consider making a commandline version of your conversion tool, simply accepting a normal commandline argument for the name of the file to be converted.

My point in asking for this is that it would then be very easy to write a small BAT file which could then be used as target for mouse drag-drop of files. So I could simply pick up a file from a window with the mouse, and by dropping that on the BAT file (or its shortcut), it would invoke your conversion tool with the correct work directory and filename, without me having to type anything by hand.

I use this method a lot to make use of command line tools more convenient, and I'm sure it could work well for your tool as well. It's sort of like a "poor man's GUI", and without requiring any deep Windows-specific coding

Best regards: dlanor

[alkarl]

the drag&drop is ready, now the user only have to drag all his saves "raw and mcs mixed at once" and drop them on PSXRC and that's all.
i think that there is no more need of a bat file.

now that i think of it there is no more need of the old interface, what do you think do i have to supress it.
do you think that i have to call it a final version because i don't really see what other feature could be added.

i am interested in doing the same thing with pcsx2 and RawPs2 saves, but i lack documentation on pcsx2 memorycard, i tried to do it without but since i am a noob i got stuck ;p
i don't want to do the same mistake as with my late discovery of Joshua Walker's PSX tech docs, so iam asking

regards, Alkarl

[dlanor]

the drag&drop is ready, now the user only have to drag all his saves "raw and mcs mixed at once" and drop them on PSXRC and that's all.

Great!

i think that there is no more need of a bat file.

Agreed. That was just an idea for how to handle drag-drop with a conventional command-line tool, that only accepts arguments on command line. Since your program accepts drag-drop directly that won't be needed.

now that i think of it there is no more need of the old interface, what do you think do i have to supress it.

When doing things by drag-drop it's just irritating if the window stays on after the work is done. IMO that should only happen in three cases:

1: The user starts without drag-dropping anything. For this case it makes sense to show some info about intended usage, and then wait for the user to close the window. But you could also keep the present interface for that case, and let the user enter filenames by hand. (But who would want to ?)

2: The user has dropped files, but the names of the new files to be created would conflict with existing files. (eg: Dropping "BASLUS-00292GENSOU00" when the file "BASLUS-00292GENSOU00.mcs" already exists.) This should lead to the normal "overwrite/skip" queries for each such conflict. But after all such work is completeted, and unless any errors occurred, the window/dialog should still be closed automatically.

3: Whenever some error occurs, including drag-drop of files with wrong formats, as well as any file handling errors, the program should show whatever info seems relevant for the error, and then wait for user to close the window/dialog.

These are just suggestions of course, and I'm sure you can find your own solutions.

do you think that i have to call it a final version because i don't really see what other feature could be added.

I don't see any reason to make a specific statement about that, and calling any release 'final' usually means you'll have to eat your own words later. (Not you specifically, of course, but any developer.) Just call it a new version and let it go at that. (It's what I'd do.)

i am interested in doing the same thing with pcsx2 and RawPs2 saves, but i lack documentation on pcsx2 memorycard, i tried to do it without but since i am a noob i got stuck ;p
i don't want to do the same mistake as with my late discovery of Joshua Walker's PSX tech docs, so iam asking

Well, I don't have any computer capable of emulating a PS2 in anything even close to realtime. (My best shot is with an AMD 1800+ CPU, which is very much 'old hat' nowdays.) As a consequence I never did much with pcsx2, even though I do have it, and have barely managed to boot into a game menu on a few occasions.

With a rendering rate of a few frames per second there's not anything meaningful I can do with it.

Anyway, checking the size of Mcd001.ps2 as used by the emulator, it is clearly (8MB + 256KB). But that's all the useful info I can get. I can't even tell if this matches the real internal size of a Sony PS2 MC, because I can't access those cards in that way, but only through the file system.

The best place to find info on this is doubtless some forum dedicated to that emulator.

Best regards: dlanor

[dlanor]

@alkarl:
Hi again.

I'm just wondering what happened to the new drag-drop version of your tool. I thought you had it more or less finished, except for some 'polishing'. But now it's been 12 days since your last post, so I'm beginning to wonder...

Did you decide to add that Pcsx2 support before any new release ?

I'd really advice against that, because Pcsx2 testing can get very complex and time consuming. I suggest finishing off the new interface for the conversions that already work well, and then you can spend all the time you need/want on the Pcsx2 stuff, after releasing the drag-drop converter for PS1. The choice is yours, of course, but that's how I'd do it.

Best regards: dlanor

[Eduko]

Okay, I'm running into problems with this. This worked perfectly fine with my Valkyrie Profile saves, which I had three of. But with my Tales of Destiny 2 saves, it keeps saying that there's no such filename or directory.

But the ToD2 saves ARE in the same directory, and they're in the mcs format and everything. I went and redid my VP saves and it converted them fine, then I tried the ToD2 saves and it said it's not in the folder. So I went and renamed the VP saves to something else and it worked. Then I renamed the ToD2 saves and they didn't get converted. I even renamed them to a.mcs and b.mcs and it says they're not in the folder. This is frustratiing too because it's only been giving me issues with these.. =/

All of the saves came from epsxe to PSXGE (extracted them to single game saves) to this proggy.

EDIT: Infact, here, could someone else try to convert them for me and see if they have difficulities?

[ozzyfan]

Eduko, I tried to convert your saves and encountered the exact same problem.

The only suggestion I can think of is try to use PSXMemTool 1.19b with the saves instead of PSXGE, otherwise I'm stumped.

[dlanor]

Okay, I'm running into problems with this. This worked perfectly fine with my Valkyrie Profile saves, which I had three of. But with my Tales of Destiny 2 saves, it keeps saying that there's no such filename or directory.

But the ToD2 saves ARE in the same directory, and they're in the mcs format and everything. I went and redid my VP saves and it converted them fine, then I tried the ToD2 saves and it said it's not in the folder. So I went and renamed the VP saves to something else and it worked. Then I renamed the ToD2 saves and they didn't get converted. I even renamed them to a.mcs and b.mcs and it says they're not in the folder. This is frustratiing too because it's only been giving me issues with these.. =/

All of the saves came from epsxe to PSXGE (extracted them to single game saves) to this proggy.

EDIT: Infact, here, could someone else try to convert them for me and see if they have difficulities?

The problem is clear and easy to fix. The header of the MCS file shows that each raw gamesave has a name that's impossible to use in PC filesystems, as it contains both the characters '<' and '>', which are reserved for other purposes (batch processing I/O redirection operators).

When the program tries to create a file by that name, the operation fails because the OS refuses to accept such names.

Just open each MCS file in a hex editor and rename those characters to something legal which also helps you remember what the original value was. I suggest using ')' for '>' and '(' for '<'. The main reason for you doing the same is that I already tried that this works. The saves then convert without problems.

The raw saves may then be moved to a PS1 MC using uLaunchELF, after which you can also rename the files to restore the original names, as that is required for the game to recognize them. (Btw: On PS1 MCs, unlike PS2 MCs, the rename command of uLE does work.)

Best regards: dlanor

[Eduko]

Well, I did that..but uLaunchElf doesn't have >'s and <'s in the onscreen keyboard, plus my PC keyboard isn't USB based ^^;;.

[alkarl]

first i am sorry for not being able to reply.
i do not have anymore access to the internet from home
no i am not working on saves from pcsx2.
the work on dragdrop is complete though it need some polishing, i had some personal duties to attend to, so sorry for the delay.
eduko the problem is a real problem , dlanor's suggestion is THE solution
windows can't tolerate those characters so if there is some solution i will try to find it, i will definitely release that dragdrop version soon,i will work on it this night since i think that i do have all what i need on my pc.

[Eduko]

Hehe, yeah. Thanks alot for the proggy though, it's helped alot. I'll just wait for uLaunchELF to have the > and < characters added. So long as it's on a changelog somewhere when it's updated with it, I'll be good XP. Thanks again!