PS2 FMCB/FHDB v1.9 series release thread

[unseen]

What parameters are stored in endvdpl.irx? (128 bytes)
This was the cause of the "DVD player is not set up" message.

 

[sp193]

It stands for ENable DVD PLayback (ENDVDPL.IRX). It contains nothing, and just serves as a mechanism for enabling the ability to read DVD Video discs, which would be otherwise disabled by default.

Older versions of FMCB worked differently, as they were always built with a KELF flagged as a DVD player. However, doing that is not only semantically incorrect, but it would be rejected by DEX consoles.

 

[unseen]

If I set the inner browser to force OFF, and have a disc loaded, there is no way to exit any app without ESR to start up?

 

[TnA]

Sorry, but your question is a bit unclear. What do you mean?

Would you mind elaborating more on what you intend to do, or what is not working?

 

[unseen]

OSDSYS_Inner_Browser is a parameter which controls the way FMCB boots into OSD. Can be set to boot into Browser or not.
If you set not to, than every time you exit an application and there is a disc inserted, it will start ESR automatically. You are basically unable to exit to main menu without ejecting the disc. Maybe I missed some setting that prevents this.

 

[TnA]

There is also an OSDSYS_Skip_disc-function...

Btw.: I do know, how every single function is named and what it does, looool... I suggested those names for the strings.

 

[jolek]

I still don't understand what we want to achieve?
It's a normal thing that when the ESR patched disk is inserted e.g. ESR (even when you'll exit app) will launch.
When you'll have org game inside and you'll exit an app, org game will boot.
When you'll have DVD-Video inside and you'll exit an app, DVD-player will boot.

So it's normal, console is design that way to automatically boots discs.
Not only from start, but also when you exit an app.

When you'll launch an app (e.g. OPL, wLe) and you're in it, ESR, DVD-player, org game will not launch.

"Go to Browser" in FMCB\FHDB configurator is a different thing.
Some apps are meant to exit into OSDSYS, some don't, that's why there is "AUTO" settings for that.
If you prefer to go into Browser after exiting an app select "Force ON", if not select "Force OFF".

"Ship Sony Boot" in FMCB\FHDB configurator will always kicks you into PS2 Browser when the disc is inserted.
No matter if you've "Go to Browser" set to "Force OFF" or "Force ON".
Do simple test (without setting "Ship Sony Boot" ON):
insert the disc when you're in FMCB\FHDB browser, disc will automatically launch.
insert the disk when you're in PS2 Browser, disc will not automatically launch,
letting you to chose between e.g. browsing MC.

 

[sp193]

What app did you exit from? If you quit from an app that invokes Exit(), the normal behaviour would be to go to the browser.
If your app is one of those that involves ExecOSD() with no arguments, loads rom0:OSDSYS with LoadExecPS2 etc, then there is no way for the system to tell whether it was a cold boot or an app that quit.

 

[sp193]

FMCB/FHDB v1.966 released!

