Where is VMC in uLE+ ?

[TnA]

As the threadtitle, says...

[Peppers]

what ddo you mean? if you mean where can you acccess a USB stick its under "mass".

[TnA]

VMC=Virtual Memory Card

[MysTiCy]

Umh... i've seen u TnA on FreeVast thread so much, that i thought u know...
VMC is in HDProject app, it's not in any uLE.
Here's more info:
http://psx-scene.com/forums/official-hd-homebrew-project-forum/58029-tutorial-memory-card-emulator.html

And kinda direct answer, where VMC is in uLE, it's in either mc0, mc1, cdvf(or whatever the name is), hdd0 or host directory under file management, if u did put the HDProject.elf in one of those. :)

[amp2006]

VMC is in HDProject app, it's not in any uLE.

lol so that i got confused thought it could be something new i dont know ..

[TnA]

Umh... i've seen u TnA on FreeVast thread so much, that i thought u know...
VMC is in HDProject app,


I knew/know this, but


it's not in any uLE.


not that.
I thought I read something, that uLE is is direct VMC-Compatible and can also fetch it to RAM, like HDP does.
Maybe something new to implement. :)

Btw.: To which pfs does HDP mount the Partition?

[dlanor]

I thought I read something, that uLE is is direct VMC-Compatible and can also fetch it to RAM, like HDP does.
Maybe something new to implement. :)
VMC was implemented in uLE beta versions 4.12f and 4.12g, which do allow copying of files between VMC and other devices. If the so-called "uLE+" is based on v4.12g, then you should find "vmc:" in the filebrowser device list, with all the others. Using that entry should then lead to a fileselector where you can choose the vmc file to be used. After that choice this file is 'mounted' to the "mc0:" device using the MC emulator from the HDProject thread, and the filebrowser is automatically switched to "mc0:". The effect of this is that directly after choosing the vmc file you'll find yourself browsing its contents.

But that is just how I implemented things in uLE v4.12g. I have no idea if the same is true about that "uLE+" program, as I've never used it.

Please note that the method used for the beta VMC implementations were based on the so-called X-modules of the PS2 bios, and unfortunately those modules will corrupt the timestamps of all PSU backups created or restored from/to PS2 gamesaves, so that line of betas has been aborted. We still hope to reimplement VMC support in future uLE versions, using a fully homebrewed driver instead of the X-modules, but as yet no such driver is available... :(

Best regards: dlanor

[TnA]

AFAIK it has just HDL and maybe some other stuff embedded and is based on uLE Beta 4.12e.

Embedded:
-USBA
-VMC-Device-Hook (Game and original PS2-Browser, if we can return to that).
-SKIN (still switchable)

You may not like the idea about USBA and SKIN (as it may support piracy and blow up the elf), but the ELF's ever get loaded. ;)


THX 4 knldg.
regards TnA

[dlanor]

AFAIK it has just HDL and maybe some other stuff embedded and is based on uLE Beta 4.12e.

Embedded:
-USBA
-VMC-Device-Hook (Game and original PS2-Browser, if we can return to that).
-SKIN (still switchable)

You may not like the idea about USBA and SKIN (as it may support piracy and blow up the elf), but the ELF's ever get loaded. ;)
I'm opposed to embedding any material which I regard as unnecessary and/or not a natural part of the main program. And that includes media players, emulators, game launchers, as well as any files dealing only with cosmetics. No matter what skin we include, odds are that well over 50% of the users will never use it, preferring their own. So to all of them that embedding will just add dead weight (often stealing MC space).

As for VMC, we do plan to incorporate basic VMC device support, once we have a suitable device driver. But the in-game hooking you want is not something uLE will deal with. That needs to be implemented for whatever game launcher you use to launch those games.

Best regards: dlanor

[spkleader]

dlanor: you said about those xmodules in the bios.. what if you let a option for the user add his own modules in ule just like a skin or a language file? Let's say, but the modules in the sys-conf dir in the memory card and make uLe look for it there? Or even better, look for the modules on a hdd? or, if you want to be really picky, look for the modules from the PS2 disc present in the ps2 drive? ;)
Just a tough... but oh well.

[suloku]

dlanor: you said about those xmodules in the bios.. what if you let a option for the user add his own modules in ule just like a skin or a language file? Let's say, but the modules in the sys-conf dir in the memory card and make uLe look for it there? Or even better, look for the modules on a hdd? or, if you want to be really picky, look for the modules from the PS2 disc present in the ps2 drive? ;)
Just a tough... but oh well.

The problem isn't accessing X-modules, they are inside all ps2 bioses, the problem is they doesn't work OK for VMC to be really implemented and fully working.

[spkleader]

The problem isn't accessing X-modules, they are inside all ps2 bioses, the problem is they doesn't work OK for VMC to be really implemented and fully working.

Well doh, read again my post please. I was talking about the modules present in a PS2 disc. Aka, the user (a evil pirate, as always) copies the modules from the PS2 game disc and put in a place where uLe can make use of it. :chinscrat

[suloku]

I don't think there's any real difference on using the drivers from disk or from the bios, the whole think is about making a working driver.

[spkleader]

suloku: If I remember well, the xmodules are 'limited' hence the incompatibility. The modules present in a ps2 discs are 'complete'. But again, I might be wrong, I guess mr. dlanor might answer that for us ;)

