OPL with prototype game list cache

[Tupakaveli]

Are all of you including the time taken for the HDD to spin up?

Ah, I was launching it with wLE...

With a cold boot and launching from OSDSYS it takes ~20 seconds.

That's still a massive improvement

 

[TnA]

I meant since this: http://www.ps2-home.com/forum/viewtopic.php?f=90&t=6207

Oh, alright! Yes, indeed!

Anyway there wasn't this need before, to have very huge game-lists is a quite new trend after all.

Quite new? No! We already had some people using 1TB-HDDs in ~2008!
...and older HDDs are slower as well, so there ever was a kind of need for it, but due to the demand of it being quite low, there was no real reason to implement it and alot of other things where much more important before!

I'm curious to know the @sp193 opinion about it. If it really makes a noticeable difference in loading time it would be good to add an option in settings to specify where the file will be saved, i.e. these 3 options: hdd0:/+OPL, hdd0:/system-partition, mc?:/OPL.

Only tests can certainly answer this question. The function you propose here would need to find the +OPL-Partition in the first place to read the settings, which by that time could simply read the original cache-file...

Essentially, that proposal voids itself!
...or 'the snake bites her own tail'...

I've the "absolute" setup

Partition-wise, yes! But the ultimate setup would be an SSD!
​

Yes, I'm developing mind-reading powers

lol

Well, to have the +OPL partition at the beginning would be Always the best (you have, cfg, vmc, into it, to not talking about cover-art and screenshot!).
About it, I know people that enlarged the OPL partition when having the HDD almost full, and it don't seems to affect in a noticeable way the loading time of game CFGs and cover arts…

That's due to it simply adding a chunk at the end... The main-partition is still in the beginning... so adding that chunk shouldn't make a difference!

It don't power off when IGR. I access Ulaunchelf from Apps in OPL and the HDD spindown.

Ah! That makes sense!

For me it's a very good thing. For 2 resons:

1. If I'm leaving OPL to do something not related to the iHDD (like playing from USB with PS2ESDL, playing a DVD, etc...)

2. Even if I'm leaving i.e. for switching to another OPL version/HDLoader (or other applications that use the iHDD) it is better to restart the HDD modules with the new program (as we know it could make many differences).

Regarding '2.': Well, this can shorten the life-time of the HDD and would increase the load-up-time between the sessions.

Btw.: Why should it be 'better'? Do you think this might fix some issues which appear when a game isn't 'cold-booted'?
That MIGHT be true for some games, but I doubt it would fix everything. Maybe it doesn't even change anything...

Anyway I must thank you for this input, I'm going to try this:

Make a IGR, go to Ule (HDD will spin down), press square (my shortcut from Ule to OPL) and I bet that it would solve the "after IGR problems" in FC and SPPS

I am not so sure... It MIGHT make a difference but I doubt it to be the universal solution... But it is worth a test!

Btw.: FC=Force Close (?); SPPS=?

Tested OPNPS2LD-GAMELIST-3.ELF

I deleted the previous games.bin and generated a new one.

Everything seems good, ~12 second load time is amazing, thank you!

This 2Tb HDD is almost full, the partitions are set up as:

__mbr
__net
__system
__sysconf
__common
+OPL

Then the games. 1100 games, ~104 of which are larger than 4Gb so all up ~1210 partitions.



I sincerely hope it's the latter

THX for adding your partition-structure and for testing!

Are all of you including the time taken for the HDD to spin up?

I can't test it currently with the HDD (too less games installed) and the SSD would not be of use in these tests + has no spinup-times.

Yes, and that was not mentioned, but it was done because I think it is necessary.

I'm not sure if it is 'necessary' (for what exactly?), but it's certainly worth some tests.

But this game was known to have issues. It might have some problem related to uninitialized hardware, since letting the PS2LOGO program run first would magically solve things.
We might have to either patch the game or to initialize the SPU2 in the way it expects, since the game would be normally booted after PS2LOGO.

Did 'the real developer' (in quotes, because I am quoting @Grahf... It's NOT to discredit you or your skills of course...) @sp193 just confirmed, that he has a similar/the same suspicion about 'init' possibly being related to that issue?!?

No, the capabilities of a program are determined by the program itself. Usually, we don't share modules between programs, due to possible compatibility problems.

IMO he wasn't exactly clear in what he was asking!
I think he asks this due to the 'coldboot-start' needed for some games!

...and to be honest... When the HDD is initialized before, it MIGHT cause issues i.e. when the software which is about to be loaded doesn't 'like' the pre-initialized state, even tho' it should be able to re-init it!

That's however not due to 'shared modules', but possibly rather the init.
It also could be, that a software-part (for example one of the drivers, which are related to HDD-Support) doesn't expect it to be initialized before...

I doubt it'll change for the HDD OSD's case. Once you exceed the limits of the HDD.IRX cache, the cache becomes totally useless and cannot become any more useless.

Correct! But listen to an HDD, when the cache is full and becoming useless! On every scroll you hear multiple reads and jumps! The time the hardware needs for these physical movements (seeks, etc.) and reads is pretty much completely eliminated.

That leads me to conclude that an SSD could indeed yield quite a big improvement in that regard!

I am reporting back on this, once I got enough/alot of games on the SSD + HDD-OSD + make the games compatible with the HDD-OSD (HOSDSYS) via HDLGI (or HDLGU?)!

Now that you mentioned it, this might be the problem. Well, we cannot solve all problems.

Indeed!
Well, if it is we can simply tell the users to make sure that the partition is 'in the beginning' of the disc (or better at the logical beginning of APA).

I'm sure it's a plausible reason, because of how APA (unfortunately) works. If it's the 1100th partition, the poor thing must go through 1100 partitions to find the +OPL partition (or not). Anyway, since game settings are stored in +OPL, it needs to be accessed sooner or later.

Yes, that is exactly what I thought.

Well, we need someone which could test both cases (+OPL at the beginning and the same HDD with +OPL at the end), to verify if that assumption is true.

Nevertheless, it MIGHT still increase the speed, even if +OPL is 'at the end (of APA)', because as far as I remember OPL still reads small chuncks to get the game-ID, or does it do that solely when 'selecting' it and not on HDD-Startup?

But once you boot a game on another device, you won't go back to select another game for a while.

Except if you make a lot of test!

Even Sony does this, when you boot a disc-based game from the CD/DVD drive from the HDD browser.

I didn't even remember that (you see how long I haven't used discs on that system anymore? Lol)! Interesting!

