I have removed attachment from his post.
I just hope it wasn't done on purpose. Better scan your files for viruses.
Excatly, that's why you shouldn't care about them.Quote:
Not releasing - a liar, releasing - an idiot... You just can't make some of the people happy, no matter what you do .
So just forget about them.
The fact is, and I think you know it well, that you have made most of us very happy by persevering in this project (and others) to the benefit of us all.
Best regards: dlanor
I'm just curious about one thing. How do things look on PS3 side? I mean, the ones with backwards compatibility... Are there any special requirements to make anything work on it? How well is PS2 emulated on PS3? Is it full emulation or it's just a general one made to make most of the games working but nothing more? PS2PSXe relies heavily on TLB and exceptions... Do these work properly on PS2 emu included in PS3? How's the hardware access? Do mass devices work fine or are there some ps3 specific fixes necessary? Do things like uLE or radshell work on it?
Because I'm quite curious, I would be glad if someone could help me test it. I can provide all the PS2 and project related support, though the PS3 related stuff is totally beyond me (I don't have one and know barely anything about it). It's not a priority, I'm just curious... If the changes required are not big, I think it could be done... If there is a lot of work required, I'll pass. The backwards compatible PS3s are obsolete now, no longer in production, so it would ba a waste of time. Then it would be simply easier to wait until some exploit is available and write native ps3 app (well, there is one, but they're selling it with every game through psn, and this sucks... why to pay for a game you already own...).
PS. Emulator running emulator... How perverse! ;) .
Forget about it. I've read a little bit on the topic and now I know how stupid I was ;).
When you launch the emulator through PS2Link, with both game image, bios, and MC files being loaded from a PC, then you are dependent on the HOST protocol connection remaining active for the remainder of the session. That connection is in fact split into two parts, one of which resides in PS2Link on the PS2 while the other resides in ps2client on the PC. So closing the ps2client command line window terminates the HOST connection, which inevitably freezes the emulation.
It is like simultaneously removing the game disc, unplugging the bios chip, and jerking out both MCs from a real PS1, and then expect it to continue running the game... :lol:
You are on the right track, but not quite there.Quote:
I put games on a partition on my PS2 hdd, but have no idea how to get them loaded.
I am guessing I use path pfs0:/+PS1/gamename.img instead of host: to start for the cdimage path
For one thing, the partition name is never included in a PFS path. It is only used in mounting an "hdd:" partition onto a "pfs?:" device mountpoint. Then you access that "pfs?:" device as if it was the true root directory of the mounted partition. So with "gamename.img" stored in the root of that partition the PFS path would be "pfs0:/gamename.img", without any explicit mention of the partition name.
But in addition to this you must first have loaded all the necessary device drivers, like I do in the following radshell script section:
The last command line above shifts the current work directory into a PS2PSXe folder on that HDD partition, where I have placed all the usual files and subfolders from the PS2PSXe package (including bios files, MC files etc).Code:
load ps2hdd.irx -o 4 -n 20
load ps2fs.irx -m 4 -o 10 -n 40
mount pfs0: "hdd:+Test 2"
NB: Storing the above radshell script and the modules radshell needs to load on HDD will obviously not work, since there will be no way of accessing the HDD after the initial iopreset, even though the HDD drivers may have been active before that in uLE. So the initial RadShell launch, and the execution of this script needs to be started from MC. The script above is suitable for use as inital "radshell.rsh" to be launched by RadShell every time you boot it, especially if you installed RadShell specifically to use with PS2PSXe.
After executing the script above, I am then ready to run various scripts to launch games, such as the following "test_CT.rsh" script that I use to launch "Chrono Trigger" of the "Final Fantasy Chronicles" release (where CT is SLUS_013.63).
As you can see this script starts by deleting the current MC files (too drastic, you think ?), so as to replace them with game specific MC files from another folder in the root directory named "!_PSX_MC", where I keep a collection of such MC files for all the installed games (originally I made those MC files for use with ePSXe, via ePSXeCutor).Code:
copyfile "../!_PSX_MC/ChronoTrigger_m1.mcr" mc/epsxe000.mcr
copyfile "../!_PSX_MC/ChronoTrigger_m2.mcr" mc/epsxe001.mcr
run pfs0:/PS2PSXe/ps2psxe.elf "-cdimage=pfs0:/!_PSX_ISO/Chrono_Trigger_US/Chrono_Trigger_US.ccd" -xoff=40 -digitizepad
And after setting up the MC files needed for the game, the script proceeds to launch PS2PSXe with a -cdimage path for the game, which in this case is stored in a subfolder of another collection folder in the root, named "!_PSX_ISO" and holding one folder for each of the installed games.
I do this to keep the game files separate, since a game image in CloneCD format can have up to four separate files, and this quickly gets messy if just putting all game images in a single folder. It gets messy enough anyway with the larger games, having up to four discs (thus 16 files in a full cloneCD file set of ccd, cue, sub, img).
But of course, if that was the only type of script used, the initial MC deletion would be fatal.
To avoid having all gamesaves destroyed when next launching a game this way, it is essential to also have a cleanup script, for use each time you have run a game making new saves. And this script too needs to be individual per game, as in the following "post_CT.rsh" example for "Chrono Trigger".
As you can see this does not involve the emulator itself in any way, but merely ensures that the MC files in the collection folder are updated (by replacement) with the newest gamesaves for the game that was just used.Code:
copyfile mc/epsxe000.mcr "../!_PSX_MC/ChronoTrigger_m1.mcr"
copyfile mc/epsxe001.mcr "../!_PSX_MC/ChronoTrigger_m2.mcr"
With this method it is the responsibility of the user to recognize which was the last game used and when it is necessary to use a 'post_xxx.rsh' script to preserve the saves. But it is simpler to implement this way.
I have also done some experiments where the scripts themselves can keep track of such things by various methods, but it gets rather complex and prone to failure if the user makes any errors in script preparation. I think the above should do for most immediate needs anyway.
Best regards: dlanor
sorry about it i compress the folder so i must have something on my pc about my kaspersky don't know...