[dlanor]

suloku: If I remember well, the xmodules are 'limited' hence the incompatibility. The modules present in a ps2 discs are 'complete'. But again, I might be wrong, I guess mr. dlanor might answer that for us ;)
In fact VMC seems to work just fine with the X-modules, as VMC was implemented in uLE v4.12g beta.

The reason why X-modules are not acceptable for use in uLE is that they destroy the integrity of timestamps for gamesaves saved/restored to/from PSU backup files (psuPaste command in uLE). The normal bios MC modules allow uLE to set timestamps as a separate operation, so as to ensure restoring the original state, but X-modules do not allow that so each folder and all files in it will receive a timestamp based on the realtime clock value at restore time. Thus the resulting gamesave folders, and their contents, will be different from the originals that were saved... :(

The drivers from game discs can also contain other differencies, but are mostly closer related to the X-modules than to the 'normal' bios modules. That is the reason why the VMC emulator works well with many commercial games.

Best regards: dlanor

[spkleader]

Thank you for the explanation dlanor. Still vmc on ule would be great, even with that little 'problem'. Just a tought... wouldn't be possible to ule store the original timestamp then change it in the new save?

[suloku]

Thinking of it, using psu is a nice feature, but it isn't really required to backup a savegame, as ule can restore them even if they are protected, only problem is it is a folder and you can't change its name, but that is the way I have been backuping my savegames since ule 3.41j.

For what you have said, backuping the savegames this way might be possible without any issues right? Then why not disabling psu load/save for vmc for the mean time and still be able to browse and change it's contents.

If someone really needs to use a psu, he can always use a real mc as intermediary or extract psu contents on a computer and copy them to the mc.

It's just my opinion, anyway I can always use 4.12g beta if i need to handle vmc contents on my ps2.

[dlanor]

Thank you for the explanation dlanor. Still vmc on ule would be great, even with that little 'problem'.
No. The integrity of PSU saves is more important than VMC access.
If/when we do implement VMC in uLE again, it will be through some new device driver that does not require X-modules.

Just a tought... wouldn't be possible to ule store the original timestamp then change it in the new save?
That is exactly what uLE attempts to do, since the functions that create files and folders automatically do so using a timestamp based on the current realtime clock value. So uLE thereafter uses a special function to modify status flags and timestamp value of each file and their containing folder to the values originally saved into the PSU file. But when X-modules are active that special function is incapable of changing the timestamps, thus leaving the incorrect timestamps (current realtime) for all the gamesave files and their containing folders.

Best regards: dlanor