If you're a developer, why would you have HDD set to AUTO and not boot games from it?

Hm??? I thought it would do that everywhere (after IGR and so on) but @Peppe90 cleared that up!

Even if you/anyone would not have had it set to 'AUTO', it would still require the HDD to be turned on and spun up...

As for the 'Why...': for example: Because 'that person' who has it set to 'Auto' wants to start a game from another device or just an app from OPL...

Some rather use OPL as their 'AIO-Central', also for starting Apps...


Btw.: An 'Apps-Config/Compatibility-Menu might be interesting as well... It could have a per-app-option if the HDD is shut down, or not...

This was an earlier patch, to put the HDD in STANDBY mode first, to prevent an emergency park by some HDDs when power is cut when DEV9 is shut down.

I know!
...and I am quite thankful for that, because it was just like pulling the power-connection during runtime before!

Oh no, it won't be just a few ms, since we're trying to reduce the 40s loading time observed by some people. It's not about the position of the partition on the HDD, but whether it's behind 1000 partitions or behind just 5.

I think saying that the logical position within APA (rather logical, than physical) is quite appropriate to describe it correctly. So... Not exactly the (physical) beginning of the HDD, but rather at the (logical) 'beginning'/start of APA.

Game CFGs are stored in +OPL and this will always be checked for, so it is impossible to avoid spending some time scanning for +OPL (even if it doesn't exist).

On another note: The medium which this cache belongs to, also should 'hold' it, or various issues could occur... Imagine someone with his MC going to a friend (both start their games from the same type of medium)...

Yes, that is true. Game title information is only 2 sectors per game and this is read after a list of games is generated. It also exists once for each title. So if you have 500 titles, then it will seek an additional 500 times. If each game took up 2 partitions (not always the case), we can say that it might represent a third of the seek time observed.

THX for the confirmation and additional informations!

So if @Tupakaveli always had to wait 50s, just scanning for the partitions (omiting this step) could reduce the wait by a third.. which is still quite some time. It would have been nice if this wasn't a problem though. Unless 30s is still tolerable.

For a 2TB-HDD? Certainly! Lol
But it's already faster, haha!
​

Btw.: So... The cache has these informations contained?
Game-ID, Game-Name, sectors/partition-name of the game?!?

It's sad, but this is only a problem because the cache within HDD.IRX does not work.
Otherwise, it would have helped with reducing the time taken to scan through the whole disk, at least once.

Awwww... That's really sad... :-|

Now to think about it, this might need some tweaking because we're back at this question: what happens when a user boots a program that uses the HDD unit?
In the case of FHDB, I think I chose to just leave the HDD unit on.

Yes, FHDB is a prime-example! It's even the most obvious example and I have not thought of it... *shame*

We can also choose to implement something like the HDDUNITPOWER setting that Sony uses, which is used to determine whether the HDD is put into IDLE mode (because only the NIC is required), the HDD & NIC are left on or if DEV9 should be shut down entirely.

I ought to remember that the discussion about that 'secure shutdown' of the HDD, included multiple approaches. Was this way mentioned as well?

But it isn't a solution.

Why do I have a similar sentence ("...not a 'fix'...") in mind?

Now that we will block further accesses to ATA before IGR, I'm not sure why you will have problems under specific conditions...

Like I mentioned in the upper part of this post: It could be in a 'state' (for example it is initialized, before the drivers are loaded), that might cause these issues if a game is not 'coldboot-started'.

But it is just an/one assumption based on the things we experience... An 'educated guess' might be the proper term(s) to describe that assumption/idea.

But if we can avoid it, the less options there are, the less choices the user must make.

Really?! I thought we should clutter the GUI with as many things as possible! :P

Nah, just kidding! I fully agree!
A choice should only be, where there is an advantage to the user, not were he/she 'has to' set it up, so that it works with his setup!

...and THX for all your confirmations!

Ah, I was launching it with wLE...

With a cold boot and launching from OSDSYS it takes ~20 seconds.

That's still a massive improvement

That's really impressive for a 2TB-HDD!
Imagine those, who autoboot to OPL and have the HDD set to 'Auto'!

Would you mind trying that as well?
I suppose it will be ~15seconds?

 

[sp193]

Only tests can certainly answer this question. The function you propose here would need to find the +OPL-Partition in the first place to read the settings, which by that time could simply read the original cache-file...

Essentially, that proposal voids itself!
...or 'the snake bites her own tail'...​

Anyway, OPL will locate +OPL, so it will end up looking for it as part of the boot process.​

Regarding '2.': Well, this can shorten the life-time of the HDD and would increase the load-up-time between the sessions.

A few extra seeks won't really do much though. The real reason why we want this feature, is to get rid of the annoying ~40s loading screen.

Btw.: Why should it be 'better'? Do you think this might fix some issues which appear when a game isn't 'cold-booted'?
That MIGHT be true for some games, but I doubt it would fix everything. Maybe it doesn't even change anything...

We use a copy of the standard ATA module, this is not a problem.

I am not so sure... It MIGHT make a difference but I doubt it to be the universal solution... But it is worth a test!

But even if it made a difference it won't conclude anything new.

I'm not sure if it is 'necessary' (for what exactly?), but it's certainly worth some tests.

https://github.com/ps2dev/ps2sdk/issues/85

it appears that some HDD manufacturers treat a simple cut to the HDD's power as an "emergency unload". However, it does not seem like ATA-4 (the ATA standard that the PS2 was originally designed for) describes a proper procedure for shutting down.

At ATA-7 (from 2005), the IDLE IMMEDIATE command with UNLOAD FEATURE was added. However, it is optional and there was still no description of whether HDDs really need this to be shut down correctly.

There does not seem to be a standard for this, hence the lack of official admin instructions. Basically, we have been slowly destroying some of our modern 2.5" HDDs because the old way of just cutting power causes mechanical stress.

I have added code for issuing STANDBY IMMEDIATE before the power to dev9 is cut. For USB devices, I have added a devctl() function for issuing the SCSI START STOP UNIT command to cause the HDD to park its heads, but this must be issued by the software.

Not shutting down the unused devices before booting a game will forfeit the opportunity for OPL to properly deactivate such HDDs.

Did 'the real developer' (in quotes, because I am quoting @Grahf... It's NOT to discredit you or your skills of course...) @sp193 just confirmed, that he has a similar/the same suspicion about 'init' possibly being related to that issue?!?

But in all seriousness, we have two choices here:

• Re-create the conditions that the game was developed to run off.
  
• Determine the problem and write a patch.

For the former, we can already do it by running PS2LOGO before the game. Under normal circumstances, PS2LOGO always runs before the game. But perhaps we can just find a direct to put the SPU2 in the right state, since Half Life already had sound issues back when OPL didn't even touch the SPU2.

This isn't like what was suggested in the other thread because it isn't about trying to work around a timing problem of some sort by inaccurately emulating speeds.

...and to be honest... When the HDD is initialized before, it MIGHT cause issues i.e. when the software which is about to be loaded doesn't 'like' the pre-initialized state, even tho' it should be able to re-init it!

That's however not due to 'shared modules', but possibly rather the init.
It also could be, that a software-part (for example one of the drivers, which are related to HDD-Support) doesn't expect it to be initialized before...

No, all DEV9 and ATAD modules will handle initialization correctly. If you had issues with a compatible adaptor, you should ask your manufacturer why they didn't make their adapters work like the original.
Seriously though, what you're thinking of, was a problem because the (then) new DEV9 & ATAD code couldn't work with non-compliant hardware.

That leads me to conclude that an SSD could indeed yield quite a big improvement in that regard!

Indeed, but the price per GB is still very steep, compared to what you can get with a HDD. It's also a limitation caused by bad software design, not that the HDD cannot do it.

Nevertheless, it MIGHT still increase the speed, even if +OPL is 'at the end (of APA)', because as far as I remember OPL still reads small chuncks to get the game-ID, or does it do that solely when 'selecting' it and not on HDD-Startup?

It will read title information after generating a game list.

Except if you make a lot of test!

Yes, but then your HDD still wouldn't matter if you didn't need it?

Even if you/anyone would not have had it set to 'AUTO', it would still require the HDD to be turned on and spun up...

If not set to AUTO and not started by the user, the HDD will not be activated.

As for the 'Why...': for example: Because 'that person' who has it set to 'Auto' wants to start a game from another device or just an app from OPL...

But that's fine too. The intent is to not keep the HDD on, when not required.

Btw.: An 'Apps-Config/Compatibility-Menu might be interesting as well... It could have a per-app-option if the HDD is shut down, or not...

That will be an exercise for other people.

Btw.: So... The cache has these informations contained?
Game-ID, Game-Name, sectors/partition-name of the game?!?

Yes: https://github.com/sp193/Open-PS2-Loader/blob/gamelistcache/include/hddsupport.h#L27

Yes, FHDB is a prime-example! It's even the most obvious example and I have not thought of it... *shame*

I went by memory, however. For all we know, I made it shut down DEV9 if the app was not booted from the HDD. Either way, a decision has to be made.

I ought to remember that the discussion about that 'secure shutdown' of the HDD, included multiple approaches. Was this way mentioned as well?

What "secure shutdown"? If you're referring to the risk we've been exposing some modern 2.5" HDDs to, it's not covered by Sony because the PS2 was designed for 3.5" HDDs from the early 2000s.

 

[Peppe90]

You once had a question regarding the Idle command. The Idle command was meant for power-management. We have this option to configure the Standby Timer of this function because it used to be that some people complained that the HDD would go to sleep and the game would crash.
But IMO, it should not have been a problem in the first place.

Understood. Anyway it never worked for me.

But this game was known to have issues. It might have some problem related to uninitialized hardware, since letting the PS2LOGO program run first would magically solve things.
We might have to either patch the game or to initialize the SPU2 in the way it expects, since the game would be normally booted after PS2LOGO.

This game is just perfect for me. I don't need to enable the Ps2 Logo or any other trick/MODEs or DMA settings. It happened only that time to have this weird problem. Probably it wasn't related to the program, maybe a coincidence, indeed I could repeat the problem a
couple times IGResetting. But after I power-off the Ps2, the problem did not show up anymore (and I was always using the same OPNPS2LD-GAMELIST-2

This might not be related to this feature, as I only cache the existence of games. As it is quite simple, it should either always work or not at all.
There are too many existing problems with OPL and the PS2SDK, unfortunately.

I thought you made OPNPS2LD-GAMELIST-3 for that bug. So the bug was this that you said:

"No, I was referring to a possibility that it might reject the game list and spend more time to generate a new one."

What happened to me is different. It wasn't rebuilding the list. The light blinked as usual then turned off leaving the OPL loading icon on screen forever (the HDD light turned-off, so it wasn't even trying to making the list).
Never happened a similar thing in 3 years of playing from HDD.
Btw I tried OPNPS2LD-GAMELIST-3 a couple times and the problem didn't happened (IGResetting from the same game). So maybe this problem was in some ways related to the OPNPS2LD-GAMELIST-2 bug.

Game CFGs are stored in +OPL and this will always be checked for, so it is impossible to avoid spending some time scanning for +OPL (even if it doesn't exist).

Indeed is was that simple. Thanks for letting me know

So if @Tupakaveli always had to wait 50s, just scanning for the partitions (omiting this step) could reduce the wait by a third.. which is still quite some time. It would have been nice if this wasn't a problem though. Unless 30s is still tolerable.

It's strange that his (@Tupakaveli) HDD takes more time, I mean, I have a 2tb HDD with +1,3tb already full (692gb free space) and it takes less than 5 secs. But actually the first 4,5 secs are required for the HDD to spin up. As soon as it make the first blink, the list appear, as I said before. It takes just a moment to read the games.bin file, I don't understand how it could make a difference, reading a list with more games.

Maybe his HDD is slower than my to spin-up ?
Maybe his OPL partition is behind many games ?
Or maybe when the HDD is full of partitions it just takes more time to spin up (?). Indeed even with Ulaunchelf (accessing HDD0) or other programs, if the HDD is huge and filled up, it seems to take more time to load the modules.
​

Now to think about it, this might need some tweaking because we're back at this question: what happens when a user boots a program that uses the HDD unit?
In the case of FHDB, I think I chose to just leave the HDD unit on.

Probably the HDD would spindown, then the other program will make it spinup normally I'll try it going to OPL from OPL apps page.

We can also choose to implement something like the HDDUNITPOWER setting that Sony uses, which is used to determine whether the HDD is put into IDLE mode (because only the NIC is required), the HDD & NIC are left on or if DEV9 should be shut down entirely

I think it's the best to sut down the DEV9 entirely.
About that I've a question: It's possible to play games via ETH without making the HDD spinning (or to turn off it after)??

But it isn't a solution. Now that we will block further accesses to ATA before IGR, I'm not sure why you will have problems under specific conditions...

I am not so sure... It MIGHT make a difference but I doubt it to be the universal solution... But it is worth a test!

Btw.: FC=Force Close (?); SPPS=?

I meant Ferrari Challenge and Shwaun Palmer's pro snowboarder. They are 2 games with problems after a IGR have been performed.

However I said a folishness. Something remains in the Ps2 memory after IGR or so… Reastarting the HDD doesn't make any difference to that obviously. Ferrari Challenge simply can't work after an IGR have been performed.​

But if we can avoid it, the less options there are, the less choices the user must make.

I understand. Perhaps it would be good to make an ELF, similar to the Ps2 Poweroff.elf, but for turning off the iHDD only. I would set the path to it in OPL apps and use it when it happens to play from USB

EDIT: nevermind. I know it can't be done with an elf…

 

[Peppe90]

https://github.com/ps2dev/ps2sdk/issues/85​

...What "secure shutdown"? If you're referring to the risk we've been exposing some modern 2.5" HDDs to, it's not covered by Sony because the PS2 was designed for 3.5" HDDs from the early 2000s.

About secure shutdown. I've Always noticed a thing that I thought was normal, but it makes makes me a little suspicious:

When I power-off the Ps2 (when the iHDD is on), sometimes it make a gentle noise, a progressive spindown, then the Ps2 completely power-off. Other times instead it makes a nasty "clack", like something is being violently detached, then the Ps2 power off.

With the new OPNPS2LD-GAMELIST-3 it seems to Always shutdown the HDD kindly (so far). But with older OPLs, the power-off.elf and the Ule power off it makes this bad noise almost every time.

 

[Peppe90]

About FHDB, I don't see what could be the problem. FHDB already shutdown the HDD when playing something from the optical drive. So it would be just to complete the thing

 

[sp193]

As part of some integrity checks, I was testing the IDLE and IDLE IMMEDATE commands, and to see what happens when I try to access the HDD after it transitions to STANDBY state (due to the standby timer reaching 0).
All functions seem to work, with my Seagate ST3802110A. The HDD will spin down after 5s, when the standby timer is set to 1.

The description of the IDLE and IDLE IMMEDIATE commands was not so clear at the ATA-4 specification, which was rectified in newer versions of the standard. These commands will never directly cause the HDD to spin down. IDLE can cause the HDD to spin down, as it programs the standby timer, which will cause the HDD to transition to STANDBY state when it expires. The description from the hdparam manual is clearer.

Through the checks, I also found that the Sony HDD Browser had a problem with disabling the standby timer if "NIC" is specified for HDDUNITPOWER by the title, preventing disks from entering STANDBY state. It was caused by them issuing the IDLE command with a standby timer value of 0.
This was changed in the PSBBN, whereby they issue IDLE IMMEDIATE instead, which will still allow the HDD to enter standby after 21 minutes and 15 seconds. I only checked the Japanese v1.00 release, however. But I doubt the v1.10 US release would have been different because Sony only added the IDLE IMMEDIATE command later on, at SDK release 2.5.

Understood. Anyway it never worked for me.

That being said, if the standby timer cannot be set via the IDLE command, it might be a problem with your SATA adaptor.

This game is just perfect for me. I don't need to enable the Ps2 Logo or any other trick/MODEs or DMA settings. It happened only that time to have this weird problem. Probably it wasn't related to the program, maybe a coincidence, indeed I could repeat the problem a
couple times IGResetting. But after I power-off the Ps2, the problem did not show up anymore (and I was always using the same OPNPS2LD-GAMELIST-2

Okay, but I'm telling you that the game is known to have that problem. It's been like that for years, although I don't think I have personally witnessed it either.

Btw I tried OPNPS2LD-GAMELIST-3 a couple times and the problem didn't happened (IGResetting from the same game). So maybe this problem was in some ways related to the OPNPS2LD-GAMELIST-2 bug.

No, it's not possible.

Or maybe when the HDD is full of partitions it just takes more time to spin up (?). Indeed even with Ulaunchelf (accessing HDD0) or other programs, if the HDD is huge and filled up, it seems to take more time to load the modules.

LaunchELF will also scan through the whole HDD for the partition list. It doesn't have a separate message for indicating that it is reading the HDD.​

Probably the HDD would spindown, then the other program will make it spinup normally I'll try it going to OPL from OPL apps page.

I meant to say that we need to cover that use case. As of now, it will happen as you say.

I think it's the best to sut down the DEV9 entirely.

I think we can do better than that. I will not create a new UI, but we can add a new option to do what Sony did. Of course, we will also opt to shut down DEV9 entirely by default.

About that I've a question: It's possible to play games via ETH without making the HDD spinning (or to turn off it after)??

It's already done.

I understand. Perhaps it would be good to make an ELF, similar to the Ps2 Poweroff.elf, but for turning off the iHDD only. I would set the path to it in OPL apps and use it when it happens to play from USB

I meant to write that we can design a system that offers a good user experience, without needing the user to be bothered with more settings. Gamers just want to play games with minimum hassle, that has been the premise of consoles.
Like when it comes to newer consoles or even your PC, do you tell the OS when to switch off the HDD?

About secure shutdown.

It's just about shutting down the HDD, not actually "secure" or not. (nothing mentioned "secure" anyway)

I've Always noticed a thing that I thought was normal, but it makes makes me a little suspicious:

When I power-off the Ps2 (when the iHDD is on), sometimes it make a gentle noise, a progressive spindown, then the Ps2 completely power-off. Other times instead it makes a nasty "clack", like something is being violently detached, then the Ps2 power off.

With the new OPNPS2LD-GAMELIST-3 it seems to Always shutdown the HDD kindly (so far). But with older OPLs, the power-off.elf and the Ule power off it makes this bad noise almost every time.

That was the purpose of the series of commits for adding that new feature. Software must be updated to be built with the newest SDK revision and to issue the USBHDFSD devctl() command, to properly shut down supported devices.
Existing software will continue to do what they have always been doing.

Related commits:
https://github.com/ps2dev/ps2sdk/commit/f0e62ac75758a6e9ad35dd3863667f59c60f1d6b
https://github.com/ps2dev/ps2sdk/commit/97b53a15bbf715c5cede81fb4230796a64701ede

 

[Peppe90]

That being said, if the standby timer cannot be set via the IDLE command, it might be a problem with your SATA adaptor.

I'm using the maxdiypower sata boar at the moment. What problem could be?? It shut down perfectly the HDD with the OPL power off function (and power-off function of the Others programs too, works). It's just the HDD spin down option that doesn't work. It doesn't worked with the Gamestar NA too.
Btw I wanted to use that function when switching from HDD to other devices (like usb) to not leave the HDD spinning down uselessly. But I know the spindown function is enabled only when playing from the iHDD, therefore I don't need it at all

Okay, but I'm telling you that the game is known to have that problem. It's been like that for years, although I don't think I have personally witnessed it either.

Actually this game problem is to make a sound buzz when in game, I experienced that problem when using the Gamestar NA and older OPL builds (I just needed MDMA 0 to solve). Now I can play in UDMA 4 without any MODE (and without the Ps2 Logo) and the game just plays fine.

Btw I agree, it seems it can happen to the game to not be perfectly stable some time (maybe due to the UDMA 4 speed).

No, it's not possible.

So the probably I'll experience this issue with the new build too. It worries me a little 'cause I have to hard-power-off the Ps2 when it happens… Btw it happens only IGResetting from the damned Ferrari Challenge Trofeo Pirelli.

​

I meant to say that we need to cover that use case. As of now, it will happen as you say.

​

Well on which apps could you go that use internal HDD?? OPL?? You're already there. If you access an app stored within the iHDD it wouldn't spinoff (or yes??)
However at last you need to return to OPL for a safer shuting off, based on what you said to @TnA ​

I think we can do better than that. I will not create a new UI, but we can add a new option to do what Sony did. Of course, we will also opt to shut down DEV9 entirely by default.

It's already done.

Really!? I'll try it right away

I meant to write that we can design a system that offers a good user experience, without needing the user to be bothered with more settings. Gamers just want to play games with minimum hassle, that has been the premise of consoles.
Like when it comes to newer consoles or even your PC, do you tell the OS when to switch off the HDD?

With me you're breaking through an open door

That was the purpose of the series of commits for adding that new feature. Software must be updated to be built with the newest SDK revision and to issue the USBHDFSD devctl() command, to properly shut down supported devices.
Existing software will continue to do what they have always been doing.

Related commits:
https://github.com/ps2dev/ps2sdk/commit/f0e62ac75758a6e9ad35dd3863667f59c60f1d6b
https://github.com/ps2dev/ps2sdk/commit/97b53a15bbf715c5cede81fb4230796a64701ede

So that way you will make Power-off.ELF up to date with the OPL power-off function, I understand well??

About that I have something to ask you, correlated to what you said to @TnA here:

There does not seem to be a standard for this, hence the lack of official admin instructions. Basically, we have been slowly destroying some of our modern 2.5" HDDs because the old way of just cutting power causes mechanical stress.

I have added code for issuing STANDBY IMMEDIATE before the power to dev9 is cut. For USB devices, I have added a devctl() function for issuing the SCSI START STOP UNIT command to cause the HDD to park its heads, but this must be issued by the software.

Not shutting down the unused devices before booting a game will forfeit the opportunity for OPL to properly deactivate such HDDs.

Above all the last phrase. i.e. when IGResetting the HDD never spindown. So pretend that I have the IGR <not set> After IGR I go to ULE (the HDD is still pinning up), then I have just to power-off the Ps2. It would be safer to return to OPL for shuting-off the console??

In any case it's not a problem at all now, being OPL operative in a few seconds even with the HDD set to AUTO

You could make the IGR to spindown the HDD if the path is not set to OPL... But I think there's no need for it.

IMHO It's convenient to have the IGR path to OPL, then after the IGR you can leave the program with the exit function or via apps page.


In conclusion I think you could already add this feature to the official releases. You have to choose how the auto-refresh would be by default.

I mean, with the auto-refresh on by default, OPL will work as it always did, just scanning for the games at every boot. So people that may not be aware of the new feature, won't have problems (it's a good thing to use the auto-refresh also for who have a small HDD, 80gb or so and has the habit to install/uninstall games frequently).
It's good for all tastes

Or you can just make a parallel release for now.

 

[Tupakaveli]

Actually this game problem is to make a sound buzz when in game, I experienced that problem when using the Gamestar NA and older OPL builds (I just needed MDMA 0 to solve). Now I can play in UDMA 4 without any MODE (and without the Ps2 Logo) and the game just plays fine.

I tested this game, it's not just the buzz sound during the game. There's also a problem with the BGM during the first loading screen and the menu. The BGM starts playing then drops out.

Using different DMA modes I could get the BGM to play for longer before it dropped out but it always did eventually. Also tried different Mode combinations but couldn't fix it completely.

I don't use PS2 Logo either.

 

[Peppe90]

I tested this game, it's not just the buzz sound during the game. There's also a problem with the BGM during the first loading screen and the menu. The BGM starts playing then drops out.

Using different DMA modes I could get the BGM to play for longer before it dropped out but it always did eventually. Also tried different Mode combinations but couldn't fix it completely.

I don't use PS2 Logo either.

Indeed I had like a dejavu… I seem to remeber now that this problem already happened to me when setting the game with OPL 0.9.3 (years ago).

Btw now it happened to me just that one time, and I've booted the game an incalculable number of times.

Anyway it's not a problem, if it will happen again I'll diminish the DMA setting

 

[Peppe90]

I tested this game, it's not just the buzz sound during the game. There's also a problem with the BGM during the first loading screen and the menu. The BGM starts playing then drops out.

Changing topic... it works for you the HDD spindown option in OPL settings with the maxdiypower sata board??

 

[sp193]

I'm using the maxdiypower sata boar at the moment. What problem could be?? It shut down perfectly the HDD with the OPL power off function (and power-off function of the Others programs too, works). It's just the HDD spin down option that doesn't work. It doesn't worked with the Gamestar NA too.
Btw I wanted to use that function when switching from HDD to other devices (like usb) to not leave the HDD spinning down uselessly. But I know the spindown function is enabled only when playing from the iHDD, therefore I don't need it at all

Uh. I'm not sure if it's because you are expecting something else.

So to clarify: there exists a few power states of the HDD: Active, idle, standby and sleep. Active consumes the most power as the HDD is on, while sleep is lowest power state.
By the ATA specification, we can specify after how long of inactivity, should the HDD enter standby state, with the standby timer. There are also a few commands for setting this timer, but that isn't important here. The standard did not really specify what the HDD will really do in each state, but standby state could mean that the HDD spins down.

So what this "spindown" setting of OPL does, is to set the standby timer with the specified amount of time. In OPL, the range of values is from 0 to 20, whereby each unit corresponds to 60s. If you set it to 1, then the HDD will only spin down after 60s if it encounters no activity.
Setting it to 20 means it will spin down only after 1200s of no activity. No activity = no commands issued for the period of time.

What you wanted was something different: the HDD should be switched off immediately, if it is not required.

So the probably I'll experience this issue with the new build too. It worries me a little 'cause I have to hard-power-off the Ps2 when it happens… Btw it happens only IGResetting from the damned Ferrari Challenge Trofeo Pirelli.

Yes, it may come back.

Well on which apps could you go that use internal HDD?? OPL?? You're already there. If you access an app stored within the iHDD it wouldn't spinoff (or yes??)

Since APP mode is considered its own mode, booting an app from it will cause the HDD unit to be switched off. So it probably doesn't even work now.
​

So that way you will make Power-off.ELF up to date with the OPL power-off function, I understand well??

Actually, I added a new function into FMCB/FHDB. So that ELF will be deprecated.

However at last you need to return to OPL for a safer shuting off, based on what you said to @TnA

Above all the last phrase. i.e. when IGResetting the HDD never spindown. So pretend that I have the IGR <not set> After IGR I go to ULE (the HDD is still pinning up), then I have just to power-off the Ps2. It would be safer to return to OPL for shuting-off the console??

LaunchELF can do the same job, as long as you got a new version.

I mean, with the auto-refresh on by default, OPL will work as it always did, just scanning for the games at every boot. So people that may not be aware of the new feature, won't have problems (it's a good thing to use the auto-refresh also for who have a small HDD, 80gb or so and has the habit to install/uninstall games frequently).
It's good for all tastes

Auto refresh is disabled (regardless of the setting) for the HDD unit because the HDD cannot be hot-plugged, so it doesn't make much sense to have it enabled. In fact, the refresh button was also previously disabled for it, so I made a number of other changes to make it work in the current way.

(But why the different tune now? After we've come so far too. )

Or you can just make a parallel release for now.

We'll leave this to the OPL team to decide.

 

[Peppe90]

Uh. I'm not sure if it's because you are expecting something else.

So to clarify: there exists a few power states of the HDD: Active, idle, standby and sleep. Active consumes the most power as the HDD is on, while sleep is lowest power state.
By the ATA specification, we can specify after how long of inactivity, should the HDD enter standby state, with the standby timer. There are also a few commands for setting this timer, but that isn't important here. The standard did not really specify what the HDD will really do in each state, but standby state could mean that the HDD spins down.

So what this "spindown" setting of OPL does, is to set the standby timer with the specified amount of time. In OPL, the range of values is from 0 to 20, whereby each unit corresponds to 60s. If you set it to 1, then the HDD will only spin down after 60s if it encounters no activity.
Setting it to 20 means it will spin down only after 1200s of no activity. No activity = no commands issued for the period of time.

What you wanted was something different: the HDD should be switched off immediately, if it is not required.

Thank you for the clarification but I knew how it works. My HDD seems to never spindown.
I tried setting the spindown to 1 minute (other values too), then leaving the HDD without reading (i.e. in FFX, I'm sure it doesn't read anything, the music loop in Ps2 ram). I tried playing games from other devices, and the HDD remains spinning up for hours…

Anyway it's not a problem, it was just a curiosity to know why I can't make it to work.

Yes, it may come back.

Indeed… It depends on games. So far: Ferrari Challenge Trofeo Pirelli and Ace Combat The unsung War.

After the IGR, OPL shows up the loading icon. Then after the usual 5 secs it freezes a little (at this point normally the game list would appear) for about 1 second, then it (the loading icon) starts turning again going on forever (HDD light is OFF).

The thing that worries me a little is that I need to hard-power-off the Ps2 (and the HDD is still spinning).

I'll make further tests to find out possible other games that have this problem.

It can be correlated to the "after igr issues" that some games have. Probably is the same thing 'causing OPL to can't read the games.bin after IGResetting from certain games.

Since APP mode is considered its own mode, booting an app from it will cause the HDD unit to be switched off. So it probably doesn't even work now.

It could be a good thing in case of booting HDLoader (patched with the DMA selector) 'cause it set the DMA (you could change via hot-Keys) at the HDD spinup. So maybe it would result in some problems (HDLoader would fail to correctly set the DMA) if the HDD is already spinning??
​

Actually, I added a new function into FMCB/FHDB. So that ELF will be deprecated...

...LaunchELF can do the same job, as long as you got a new version.

Maybe it's time to update my 3 years old custom FMCB '^^

Auto refresh is disabled (regardless of the setting) for the HDD unit because the HDD cannot be hot-plugged, so it doesn't make much sense to have it enabled. In fact, the refresh button was also previously disabled for it, so I made a number of other changes to make it work in the current way.

(But why the different tune now? After we've come so far too. )

in fact you're right, there's just need to know that you have to press the SELECT button when adding/deleting a game.

 

[Tupakaveli]

That's really impressive for a 2TB-HDD!
Imagine those, who autoboot to OPL and have the HDD set to 'Auto'!

Would you mind trying that as well?
I suppose it will be ~15seconds?

With OPNPS2LD-GAMELIST-3.ELF set as FMCB auto E1 Launch Key it's the same, ~20 seconds.

That's just how long it takes for OPL to init, HDD to spin up and games.bin to be read.

I guess if I used FHDB it would be ~12 seconds since the HDD would spin up at boot but I prefer to use FMCB.

 

[sp193]

New changes for today:

• Added setting for disabling the game list cache. It is disabled by default.
• Moved the reading of HDD game title information earlier, so that the HDD will not need to scan across its platters twice.
• Refactored APPS support so that it becomes easier to set up. Each APP may also have its own CFG.
• The HDD will now be put in IDLE state, if it is not required.
• Enabled the refresh function for the APPS page. So the user will not be blocked from using the feature if it was started up before the device that contains the desired content.

For the new APPS feature, applications can be put within their own folders, within the APPS folders on each supported device. For example, on a USB disk:

APPS/
  LaunchELF/
    title.cfg
    BOOT.ELF
  SMS/
    title.cfg
    SMS.ELF

title.cfg only requires two lines for now. For example:

title=LaunchELF v4.50
boot=BOOT.ELF

Download: https://www.sendspace.com/file/yo14h5

then leaving the HDD without reading (i.e. in FFX, I'm sure it doesn't read anything, the music loop in Ps2 ram). I tried playing games from other devices, and the HDD remains spinning up for hours…

Unless it really did nothing much, I find it a little hard to believe it will not read any extra data because the EE only has 32MB of memory, which is also required for graphics.

It could be a good thing in case of booting HDLoader (patched with the DMA selector) 'cause it set the DMA (you could change via hot-Keys) at the HDD spinup. So maybe it would result in some problems (HDLoader would fail to correctly set the DMA) if the HDD is already spinning??​

Actually, commands are issued to the HDD all the time. Changing the transfer mode is also done with a command.

Indeed… It depends on games. So far: Ferrari Challenge Trofeo Pirelli and Ace Combat The unsung War.

Is it a very common occurrence? If I just went to the menu and did IGR, will it happen?
​

Maybe it's time to update my 3 years old custom FMCB '^^

Welcome to 2019.

 

[ted209]

Amazing work - thank you!

While you're making improvements to the game list, I have a related request. Could you change the behaviour of the SMB game list so that if OPL fails to connect (e.g. Error 300) then the "Start device" action remains on that screen?

Currently the actions change to: run,game settings, refresh, etc (whether or not it successfully connects) so if you get a connection error, you have to go into settings>network config>reconnect to attempt another connection.

 

[Peppe90]

I noticed that the "exit" function doesn't power-off the HDD. So it could be a good option to acces other apps without letting the HDD to spindown (as @TnA requested).

Unless it really did nothing much, I find it a little hard to believe it will not read any extra data because the EE only has 32MB of memory, which is also required for graphics.

Playing FFX from DVD you can remove the DVD and the music keep playing forever. It freezes if you are moving when finding a casual encounter or accessing the menu. But if you stay still (there's not even need to put the game on pause, but I tried that way too), the game doesn't seems to read nothing.
I'll do furter tests with other games too anyway.

Actually, commands are issued to the HDD all the time. Changing the transfer mode is also done with a command.

I was referring to this:



Btw was just an assumption. So HDLoader can correctly set the DMA even if the HDD is already spinning??

Is it a very common occurrence? If I just went to the menu and did IGR, will it happen?

It happens every time with those games, booting OPL from the MC. I have other tests in mind (but too little time!!)

Hopefully if we figured out what is causing this, you can solve all related problems in a once
​

Welcome to 2019.

I don't changed it 'cause it works like a charm ...About Wlaunchelf, at the end you managed to solve the corruption when copy to mass??

 

[Peppe90]

With OPNPS2LD-GAMELIST-3.ELF set as FMCB auto E1 Launch Key it's the same, ~20 seconds.

That's just how long it takes for OPL to init, HDD to spin up and games.bin to be read.

I guess if I used FHDB it would be ~12 seconds since the HDD would spin up at boot but I prefer to use FMCB.

It would takes the remaining 8 secs for the Ps2 to boot

 

[sp193]

I forgot to undo some changes that I needed for debugging. Please use the new file: https://www.sendspace.com/file/vpnnae

While you're making improvements to the game list, I have a related request. Could you change the behaviour of the SMB game list so that if OPL fails to connect (e.g. Error 300) then the "Start device" action remains on that screen?

Sorry, but it is not so simple. When you activate ETH mode, the button actually changes immediately, while the connection takes place in the background.
So if I wanted to change the button back to "Start Device", I would need to call moduleUpdateMenu() from the IO thread. But it might not be safe to do it and I will not commit resources to determine what will happen, make the change and to debug it. There are just too many other problems that also need to be solved at the moment.

I noticed that the "exit" function doesn't power-off the HDD. So it could be a good option to acces other apps without letting the HDD to spindown (as @TnA requested).

Don't you find it strange that you have a HDD unit, leave it on AUTO but don't use it for most of your tasks?
If you wish to add the option, you're free to do it.

Playing FFX from DVD you can remove the DVD and the music keep playing forever. It freezes if you are moving when finding a casual encounter or accessing the menu. But if you stay still (there's not even need to put the game on pause, but I tried that way too), the game doesn't seems to read nothing.

I see. But it doesn't mean the game didn't try to read data.
Either way, it is working, to the best of my knowledge. How I tested it, was with a specialized program that issued the IDLE command (standby timer = 5s) and waited for 10s. At the 5th second, I could hear the spindown.

I was referring to this:

View attachment 14312

Btw was just an assumption. So HDLoader can correctly set the DMA even if the HDD is already spinning??

Yes. In fact, this is done by the ATAD module when a device is accepted by the software. So whenever you quit OPL and boot something else, the HDD will be issued the new settings again.

It happens every time with those games, booting OPL from the MC. I have other tests in mind (but too little time!!)

To cut the chase, I was planning to try it out and debug it with the equipment I have. But only because I think it sticks out like a sore thumb.
The changes these few days have been very costly for me already though.

About Wlaunchelf, at the end you managed to solve the corruption when copy to mass??

The USBHDFSD issue was fixed in late October. Which is why I have been telling everybody to throw away software made between June 8th and 27th October.

Well, at least it seems to be. I haven't had issues ever soon. But I usually don't use my PS2.

Then just yesterday or so, a 5-year old bug was found, which was causing poor performance. It should not affect data, however.

 

[Tupakaveli]

It would takes the remaining 8 secs for the Ps2 to boot

I'm only timing how long it takes for OPL to load. I start timing from after I launch the ELF and the video mode on my TV changes (before the logo is loaded), I'm not including the console boot time.