pstwo slim + HDConnect/HDCombo - LaunchELF cannot read HDD0. Is this normal?

[izsim]

I search the entire forum and found 1 post from dianor saying that no one in the development team for uLaunchELF has a slim ps2 + hdd setup in response to a user who could not get his hdd(via HDConnect) detected on his pstwo in LaunchELF, hence i reckoned HDD support for pstwo is not in the works any time soon.

Purpose of this thread is to find out if anyone who owns a slim ps2 + HDD setup and is able to get LaunchELF to detect their HDD and read/write from it?

Just like to confirm if LaunchELF->Filebrowser->HDD0: is not compatible with slim ps2 + HDConnect/HDCombo for now or hear from anyone who has managed to get LaunchELF to detect their HDD on their slim.

[izsim]

Anyone?

[dlanor]

As far as I know (by hearsay only), safe access to HDD on a 'slim PStwo' requires a patched driver, to which I have no access. I have seen various claims about functional driver patches, but in most cases those claims have also been accompanied by complaints of 'lost data', 'automatic reformat', etc.

In those cicumstances there isn't much I can do about it. I will not add a patched driver (potentially unsafe) to LaunchELF, and release it without testing its use on the target hardware myself. And I can't do that when I don't have such hardware.

If someone else will develop and debug a patched driver that is verified as working safely, by several others too, then I'll consider making a 'slim PStwo' version of LaunchELF based on that driver. But I can't develop such a driver myself as I lack the hardware to test it.

Best regards: dlanor

[E P]

If someone else will develop and debug a patched driver that is verified as working safely, by several others too, then I'll consider making a 'slim PStwo' version of LaunchELF based on that driver. But I can't develop such a driver myself as I lack the hardware to test it.
Yeah same here. Perhaps sincro can test it out for us. This thread (http://www.ps2-scene.org/forums/showthread.php?t=44555) has some information on the hack with LaunchELF v3.49.

My compiled ps2 hdd.irx driver (7C66B51C CRC32) was changed from:
offset 294: 0500 4010 0000 0000 1000 A28F 0000 0000 0500 4010

to:
offset 294: 0000 0000 0000 0000 1000 A28F 0000 0000 0500 0010

I would like to know what exactly changed there. Maybe it could be changed at the source code level. I don't like supporting binary hacking especially when the source exists.

[lonwern]

I would like to know what exactly changed there. Maybe it could be changed at the source code level. I don't like supporting binary hacking especially when the source exists.
The way apply this changed to the source:

(ps2sdksrc\iop\hdd\apa\src\misc.c)
original:
int getIlinkID(u8 *idbuf)
{
int err=0;

memset(idbuf, 0, 32);
if(CdReadIlinkID(idbuf, &err))
if(err==0)
return 0;
dprintf1("*****d: Error: cannot get ilink id\n");
return -EIO;
}

changed:
int getIlinkID(u8 *idbuf)
{
int err=0;

memset(idbuf, 0, 32);
CdReadIlinkID(idbuf, &err)
return 0;
}

[izsim]

Yeah same here. Perhaps sincro can test it out for us. This thread (http://www.ps2-scene.org/forums/showthread.php?t=44555) has some information on the hack with LaunchELF v3.49.

My compiled ps2 hdd.irx driver (7C66B51C CRC32) was changed from:
offset 294: 0500 4010 0000 0000 1000 A28F 0000 0000 0500 4010

to:
offset 294: 0000 0000 0000 0000 1000 A28F 0000 0000 0500 0010

I would like to know what exactly changed there. Maybe it could be changed at the source code level. I don't like supporting binary hacking especially when the source exists.


Purpose of my thread is just to find out if uLaunchELF has pstwo hd support implemented, did not expect the developers to respond personally:)

I do agree that robustness is more impt than implementing unstable new features. uLaunchELF is the best "ps2 os" presently and will only get better. Thanks for the tireless efforts and time spent on uLaunchELF.

[dlanor]

Purpose of my thread is just to find out if uLaunchELF has pstwo hd support implemented, did not expect the developers to respond personally:)
Ah, but from our point of view that was inevitable. After all, the 'slim PStwo' models are now the only kind of PS2 still in production, and while the latest of those models are doomed never to have any HDD (HDD controller removed), there are tons of users with earlier 'slim' models that need HDCombo compatibility in LaunchELF. We have recognized this all along, we just couldn't do much about it.

