Quickest way to get stuff onto HDD?

[JuddMan]

what is the fastest way to get many files (about 60gb into 6gb partitions) onto the PS2 HDD?
a few tests i did:
CDVD: 2 minutes 37 seconds to copy a 299mb file from DVD...
(file 3 of 14, so near the inside of the disc)

FTP: 200kb/s average speed. (slow, but very convenient for small files)

I don't have a server side app for 'host' at the moment. is that worth getting? or is CD/DVD the fastest thing you can get on the PS2?

what speeds does host achieve? if over 600k/s it would be worth using over CD/DVD... (i swap)


(ATM I don't trust any PC browsers... one buggered a secondary drive i was testing it on... good thing it was secondary :))

[dungbeetle46]

set hdd to slave and put in pc and then use winhiip to dump them onto hdd

[cyx]

Maybe I'm lazy to open up computer, but I still prefer my cheap $15 IDE=>USB2 cable to do the job.

[gravelhead44]

I agree. IDE to USB 2 is a lot more convenient than having to open your PC case. And pretty quick.

[skidude2121]

Yeah but right now Winhip can only transfer ps2 isos, The only way to get files like divx movies onto your ps2 from your computer is through ftp until someone creates a program like winhip that will let you transfer files quickly into common partitions.

[JuddMan]

yep. i use winhiip for ISO installing... that's not a problem.
so over the last 2 days i have copied about 60gb of divx files onto my HDD from CDFS using the swap trick... i dont think there's a quicker way... was just wondering about the speed of 'host' which i've never used.

btw, is it safe to copy onto HDD same partition using FTP and CDFS at the same time? i noticed it is possible but cancelled the FTP at 70mb cause it was going to take half an hour.

[KaylaKaze]

They have a program in testing that can write to PFS partitions on a PC but,well, it's still in testing. Public, but from what I read, not entirely reliable yet.

[JuddMan]

yeah i've used PS2PFS explorer on a test drive and it corrupted it. if they can work out the bugs though it definately has promise.

[Torch]

yep. i use winhiip for ISO installing... that's not a problem.

I use a round about way to copy files from my comp to the ps2 hdd...though u'll temporarily need twice the space of the stuff ur gonna copy..

Use cdvdromgen to create a uLaunchELF boot iso...also add all the files you want to copy to the image..

Then use Winhiip to transfer it as a hdloader iso...you should get a decent 25-30mbps here.. less than a minute for 1 GB

Then boot up hdloader on ur ps2 and launch ur newly image..it should boot into uLaunchELF..

Heres where the magic happens...since HDloader is practically nothing but a virtual cd drive, when you access the CDFS in uLaunchelf, it will display the contents of your ISO!!!!!!!!! :D instead of the actual dvd in the drive..

Now all you have to do is copy it to the hdd0 partition..then delete it from HDloader..
:cool:

[dlanor]

I use a round about way to copy files from my comp to the ps2 hdd...though u'll temporarily need twice the space of the stuff ur gonna copy..

Use cdvdromgen to create a uLaunchELF boot iso...also add all the files you want to copy to the image..

Then use Winhiip to transfer it as a hdloader iso...you should get a decent 25-30mbps here.. less than a minute for 1 GB

Then boot up hdloader on ur ps2 and launch ur newly image..it should boot into uLaunchELF..

Heres where the magic happens...since HDloader is practically nothing but a virtual cd drive, when you access the CDFS in uLaunchelf, it will display the contents of your ISO!!!!!!!!! :D instead of the actual dvd in the drive..

Now all you have to do is copy it to the hdd0 partition..then delete it from HDloader..
:cool:
Are you saying you actually did this ?!?!?

The reason I ask for confirmation is that this is not supposed to be possible, as it requires two different sets of HDD drivers to access the same drive simultaneously. I can see how it would work fine for copying stuff to another device, like MC or USB storage devices, but I don't see how it could work for copying stuff to another partition of the same IDE drive that the ISO is stored on.

Best regards: dlanor

[KallaiR]

i have the same question as dlanor has. i have also ulaunchelf installed in my hdd and i can boot it from hdloader but i can't access the hdd afterwards. did u actually did it or u think that this way might work?

[ahmadka2]

I use a round about way to copy files from my comp to the ps2 hdd...though u'll temporarily need twice the space of the stuff ur gonna copy..

Use cdvdromgen to create a uLaunchELF boot iso...also add all the files you want to copy to the image..

Then use Winhiip to transfer it as a hdloader iso...you should get a decent 25-30mbps here.. less than a minute for 1 GB

Then boot up hdloader on ur ps2 and launch ur newly image..it should boot into uLaunchELF..

Heres where the magic happens...since HDloader is practically nothing but a virtual cd drive, when you access the CDFS in uLaunchelf, it will display the contents of your ISO!!!!!!!!! :D instead of the actual dvd in the drive..

Now all you have to do is copy it to the hdd0 partition..then delete it from HDloader..
:cool:


tried this long time ago...it doesnt work as when u boot the custom ISO, ULE doesnt see the HD !!!

[yoclick]

So just to confirm, for transferring large files the best option is cDVD? Is there no other fast way (preferably via FTP). At the mo, im only getting 160MB/s which is very very slow. If there isnt another method, il just continue with this, leave it on for a while and get most my media up.

Oh is there a HD size limit? I've got a 120GB for games but was considering buying a 250mb HD for videos + mp3s etc. Will a harddrive that size work still?

Thanks!

[Proton_]

well i have a laptop and a crossover cable and use the ps2net in ulaunchelf and transfering mp3 vids using flashfxp and is about 300kb/s i guess that's too much for me because i have dialup and not broadband

[dlanor]

So just to confirm, for transferring large files the best option is cDVD? Is there no other fast way (preferably via FTP). At the mo, im only getting 160MB/s which is very very slow. If there isnt another method, il just continue with this, leave it on for a while and get most my media up.
160 MegaBytes per second is not considered 'slow' in the PS2 world, but rather 'SUPER FAST'. ;)

