unofficial LaunchELF v4.42

[dlanor]

I did test that and it worked for me. I shall try again.

I assumed that you had tested it, but sometimes a fluke can make it work in one test though it fails in others, and differing system environments can also affect results here.

Youre not trying to do anything in the root HOST folder are you?

No, of course not. I'm working two levels below the root. Didn't you see that from the path string I used ?

I should probably do some better error checking because it will not work properly there.

Obviously, and in fact I really should disallow such commands at that level in LaunchELF, so I've just added that to my TODO list.
("Block LaunchELF write access commands in 'elflist.txt' root dir.")

But as I stated above, I wasn't working there.

Anyway test again in a subfolder of the HOST root directory.

That's what I did, and I have repeated this test many times.
With RadHostClient v1.5 it always works, and with v1.6 it always fails.

Best regards: dlanor

[radad1]

New RadHostClient 1.7 with support for the write, delete and rename.

A last minute change introduced the bug dlanor found. Should be fixed now.

[cmal1492]

dlanor, thanks for the lengthly explanation, it is the same type of suggestions I would make if someone was having a problem with a flash cart (clean contacts, verify data integrity etc ~ which is exactly what I did after I initially got errors, attempt to verify the hardware before blaming/wondering about the software).

If I switch off to an older version, things work fine off that 64MB card with no complaints, so to me that is the simplest solution as this card has never given me cause to beleive data was being corrupted (files I download off it are exactly the same hex-wise to the origional ~esp. ones that give the error~, every game I have ever saved to it has survived). Also note that even though they figured out magicgate for the 64MB card, not every PS2 game is capable of using it (noteably, The Bouncer and Jak X combat racing wont work with mine) so its possible that some of the functionality found in those games card access is crippled in the Max cards, although it could very well be something else like the card in its final death throws (although I find that hard to beleive as this one has seen fairly minimal use, it was the first thing I thought too so I backed up the data from it immediately with uL to HDD).

Did 3.47 make any changes that should effect its behavior for me; it seems to be working much better on that plausibly bad card... I get maybe 1 in 20 fails, always when its sat still for awhile or before its done calculating the free space.