I do agree that robustness is more impt than implementing unstable new features.
Indeed, but thanks to lonwern we now have a source-level patch available, which does open new possibilities. We can now include this in our patches for PS2SDK, so that each remake of PS2SDK produces two different *****D IRXs. The normal one == *****d.irx, as usual, but the new one == *****d_slim_PStwo.irx, for use only with those PS2 models.

NB: Due to an old feud between PS2-Scene and another site, it has become impossible to mention that PS2SDK IRX module by name in these forums. I find this kind of censorship regrettable in ALL circumstances, but doubly so when it interferes with important communication about programming. Those 5-asterisk sequences above should in fact be the five characters p+s+2+h+d.

I regard this patch as a stopgap measure, to be replaced ASAP by an improved patch, as the present one obviously eliminates the ability to test for some possible errors, which is never a good thing. It would be better to redesign the code so that the same error test will work correctly on a slim PStwo as well. Then we could perhaps even use the same IRX for all models.

But until then the simple patch shown may be satisfactory for 'slim' users, depending on how it comes out in real testing by the users.

uLaunchELF is the best "ps2 os" presently and will only get better. Thanks for the tireless efforts and time spent on uLaunchELF.
Thanks for the praise, but remember that our motivation isn't entirely unselfish. Most of the changes implemented were made because we wanted them ourselves... ;)

I am going to implement the 'slim PStwo' patch mentioned above, and plan to release a test binary here later today. If this is verified as working by some users of the 'slim PStwo' models, then I will add it into the proper release package as well, but clearly marked as 'experimental' and with separate binaries from the normal ELFs, so that they retain full capabilities for error checking.

Best regards: dlanor

[E P]

I regard this patch as a stopgap measure, to be replaced ASAP by an improved patch, as the present one obviously eliminates the ability to test for some possible errors, which is never a good thing. It would be better to redesign the code so that the same error test will work correctly on a slim PStwo as well. Then we could perhaps even use the same IRX for all models.

Exactly what I was thinking and now with the source changes from lonwern maybe it's possible to bridge the gap. Then we would only have to worry about one version of uLaunchELF.

[dlanor]

Exactly what I was thinking and now with the source changes from lonwern maybe it's possible to bridge the gap. Then we would only have to worry about one version of uLaunchELF.
Yes, and we may be able to achieve this even with the current primitive method (just skipping that error test for a slim PStwo). We need a quick and certain way of testing which model of PS2 the program is running on to make the program adapt this behaviour 'on the fly'. Exactly how to do it depends mainly on whether or not the test can be done in IOP space or not, and how fast it is.

1: If the test can be done in IOP space, and is very fast, then we can include it directly in the 'getIlinkID' function.

2: If the test can be done in IOP space, but is not very fast, then we can include it in the initialization routines for the driver, setting some flag variable to show the model. Then we test that variable in the 'getIlinkID' function.

3: If the test requires EE space, then we simply use it in the main program, to determine whether to load a normal hdd IRX or the one patched for slim PStwo.

Both cases 1 and 2 have the advantage that the IRX used will solve the problem internally, making it suitable for use with any program that needs this kind of compatibility. Another advantage of this is that we don't have to add an extra IRX module to PS2SDK, but can simply modify the existing one.

Case 3 means that we have to keep using two separate IRXs, though it too allows us to reduce the LaunchELF release to a common set of ELFs for all console models. (At cost of increasing the code size, with the extra IRX.)

Best regards: dlanor

[izsim]

Thanks for the praise, but remember that our motivation isn't entirely unselfish. Most of the changes implemented were made because we wanted them ourselves... ;)



Even though your moltivation isn't entirely unselfish, people like you, EP and lonwern who spend time and effort without vested interest/profit to come up with free apps for others who do not have the ability to do it(like me) deserves commendation:)

[E P]

Yes, and we may be able to achieve this even with the current primitive method (just skipping that error test for a slim PStwo). We need a quick and certain way of testing which model of PS2 the program is running on to make the program adapt this behaviour 'on the fly'. Exactly how to do it depends mainly on whether or not the test can be done in IOP space or not, and how fast it is.
Cases one and two appear far more practical but maybe it would be better discussed with those at ps2dev. Perhaps this thread (http://forums.ps2dev.org/viewtopic.php?t=4928) as it's more in their best interests overall.:)

Besides what most likely would happen is everyone that had a slim hd mod would be only be using uLaunchELF. I just wonder what might happen with conflicting hdd.irx modules and the slim PS2.