In fact I've never achieved such speed myself, and find it hard to credit your measurement. I get 2MB at best, and that's only when copying some large file from DVD to HDD. (smaller files cause more overhead costs => lower speed)

Oh is there a HD size limit? I've got a 120GB for games but was considering buying a 250mb HD for videos + mp3s etc. Will a harddrive that size work still?
I use a 300GB drive myself, without any problems, but you do have to check what version you use of some softwares. Some only support drives less than 128GB (aka 28-bit LBA), while some have been upgraded to work with larger drives too (aka 48-bit LBA).

Best regards: dlanor

[dlanor]

well i have a laptop and a crossover cable and use the ps2net in ulaunchelf and transfering mp3 vids using flashfxp and is about 300kb/s i guess that's too much for me because i have dialup and not broadband
Surely your dialup connection is not involved in local networking with your PS2 ! That should only affect you internet access, not any LAN transfers.

In any case, 300KB/s sounds perfectly normal for FTP between PC and PS2.

If you want higher speed LAN transfers you should try using 'host:' instead. For this you need to set up ps2client.exe on the PC, preferably using one of the smart frontends for it (RadHostClient, PS2AutoClient, PS2ClientLoader). Then you can browse the shared PC folders from uLaunchELF, just as if they resided on a PS2 storage device. The host: interface normally achieves speed exceeding 500KB/s, so it's quite an improvement over FTP.

Best regards: dlanor

[Proton_]

alrady downloaded rad host client but it says .dll file noy found, msvcr71.dll vb file?? i'm using win me

[Proton_]

and for ps2autoclient and ps2clientloader i can't find them

[yoclick]

160 MegaBytes per second is not considered 'slow' in the PS2 world, but rather 'SUPER FAST'. ;)