edit:/ for the heck of it I uploaded the uncompressed uL 3.47 to the boot/boot.elf for dev1 (it takes alot longer to boot) on the 64MB card (c'mon, its got the room to have it uncompressed) and I have not been able to get it to say "not an elf" but instead it will black screen on occasion. I can even switch between sms1.6r3 and uL 3.47 flawlessly (so long as I dont browse to the elf too fast or waaaay to slow)

[dlanor]

dlanor, thanks for the lengthly explanation, it is the same type of suggestions I would make if someone was having a problem with a flash cart (clean contacts, verify data integrity etc ~ which is exactly what I did after I initially got errors, attempt to verify the hardware before blaming/wondering about the software).

And yet you still neglected the one thing I asked you for:
A report on how the same version of LaunchELF works for you with a normal 8MB MC.

If I switch off to an older version, things work fine off that 64MB card with no complaints,

So v3.45, v3.44, etc, all work problem free on the same card ?
But v3.46 fails badly, and v3.47 fails only slightly (as mentioned later in your post).

Please understand that most of the elf loading code has been completely untouched for a VERY long time. It is identical in all those versions. The only difference in v3.46 (and v3.47) is that I edited the makefile for the loader, so that this loads to a different address in EE RAM. I didn't edit the source file at all. All routines that access MC in all the versions I mentioned above are also completely IDENTICAL.

Another thing to consider is that no-one else has reported similar problems, and many people use Max Memory cards without problems, for the same versions of LaunchELF that you consider bugged. I myself use two 32MB MCs from Datel, and EP has a 64MB MC, presumably same type as yours. Yet even he has not mentioned any problem of the kind you describe, though he too complains about how slow it is.

----- snip ----- re: why you don't suspect your 64MB MC
I understand your reasoning, but I can't agree with it. Other people use similar stuff with same versions and don't see these errors. The difference must be due to something at your end. Either your PS2, or the MC, or the validity of the files you put on it (fresh unpack from healthy ZIP, like I said earlier ?).

The only thing missing for a complete picture of your problems is a report on how similar operations work for you with a normal 8MB MC. If that fails the same way, then the 64MB MC may be OK, but your PS2 is probably not... But if an 8MB MC works perfectly for you, I think it proves that the 64MB MC is responsible for the errors.

Did 3.47 make any changes that should effect its behavior for me;

None.

The total set of changes from v3.46 to v3.47 was to erase one unwanted statement and to modify one delay loop test. Both in the early part of LaunchELF's initialization after bootup. No other code was changed.

it seems to be working much better on that plausibly bad card... I get maybe 1 in 20 fails, always when its sat still for awhile or before its done calculating the free space.

For this sort of thing even 1 in 20 is a huge amount.

As for that long 'free space' calculation delay, I've only heard of it from EP before (who also has a 64MB MC). With my own 32MB cards that delay is less than half a second, so I can never browse to an ELF fast enough to launch it before that operation completes.

edit:/ for the heck of it I uploaded the uncompressed uL 3.47 to the boot/boot.elf for dev1 (it takes alot longer to boot) on the 64MB card (c'mon, its got the room to have it uncompressed) and I have not been able to get it to say "not an elf" but instead it will black screen on occasion.

It's the same thing really. 'Not an ELF' means the ELF header data was corrupted when read from MC, while 'black screen' means that the program code of the ELF was corrupted when loaded from MC. Same type of corruption for similar kinds of MC access, just affecting different data blocks.

If corruption is less frequent now (for unknown reasons), then it makes sense that you get less 'Not an ELF' warnings, as the ELF header is very small compared to the total size of a program, so there is less chance of 'hitting' that small part with random corruption. But if the corruption is very frequent, then you'll get that warning all the time, as you reported before...

I can even switch between sms1.6r3 and uL 3.47 flawlessly (so long as I dont browse to the elf too fast or waaaay to slow)

I don't understand what you mean. How can 'slowness' be a cause for hardware to malfunction... If that is indeed the case, then that hardware is either broken or badly designed.

I'm sorry I can't be more helpful, but I really don't see what I can do.
You report the last two versions as being very different, in something that they use completely identical code for. To me that makes no sense, so I can't do anything sensible about it.

Best regards: dlanor

[E P]

Another thing to consider is that no-one else has reported similar problems, and many people use Max Memory cards without problems, for the same versions of LaunchELF that you consider bugged. I myself use two 32MB MCs from Datel, and EP has a 64MB MC, presumably same type as yours. Yet even he has not mentioned any problem of the kind you describe, though he too complains about how slow it is.

Ok, sorry I've haven't been using that 64MB card to slow for my tastes. It takes like 3 times longer to boot the exploit with it so I quickly grew tired of it. The last version I used with it was v3.42.

I finally got my other 8MB card fixed I had 1.2MB lost to corruption since early last year. Using the X-port to delete saves, was most likely what caused the corruption. Anyway the card is back in order again after a format and I restored all its 49 backups from the ps2 hdd. So after I do a little more testing I should be able to verify that the mc backup routine is a true success.

As for the 64MB card I'll do some checking on it real soon. The card gets the "this is not elf" when trying to run an ELF from the card without letting it finish checking the free space remaining. I know I mentioned it before but that's the only time I have ever seen that occur.

[dlanor]

Ok, sorry I've haven't been using that 64MB card to slow for my tastes. It takes like 3 times longer to boot the exploit with it so I quickly grew tired of it. The last version I used with it was v3.42.

I quite understand. From what I've heard about it, I'd never consider buying one of those myself, since it is clearly too slow for practical use.

Also, I am beginning to suspect that the design of that MC is not only inefficient, but also flawed. Not only do the strange test results of 'cmal1492' indicate this, but I found another alarming report on a similar subject (unrelated to LaunchELF). Here's a link to that post: http://psx-scene.com/forums/showthread.php?t=44387 (Warning to those with a 64 MB memory card with HDloader on it)

I finally got my other 8MB card fixed I had 1.2MB lost to corruption since early last year. Using the X-port to delete saves, was most likely what caused the corruption. Anyway the card is back in order again after a format and I restored all its 49 backups from the ps2 hdd. So after I do a little more testing I should be able to verify that the mc backup routine is a true success.

Good. This is the kind of massive testing we need, though it's very time consuming to do.

As for the 64MB card I'll do some checking on it real soon. The card gets the "this is not elf" when trying to run an ELF from the card without letting it finish checking the free space remaining. I know I mentioned it before but that's the only time I have ever seen that occur.

Yes I know, and yet cmal1492 says he gets it all the time with v3.46, but NOT with v3.47, which uses IDENTICAL code for all MC access.

I just don't get it...

Best regards: dlanor

[E P]

I quite understand. From what I've heard about it, I'd never consider buying one of those myself, since it is clearly too slow for practical use.

In regards to the slowness, it may also have something to do with my ps2 trying to read the DVD driver on the card on boot. Sill it takes like 2 seconds for LaunchELF to calculate the free space. Normal cards display the free space almost immediately. Performance wise I'm not too sure as I haven't used it too much yet.

Also, I am beginning to suspect that the design of that MC is not only inefficient, but also flawed. Not only do the strange test results of 'cmal1492' indicate this, but I found another alarming report on a similar subject (unrelated to LaunchELF). Here's a link to that post: http://psx-scene.com/forums/showthread.php?t=44387 (Warning to those with a 64 MB memory card with HDloader on it)

I don't know I still haven't heard a whole lot about the card. I'll reserve my final judgment until I start seeing some problems for myself. Another issue that may become more of a problem is the fact that a lot of places no longer sell the 32MB ones and now only carry the larger 64MB one. BestBuy first comes to mind as they only sell the 16MB and 64MB Max Memory cards.

Good. This is the kind of massive testing we need, though it's very time consuming to do.

Yeah it will take some time. I don't think I'll check all 49 saves maybe just a random sample. I did check the attributes on saves that were different from most saves and they were correctly kept intact.

Yes I know, and yet cmal1492 says he gets it all the time with v3.46, but NOT with v3.47, which uses IDENTICAL code for all MC access.

I just don't get it...

I haven't experienced that problem in particular but I haven't tested v3.46 only v3.47 so far.

Edit:
Ok @cmal1492
1. I mapped BOOT.ELF v3.47 to a button and ran it at different times without issue perhaps 20 times or so.
2. I did get a few lockups using the fileBrowser to run the ELF though. Got the "This file isn't ELF" quite a few times even after waiting for the free space to show. It would either lock up the second time or execute the ELF. Not a good sign but I did see this before. Perhaps I can do tests to see if I can find a way to resolve this issue.

Edit2:
Ok, I took out this piece of code in filer.c

if(!strncmp(path, "mc", 2)){
	mcGetInfo(path[2]-'0', 0, NULL, &mcfreeSpace, NULL);
}

I can't get the "This file isn't ELF" with the FileBrowser and no lockups yet so it's the get free space that appears to be doing it with the larger card. I want to keep that functionality in there though. Decisions.. decisions... Hopefully dlanor or I can come up with something. Wait doesn't that 'mcSync' command need to be called after 'mcGetInfo'? I don't see it there.

[zabolyx]

Make a switch in the menu maybe..... I was wanting one of these big a$$ cards... but with the probs listed... doesn't seem worth it....

I've been doing some not so great testing (for MCPaste)... and all have worked so far... not been checking the attributes... but copying and seeing if the programs can still read them....

should we make a list of the working ones or only worry about it if it doesn't work....

[E P]

Make a switch in the menu maybe..... I was wanting one of these big a$$ cards... but with the probs listed... doesn't seem worth it....

Well I think I fixed that one issue with the mc free space. Although it now takes longer to look at the memory card with the fileBrowser. Fixing the lockup is a big deal though. All I did was change this:

if(!strncmp(path, "mc", 2)){
	mcGetInfo(path[2]-'0', 0, NULL, &mcfreeSpace, NULL);
}

to this:

if(!strncmp(path, "mc", 2)){
	mcGetInfo(path[2]-'0', 0, NULL, &mcfreeSpace, NULL);
	mcSync(0, NULL, &ret);
}

I've been doing some not so great testing (for MCPaste)... and all have worked so far... not been checking the attributes... but copying and seeing if the programs can still read them....

should we make a list of the working ones or only worry about it if it doesn't work....

The non working ones most likely as there are a lot of working ones on my end.

[dlanor]

In regards to the slowness, it may also have something to do with my ps2 trying to read the DVD driver on the card on boot. Sill it takes like 2 seconds for LaunchELF to calculate the free space. Normal cards display the free space almost immediately. Performance wise I'm not too sure as I haven't used it too much yet.

Let's hope that the total corruption some people mention only happens to a small percentage of the units. The slowness in itself is bad enough though. I find it hard to accept that the size difference between 32MB and 64MB should cause such a huge difference in speed.

I don't know I still haven't heard a whole lot about the card. I'll reserve my final judgment until I start seeing some problems for myself. Another issue that may become more of a problem is the fact that a lot of places no longer sell the 32MB ones and now only carry the larger 64MB one. BestBuy first comes to mind as they only sell the 16MB and 64MB Max Memory cards.

For the present, yes. But if the case histories we've heard about failures are in fact representative of most 64MB units, then that will have to change. Either Datel will have to go back to the 32MB design, or significantly improve the 64MB design.

Yeah it will take some time. I don't think I'll check all 49 saves maybe just a random sample. I did check the attributes on saves that were different from most saves and they were correctly kept intact.

I think the attrFile word will be ok for all saves, but we must also ensure (as best we can) that tricky games can't tell the difference between originals and restored backups by other means too. Of course, if they do we might not be able to do much about it, but at least we could warn users about those games (if any ).

----- snip ----- re: some tests for the 'Not an ELF' problem

Ok, I took out this piece of code in filer.c

if(!strncmp(path, "mc", 2)){
	mcGetInfo(path[2]-'0', 0, NULL, &mcfreeSpace, NULL);
}

I can't get the "This file isn't ELF" with the FileBrowser and no lockups yet so it's the get free space that appears to be doing it with the larger card. I want to keep that functionality in there though. Decisions.. decisions... Hopefully dlanor or I can come up with something. Wait doesn't that 'mcSync' command need to be called after 'mcGetInfo'? I don't see it there.

I think you've found the bug, and it's interesting to note that it has been with us 'forever'.

That mcGetInfo call (line 1776 in filer.c of v3.47) is identical to one in the original source that was the start of our uLaunchELF project (line 1362 in filer.c of v3.41 by Mirakichi). We just never noticed the lack of an mcSync call there, because it seemed to work well on all normal MCs. Apparently the normal delays between reading folder data and trying to access its contents were sufficient to prevent the problem from affecting anything, until the superslow 64MB MCs appeared...

I will at once prepare a new release with this bugfix (adding mcSync I mean), and in preparing this I will also make a quick scan for any other mcXxxx calls that may have neglected proper use of mcSync.

Best regards: dlanor