This update is to add better support for some (2.5") HDDs that require their heads to be parked before power is disconnected, otherwise their lifespan could be significantly reduced.
This update also fields a new build of LaunchELF, which also has modifications to better support those (2.5") HDDs. And USBHDFSD was replaced, so that we can delete/rename files properly.

The problem with USBHDFSD was a mistake that was introduced in late 2014, which caused its cache to become dysfunctional. While no data will be lost because of that, it sometimes resulted in very poor performance. Due to the more recent modifications to USBHDFSD, this performance problem is now limited to filesystem operations, which is why deleting & renaming files were the most badly affected by it.

Changelog for FMCB/FHDB:

• Added system shutdown function. The corresponding special menu item is "POWEROFF".
• Renamed "Reload Configuration" to "Restart System".
• Updated USBHDFSD & HDD modules to reduce wear on some 2.5" HDDs (USB and the PS2 HDD) when the PS2 is shut down. The User should use the shutdown function to shut down these devices properly.
• Updated USBHDFSD to fix the performance problem from 2014.
• (FHDB) Recompiled FSCK with new HDD modules.
• Recovery mode will now once again be entered as long as mass:/RESCUE.ELF is found. The START+R1 combo can still be used to force it (FMCB/FHDB will make an infinite number of attempts to boot it).

Changelog for the installer:

• Updated LaunchELF.
• Updated USBHDFSD & HDD modules to reduce wear on some 2.5" HDDs (USB and the PS2 HDD) when the PS2 is shut down. The User should use the shutdown function to shut down these devices properly.
• Updated USBHDFSD to fix the performance problem from 2014.

New Limitations:

• FMCB/FHDB will issue the SCSI UNIT STOP command to USB devices connected when a disc is booted via fastboot, to prolong the lifespan of those (2.5") HDDs that require proper shutdown.
  However, this will not happen if the disc is booted from the browser because the disc boot process is not conducted by FMCB/FHDB.
• Some 2.5" HDDs (used within USB enclosures of as the PS2 HDD) require their heads to be parked in software. Otherwise, their lifespans could be reduced significantly when power is removed and they attempt an emergency park.
  The User should use the shutdown function to shut down the PS2 and these devices properly.
  Please note that despite pressing the power button of an expansion bay PS2 will cause new (built in 2019) software to park the internal HDD's heads, this is presently not supported by FHDB because of the Browser.
  The exact capabilities of the software, depend on the software itself.

Recovery Mode
Recovery mode allows you to boot a single ELF, in case your FMCB/FHDB installation was rendered unusable.
Place the ELF as mass:/RESCUE.ELF and FMCB/FHDB will boot it when you switch on the PlayStation 2.

If you are having difficulties with getting RESCUE.ELF to be booted, press and hold START+R1. FMCB/FHDB will make an infinite number of attempts to boot the file.

Downloads/links
FMCB, FHDB & FMCBInstaller project page (downloads at bottom): https://sites.google.com/view/ysai187/home/projects/fmcbfhdb
psx-place FMCB/FHDB resource thread: http://www.psx-place.com/resources/free-memory-card-boot-fmcb-free-harddisk-drive-boot-fhdb.712/

 

[jolek]

I'm not sure if this is right, but in your archive there is "LAUNCHELF.CNF" in "...INSTALL/BOOT/" with:
TV_mode = 4

I think It'll be good if this file will be deleted from this folder.

BTW thanks for the new build, I'll test it in free time.

 

[tinostar91]

Yeah, bit of a problem to have progressive scan by default. Also, another problem in LaunchElf that I've noticed is that poweroff briefly enables network adapter during shutdown (fan spins up). This doesn't happen in OSDSYS.

 

[sp193]

I'm not sure if this is right, but in your archive there is "LAUNCHELF.CNF" in "...INSTALL/BOOT/" with:
TV_mode = 4

I think It'll be good if this file will be deleted from this folder.

Thanks. I have updated the bundle.

Also, another problem in LaunchElf that I've noticed is that poweroff briefly enables network adapter during shutdown (fan spins up). This doesn't happen in OSDSYS.

It's because I need to switch off the DEV9 part to be able to shut down the PS2. But I need to have access to the dev9x device for that. However, loading the dev9 module will also initialize DEV9 if it was not already initialized...
On the other hand, the HDD Browser always loads the dev9 module, so it will always shut it down too.

You also can get such a deadlock by activating the HDD unit and then going to FMCB. It becomes impossible to reset & shut down the PS2 at that point.

 

[unseen]

It is best to exit a game, (L1+R1+L2+R2+Select+Start) and perform a poweroff? I have a rather new 80GB HDD anyway, (I modified a 70004 console as per Automan) so it probably does the parking while spinning off.

 

[sp193]

It is best to exit a game, (L1+R1+L2+R2+Select+Start) and perform a poweroff? I have a rather new 80GB HDD anyway, (I modified a 70004 console as per Automan)

Since you have a SCPH-70000 series and I don't suppose the power button works like it does on a expansion-bay PS2, you should do a proper power-off from software. Pressing the power button will cause a hard reset, I suppose?

You can do one of the following:

• Press the shutdown IGR combo. OPL is actually still running and will have you covered.
  
• Return to OPL main UI and use the shut down option from the menu.
• Boot into other updated software, like a new version of LaunchELF and shut down from there.

Please take note that because the capabilities of the software depends on itself, that means that only new software that was designed to work properly with these HDDs, can be trusted to shut down the HDD properly.

If you had an expansion bay PS2, then it becomes simpler because pressing the power button would have triggered the proper shutdown sequence by the running software, but again it is also dependent on what the running software can do.

so it probably does the parking while spinning off.

You can refer to your HDD manual to see if it differentiates between a software-initiated park and an emergency park.

Somehow, all the 2.5" HDDs I have used with the PS2, have actually been doing emergency parks. The sound is quite noticeable. You can also get the same sound if you forced a laptop to shut down.

 

[unseen]

Pressing the power button will cause a hard reset, I suppose?

Yes it resets the console. Long press powers it off.
What about 3.5'' HDD's?

 

[sp193]

What about 3.5'' HDD's?

As there seems to be no standard for this, you should consult the HDD's manual. But what I think is that this mainly concerns 2.5" HDDs.

 

[sandungas]

Btw, if i remember right that "improper shutdowns" are recorded in a counter as part of the S.M.A.R.T. data of the hdd
So for testing you can check how much you have now, then make some tests and check again

 

[TnA]

All of these additions and changes are PERFECTLY matching into the system!

I really like the fixes and that you implemented 'POWEROFF' as a call! I really like not being dependent on an external ELF for that!

(Btw.: You had pushed an external ELF earlier, which doesn't have the proper HDD-Shutdown. Could you add the changes to it as well, if it isn't too much work?)

It's sad that the first OSDSYS-Version(s) do not support the extended OSDSYS-Syntax (to change the color/shape/size/etc. of an OSD(SYS)-Item). If it would support it, the color of the Shutdown-Item could have been changed in the Standard-CNF.


On another note: 'RESCUE.ELF' was called 'recovery.elf' in some 1.9x-Versions, correct?


And the 'Recovery-Force' is interesting as well! I didn't even knew you implemented that, or I indeed forgot it!
Btw.: '(Force)Start + R1' = 'Start Recovery'...
Was that a decision based on that similaritily, or because it is unlikely that the users will accidentally press that combination?

Hm... Something similar (Start + R2, or whatever) for a 'TDB-Mode' would be interesting as well, but I suppose that's not going to happen for various reasons (even if most of it would be excluded into a file, separated from the Loader).


With all those changes, it could have been tagged '1.97' tho'.

 

[TnA]

So... I didn't really thought about the OSDSYS-Syntax.

We ARE already using it since a decade in the standard-CNF... Lol


@sp193 (and others)
What do you think about these small changes (they are solely CNF-related):

• Would you mind changing the 'Shutdown System' to i.e. 'red',
• 'Restart System' to yellow (or what you prefer)
• Link POWEROFF to LK1 of Digipad 'down' (perfect for those apps which can exit to Browser and can not properly shutdown the HDD) essentially giving those older apps a quite easy and secure workaround, to be able to use the new feature(s).

I did it similar (or the same way) in the FMCB/FHDB USB-Extension-Package (and I will update it, but that specific test-stick got broken, so I have to start over with some things from 'PoC3' on).


Granted... Anyone could add that on their own, but I think it might be a good idea for the install-package.

 

[TnA]

@sp193: Relating this post

Ooops, I forgot to reply here... Sorry!
~
It entirely depends on the kind of OSDSYS-Hack!

A function based on source (and doesn't need to be a 'visible' hack), usually is not so hard to make it compatible along different BOOT-ROM-Versions.


The biggest issue I see is, when someone tries to implement on of those more sophisticated manual OSDSYS-Hacks (mostly those which can be seen).

• As for %VER%... Well, I don't know if it is a global constant or variable, or if it is locally within the CNF-Parser... (with an exception trigger, if the CNF Parser reads '%VER%). Obviously this function (the version-submenu-hack) would not need to 'get in contact'/use the CNF-Parser... (but it still could get it from there, possibly)

Well, it definitely can get quite annoying, even for the supposedly 'small' features/additions. :-|

The addition of the POWEROFF-Call is a perfect example of this, just like %VER%!

It's technically not a real 'OSDSYS-Hack', because it doesn't patch the OSDSYS manually/directly. It doesn't add a new button or so... You know what I mean!

But it still adds a function to both 'stages' of user-interaction (Logo/Button-Launch and 'hacked OSDSYS') via a (I like to refer to it as) 'call' (i.e.: FASTBOOT, OSDSYS, OSDMENU, POWEROFF...)!

So that is a perfect example of a 'kind of' OSDSYS-Hack, which doesn't involve really patching the OSDSYS 'technically'!

The function-enhancements of these kinds have some benefits!

• They are usually compatible to all BOOT-ROM-Versions, because they already have full control about the Hardware once they are started... (i.e. like an ELF). The code which is started, however still musst be compatible with the hardware or the software it is interacting with.
• There is no need to track down the location of functions which are intended to be patched!
• No need to apply/know MIPS ASM to get them done, which makes it
• less likely for bugs to occur, based on faulty Opcodes!

But they are limited in regards, what could be done for with OSDSYS-patching (like the scrolling)!


In %VER%'s case, it probably replaces the %VER%-'Variable' (if it parses it from the config) with the version-number... So I suppose it is some code in the CNF-Parser?!
Only @sp193 could tell, because these sources are not open, but based on the old sources, that's a logical way IMO.

The 'more sophisticated OSDSYS-Hacks' I was referring to here (in the following quote), sadly are prone to cause issues like crashes or other things + the multiple BOOT-ROM-Versions sometimes need other values to search for, or other locations to patch, etc...

If it is the secondary and you are referring to the 'patterns' FMCB looks up and patches, yes indeed!
But they can be 'traced' (even via PS2Dis and I think IDA can be used for it as well)!

~

If I remember correctly, ffgriever dumped some cdvd-related RAM-Portions (CDVD-Registers?) and re-implemented it back manually. This in the beginning caused some troubles with various models, because some were using other 'patterns'/instructions/orders.

Regarding this:

Ooooh! The cause of this (probably) is the pointer-array overflowing. The function for this is... (I will edit the post later and add the name.)
The function could be moved to another memory-location and 1Item uses 17Byte (atleast in 1.8), if I remember correctly.

I will look up the function and post it tomorrow. I've got a lot to do for the next 9 hours...

...and...

I think I found it!
It's probably the struct 'osdsys_settings', which is overflowing into another region, once it grows too big (thus not allowing 256 or more items)... --> typedef struct {~} osdsys_settings;
Changing it's Memorylocation would 'fix' that '(non-)issue', I suppose!

I will add the OSD Hack-related functions I meant and which can be reused in a similar way to rebuild another 'sub-menu', once I find it.

I've got to take a nap. It's past 3AM here...

Have you tried moving the 'struct' (typedef struct {~} osdsys_settings; ) to another memory-location with a bit more space?
I think that would be sufficient, if '256' or '300' App-Links would be needed!

I love the POWEROFF-Call, really!
It is just perfect, because FMCB is so closely 'tied' to the PS2-System and -menu related stuff!


Btw.: I would still like to see atleast 'Shutdown System' in the OSDSYS being red, but it is your choice if the 'base/basic/core-install-package' will use it.