In fact I've never achieved such speed myself, and find it hard to credit your measurement. I get 2MB at best, and that's only when copying some large file from DVD to HDD. (smaller files cause more overhead costs => lower speed)
Best regards: dlanor

Sorry, that meant to say 160KB/s! Right now i'm transferring a 1GB file and its taken roughly 2 hours. This is tedious, there must be some other way? Although its not too bad since im transferring wirelessly so it doesnt hugely make a difference, just im impatient :lol:


Oh, is it possible to just connect the HD to the IDE cable and the newly partioned part should appear on windows? Therefore i can drag and drop and a much better speed. Just that way I would move all 10GB's of data i want straight away.

Thanks!

[flamingo24]

Oh, is it possible to just connect the HD to the IDE cable and the newly partioned part should appear on windows?

no, windows doesn?t support ps2 partitions/file-systems (only fat12/16/32, ntfs)

[yoclick]

RadHostClient it is then. 500KB/s isnt too bad i guess. It will definatly make an impact when I transfer a 4GB file i got! :-)

[Krack3n]

Well what would you all say if there is a way to use HD Dump Utility to dump all contents of CD or DVD by using a CDX{UMCDR Bla, bla, bla Dragonite's wishes :cry: ) If you know what you mean ;) . Can any one say UMCDR SNES Station! Hint, Hint. But I'm not talking about that lame MC Loader 1.35 trick. Admin's please delete if I'm stepping on toes.

[tester3000]

I would connect hdd to pc via ide cable and then use a utility like winhiip to copy iso to hdd. Correct me if i am wrong but you will probably get a really fast speed like 100mb/s (the actual transfer rate that you have if you are transfering from hd to hd in windows) forgive me if i am wrong cause i'm still pretty much a noob.

[nakkizz]

Any idea what wron with my config: Ftp upload speed to ps2 is only 50KB/s but download is ~500KB/s. I tried also "host:" client but I did not measured transfer speed, but it's felt faster but not even close to 2MB/s.

[Proton_]

i don't thinks there's something wrong i have max 180kb/s up to the ps2 and down almost 900kb/s maybe that's how it works

[nakkizz]

Can anyone confirm what is maximum ftp upload speed?
In my test case uLaunchELF ftp server upload speed is 50KB/s (test file 80MB ~20min). Same file upload with uLaunchELF host: function transfer speed in 333KB/s (test file 80MB ~5min).

So is this 50KB/s normal? I have tested my setup with different cables and also with cross cable. Different ftp clients also tested. No affect to ftp speed.

Proton: Your upload speed is 3xfaster than my, so something is different?

[Proton_]

i have a crossover cable and for the 50kb/s i've found that's the speed i get when i upload to the memory card, and i'm using flashfxp, dunno why can't you get more speed, but as far as now i'm getting download from hd 1mb/s and upload to hd 210kb/s now i'm getting faster speeds

[dlanor]

i have a crossover cable and for the 50kb/s i've found that's the speed i get when i upload to the memory card, and i'm using flashfxp, dunno why can't you get more speed, but as far as now i'm getting download from hd 1mb/s and upload to hd 210kb/s now i'm getting faster speeds
When uploading to a memory card, the main bottleneck is the slow speed of all MC access. This is even more of a problem with 3rd party MCs of larger sizes.

For example, the Datel 32MB MCs I have are approximately half as fast as original Sony MCs. Even with host: (always faster than FTP) I often get speeds around 40kb/s for pasting files to MC (something I do a lot in testing new uLE lab versions).

Best regards: dlanor

[Torch]

Are you saying you actually did this ?!?!?

The reason I ask for confirmation is that this is not supposed to be possible, as it requires two different sets of HDD drivers to access the same drive simultaneously. I can see how it would work fine for copying stuff to another device, like MC or USB storage devices, but I don't see how it could work for copying stuff to another partition of the same IDE drive that the ISO is stored on.

Best regards: dlanor

O.O
Ur right...it doesnt work copying back to the hdd.... i has copied songs to my ipod like this and i presumed you could do it to hdd...

actually i had burned uLE and some other apps to a dvd along with some mp3's.... i was using mp3se to play the songs off the dvd...

then i decided to just dump the thing to my hdd... and set hdloader as my default boot app and run uLE from there when i needed....

it worked copying to the ipod from the hdl image....apparantly like u said it doesnt copy back to another partition..

[Torch]

one more thing i noticed when i tried hdl image to hdd.... if you have set a wallpaper for uLE thats located on the hdd, then it shows the hdd module loading as soon as it starts...and when you open the CDFS it shows the actual DVD contents...not the ISO... the normal HDD is accessible in the filebrowser though...you cant access the hdl image contents at all once you start uLE image from hdl with a wallpaper on hdd...

[zabolyx]

A few things...

So far it has never been done... ULE from HDL Partition to a normal partition... I tried... don't work.... at least I tried back with 3.41 something or other... I used that to make an installer for the exploit...

And for transfering files with the PC.... using winhiip... it is advised to not use the main windows drive for storage of ISO files... this will severly limit your transfer speed... with the paging file, registry read and writes, and the constant running of the restore files... I could only get about 2-3 MB/s sustained transfers... use a slave drive on the 1st IDE channel and then use one of the secondary or USB drives channels... I usually swap out my DVD cooker...

Also note: Transferring large ISO files on the HDD will make your drive very hot.... almost hot enough to blister the skin (well pretty damn hot)... I usually toss a 80mm fan on top of the PS2 HDD while transfering files.... raised buy 2 bolts to hole it up about 1/2 inch (1.5 cm)... keeps her nice and cool.

[dlanor]

one more thing i noticed when i tried hdl image to hdd.... if you have set a wallpaper for uLE thats located on the hdd, then it shows the hdd module loading as soon as it starts...and when you open the CDFS it shows the actual DVD contents...not the ISO... the normal HDD is accessible in the filebrowser though...you cant access the hdl image contents at all once you start uLE image from hdl with a wallpaper on hdd...
Hmmm...
At first I was going to pass this post as just another interesting but unimportant side note, but then I realized what you are truly saying here, and it may be of huge importance, if it really works that way.

Let me clarify what I mean by that:

So far it has never been possible to regain full control over all devices after booting uLE from HDLoader. Something always fails, and usually it's either access to normal HDD partitions, or access to CD/DVD. But you say that both are accessible when booting the way you describe, with a skin stored on an HDD partition being specified in the CNF file. The only difference that should make is that the HDD drivers get loaded a bit earlier than otherwise, but perhaps that makes HDLoader behave differently, as it intervenes in module loading of all programs it launches...

Please doublecheck your results, to see if uLE really works properly when booted that way, and I'll make some experiments of this too. If it does work out, then you've done us all a great service by discovering it.

Also, if it does work out, I'll want a copy of your CNF file, to make sure I see all factors that may have influenced this result.

Edit:
False alarm! :(
This turned out to be one more of those attempts that come close but don't hit the spot. Nearly everything seems to work correctly when uLE is started this way, but if it is then used to launch a new instance of HDLoader, then that HDL instance is incapable of launching any games or other programs. Every attempt to do so results in 'black screen of death'. This has happened in previously reported 'successful' launches of uLE by HDL too, so it was to be expected.

Best regards: dlanor

[E P]

Edit:
False alarm! :(
This turned out to be one more of those attempts that come close but don't hit the spot. Nearly everything seems to work correctly when uLE is started this way, but if it is then used to launch a new instance of HDLoader, then that HDL instance is incapable of launching any games or other programs. Every attempt to do so results in 'black screen of death'. This has happened in previously reported 'successful' launches of uLE by HDL too, so it was to be expected.

Yeah, there doesn't appear to be anyway to break out of the cdvd driver or whatever hook is in place. I didn't try it myself but I know it's something you really want to get working.:( I don't think any loader can do a full circle the way most users would like. It is just one of those things that users still sit and wonder about.:chinscrat

[Torch]

Hmmm...
But you say that both are accessible when booting the way you describe, with a skin stored on an HDD partition being specified in the CNF file. The only difference that should make is that the HDD drivers get loaded a bit earlier than otherwise, but perhaps that makes HDLoader behave differently, as it intervenes in module loading of all programs it launches...


No no both dont work...my sentence phrasing wasnt very good...

1) Boot uLE Image from HDL = CDFS: shows contents of image...but hdd0 doesnt work...usual problem we all have..

2) Boot uLE Image from HDL !!!WITH WALLPAPER on HDD!!! = CDFS: shows the physical DVD disc contents... and hdd0 partition works normally...
effectively booting uLE from HDL with wallpaper on HDD is the same as booting uLE direct from disc.

[dlanor]

2) Boot uLE Image from HDL !!!WITH WALLPAPER on HDD!!! = CDFS: shows the physical DVD disc contents... and hdd0 partition works normally...
effectively booting uLE from HDL with wallpaper on HDD is the same as booting uLE direct from disc.
No. Unfortunately it's not quite the same.

Like I said before, *ALMOST* everything seems to work right when uLE is started your way, but there is one important thing wrong with it. This is the fact that if you use it launch HDLoader again, then HDL will be unable to launch any installed games, instead freezing on a black screen at such attempt.

This error is probably caused by some remnant of the older HDL instance, which has somehow remained resident in IOP memory despite the IOP reset commanded by uLE. It is well known that HDL has components that interfere with proper IOP reset of games, making it nearly impossible to clean out HDL from memory completely. (As yet none have succeeded, without full PS2 reset.)

Best regards: dlanor

[Torch]

i got an idea...something you might have tried already before...but anyway here goes...

Launche uLE again from uLE after mode 3 launch from HDL.
Notice that in cases where the mode 3 (kill hdl after launch is set) for games that require it...after the game is launched, if the game has another executable which can be launched from the game menu, like a demo game or something..the demo game almost always never works.

Now i dunno jack about ps2 programming but from my experience with PC apps im presuming when mode 3 is set, HLD acts like a "loader" that u have for PC apps and patches the elf of the game in memory or its IOP or whatever. Notice when you transfer games from PC the transfer app always asks for the elf file directly to launch the game ?? not the system.cnf, so its not booted as if its a disk in the drive...more like HDL executing the game elf directly and patching it in memory so that it finds its files on HDD.

It probably has the IOP patched only for the elf that it launched itself..

So..what you could try is...
Enable mode 3 for the uLE image...
Run uLE through HDL..
The from uLE launch uLE AGAIN (from another location like mc0 just to be safe).
Im guessing the IOP should be clean now cos of mode3 effective only for the first uLE launched by HDL instance..

Now pray that lanching HDL from the 2nd uLE works properly...

Im n00B so just a logical guess...id try it but dont have time right now..

[E P]

Thetest read this (http://www.ps2-scene.org/forums/showpost.php?p=261313&postcount=16) old message for your answer.:)

[Torch]

Well atleast the wallpaper thing lets ppl use uLE normally for some quick work, launching straight from HDL without DVDROM or HDD0 problems...only we still cant launch HDL again..

[Torch]

just a guess...but...can you like dump the IOP section in the ps2's memory straight out of the ram by reading raw memory addresses (presuming you know where the IOP resides in memory)...this should be done by first launching uLE directly..then launch HDL...the next time you launch uLE by what ever means (in our case through HDL), check if a memory dump exists, if so just ignore what ever is already in the ram and just overwrite the memory with the dump...so the IOP should be forcefully reset...thus bypassing whatever lock HDL has on the API functions of the IOP...

all this presuming the IOP is stored in regular "accessible by memory address ram"

this is how trainers work right ? patch an instruction or value in memory...except that here we read the orignal value first and restore it later, instead of patching with our own value like a trainer.

[dlanor]

just a guess...but...can you like dump the IOP section in the ps2's memory straight out of the ram by reading raw memory addresses (presuming you know where the IOP resides in memory)...this should be done by first launching uLE directly..then launch HDL...
So you suggest that the ELF launcher dump a couple of megabytes to a file at each launch, just on the off chance that it might be wanted later for HDL re-launch compatibility. Is that it ?

If so, forget about it. To me such HDL compatibility is not at all important, and I'll certainly not cripple the program in that way, just to cater for the abnormal IOP treatment of HDL.

In any case, your entire reasoning fails because of the asumption that the dump made would be 'clean' of any HDL 'infection'. But that's not going to be the case for someone who boots HDL and uses it to launch uLE. The IOP RAM will already be 'infected' when uLE first sees it, and there's nothing it can do to change that.


the next time you launch uLE by what ever means (in our case through HDL), check if a memory dump exists, if so just ignore what ever is already in the ram and just overwrite the memory with the dump...so the IOP should be forcefully reset...thus bypassing whatever lock HDL has on the API functions of the IOP...
Using the main processor to modify IOP memory contents is a viable option, but it has many complications that I doubt you see clearly.


all this presuming the IOP is stored in regular "accessible by memory address ram"
Perhaps I'm reading you wrong here, but you seem to believe that the IOP is just some software system, as you ask if it's 'stored' normally. But the IOP is in fact a separate processor, with hardware different from the main processor, which is known as EE. So the IOP is not 'stored' anywhere in memory.

But the RAM used by the IOP is another matter of course, and that is accessible in the memory map of the EE as well. Tampering with it should be possible, though hardly safe...


this is how trainers work right ? patch an instruction or value in memory...except that here we read the orignal value first and restore it later, instead of patching with our own value like a trainer.
Doing this to one instruction at a time is one thing, especially if cheaters do it by a routine running in IOP space, as that guarantees that the IOP is not simultaneously accessing the patched area.

But letting one processor (the EE) completely replace the RAM content for another (the IOP), while both processors are running in parallel, and with the second one running software (HDL drivers) that actively defend against tampering, well that's an entirely different matter.

That can only be done safely by someone knowing exactly how those HDL routines work, as well as all other IOP routines that may be co-resident. And with such detailed knowledge this problem would already have been solved long ago, and by more normal means.

Best regards: dlanor

[Torch]

In any case, your entire reasoning fails because of the asumption that the dump made would be 'clean' of any HDL 'infection'.

I mentioned that the dump be made only when uLE is booted directly...you even quoted that sentence... :P
And since you cant tell whether it was booted throught HDL..the whole process should be optional...

So users can make a dump only if they want to..(when they know they've booted uLE directly)

All my references to IOP i meant the IOP's memory ofcourse..

Suppose you boot uLE in the exact same way each time, from the same bootdisc or whatever...the PS2's memory (or atleast the IOP's bit of the memory) should remain the same for each boot right ?

i mean its not like a comp where there are many things that may or may not occur in the same order when its booted and might mix up the memory so that its different each time you boot.

If atleast the IOP bit of the memory is gonna be the same for an identical boot method each time, the the dump can even be a one time process 9provided u boot the same way)...And it might not be several megabytes...(possibly actually check and verify its size ?????)

Since the IOP memory is accesible to programs running in the EE, it is possible theoritically...

[Torch]

and yes i see the complications it will imply..but ull never kno unless u try it.

i guess it would just crash the system cos of things running in the IOP...

Unless there is something like window's suspend process function to freeze the execution of instructions in the IOP...then once the dump is restored immediately force an IOP reset through API again..

Then again the IOP reset API will want to clean up and will crash...

[Torch]

what we need is one of these buggers who make pirated PS2 games that work online with DNAS...like we get in SE Asia...

They should be sufficiently skilled in RISC asm to take apart HDL....