Bug reports

[TnA]

As I understand it this is just because the behavior we want,

Indeed, that is true.
It's a workaround on newer models, since they don't behave as older models, like you said.

to simply have the program go to the main FMCB menu and stay there, is impossible to achieve with the newer bios of slim PS2 consoles when there is a disc in the tray. So FMCB must 'duck' into the Sony Browser in order to prevent launching of the disc.

I don't think, it is impossible, but 'only' very hard to do/accomplish (maybe even not).
Getting the highest compatibility to all models, ever was a big goal and it works very good in almost all cases, but I know that this function (OSD-Skip-Disc) was one of the, if not THE most annoying issue ever, while FMCB was developed and it never was really 'cured' 100%ly.

We could try to make the behavior consistent by making FMCB 'duck' in the same way on older consoles too, even though it is not needed there. But if we do that we have to expect an outcry of protest from users who have those consoles and hate the new behavior.

I would hate that, too.
What should the 'inner Browser'-Function, should be there for then?
In my meaning, it is an issue which needs entire fixing done on a PS2-Model/Version, where it must 'duck' into the 'inner browser'.

I'm not sure what you mean by "OSD-Mod-Subprogramm",

I mean only the OSDSYS/OSDMENU-Programm-Part (in launcher2.c).
It's like an embedded sub-programm, compareable to the MISC-Tools in uLE.

but if you mean the bootup code inside the main FMCB bootfile, then I think any major additions to it, as required for such compatibility, are ruled out.

Well, 'major-addition' is a 'relative' (don't know how to say it better).
You can see it in many perspectives (is, what I mean with my sentence before ^^).
-Reworked code can be even smaller, faster and more effectively re-used (it CAN be, not a must of course...).
-Additional Code (if any), of course will size-up the 'EMBED.ELF'/FMCB-Loader/'Payload'.

It mustn't be an addition, but what if reworked code simply works better?
I know, Jimmi was skilled back then and is it know still, but maybe back then he didn't thought of some ways, which he can now accomplish.

Btw.: A 'major work' might fit better.

Edit: I 'switched'/missinterpreted the second quote of you a bit, when I replyed (and didn't looked in the posts under the text-field, what you quoted from me) and thought, we were still writing about the OSD-Skip-Disc-Function.

Still, most of it is matching thought.
Maybe it would 'eat' some additional space, but I guess it still is 'within the range'.
/Edit

The 'payload' size of the KELF files used does not allow for such major additions. After all, the total KELF size is only 75KB, and only part of that can be used for the FMCB 'payload'.

Yes, it are around 60,9KB which can be used in a 'DVDPLx'/75KB-Mini-DVDELF.
The question is:
Would it take up too much space?
And: Would it 'cost' space at all, or would another implementation even free up some space?

There still are a few KB left (when packed with normal PS2-Packer-Compression, like all FMCBs use, since I can't even remember exactly, when, but it was before FMCB1.5, so it's some time gone... ), not to mention how far the FMCB-Loader still could be compressed with another compression [which doesn't necessarily mean the NRL-Packer instead...]

To have full flexibility in doing all we want with it, we'd need the ability to encrypt/sign our own KELF files, created from scratch. And that is something our current tools can't do.

Best regards: dlanor

Sad, but true.

Best regards
TnA

[TnA]

Just saw your reply, hence the double-post.

He's referring to the FMCB installer.

Nope. I was actually refering to the sub-programm/routine of the FMCB-Loader, which patches the OSDSYS.

When you install FMCB v1.8b on a SCPH-10000, SCPH-15000 or SCPH-18000 console, the hacked OSDSYS isn't there (Probably not created by the FMCB installer).

Either I'm seriously missing something, or it it is not me.

The Installer only creates the MC-KELF, with the embedded loader in it, creates a dir on MC, copies the MC-KELF there with a (for this version) commonly used name and if multi-install is choosen 'cross-links' multiple dummys and re-indexes their Data-Sector-Values, with the one pointing to the real MC-KELF-Datasectors. (<-- Very rough/short explaination.)

It's simply the loader (or specifically the OSD-Mod-Subprogramm), which is missing/lacking support for these versions thought...

I believe that it's possible to implement (The OSDSYS file of such a console is uncompressed anyway), but it's just not implemented yet.

Yes, I also think it is possible, but the questions raise to the same extend, like those about the OSD-Skip-Disc-Function.

Best regards
TnA

[botastejem]

Hi everybody!

I managed to install free mc boot on my memory card (sony 8 mb) but when i reset my ps2 i get only standard boot menu??
http://sksapps.com/images/ps2_browser.jpg
what is the problem?

I have ps2 v. 30004 R with some chip (i do not know exactly which)

[TnA]

This thread is dedicated to the FMCB-Bugreports.
Do not hijack this, or other threads again.
Create your own thread instead.

[SP193]

Nope. I was actually refering to the sub-programm/routine of the FMCB-Loader, which patches the OSDSYS.

Oops. I guess that posting information before rushing off for school isn't too good for me.

Either I'm seriously missing something, or it it is not me.

It's me.

The Installer only creates the MC-KELF, with the embedded loader in it, creates a dir on MC, copies the MC-KELF there with a (for this version) commonly used name and if multi-install is choosen 'cross-links' multiple dummys and re-indexes their Data-Sector-Values, with the one pointing to the real MC-KELF-Datasectors. (<-- Very rough/short explaination.)

I see. I guess that I was mislead. Oh well...
I thought that the FMCB installer didn't even inject any code that patches the OSDSYS file into the KELF.

It's simply the loader (or specifically the OSD-Mod-Subprogramm), which is missing/lacking support for these versions thought...

If it's because there isn't enough space in the KELF to put 2 different OSDSYS patchers (The OSDSYS file for the v0 consoles are different), I reckon that the FMCB installer could have 2 versions, and determine which one to inject instead.

[TnA]

Oops. I guess that posting information before rushing off for school isn't too good for me.

Obviously.

It's me.

No problem. We all make mistakes.

I see. I guess that I was mislead. Oh well...
I thought that the FMCB installer didn't even inject any code that patches the OSDSYS file into the KELF.

I'm not entirely sure, if it is a grammar-isue (on your side), an understanding-issue (on my side), or if you really mean it the way, you wrote it.

It sounds, like if you think that the FMCB-Installer embedds the OSDSYS from ROM into the KELF which isn't true, but it is only a small fraction of the FMCB-Loader/Code, which modifies the OSDSYS in RAM.

If it's because there isn't enough space in the KELF to put 2 different OSDSYS patchers (The OSDSYS file for the v0 consoles are different), I reckon that the FMCB installer could have 2 versions, and determine which one to inject instead.

Better than that, would be adding support to the current OSD-Mod-Subprogramm.
Why having 2 versions, when one routine can simply check for the PS2-Version it is running on and patch the OSDSYS accordingly.

If this statement is based on an assumption, that the OSDSYS-File get's embedded to the MC-KELF, then I have to tell you again that this is a wrong assumption (obvious, if you look at the filesize of the OSDSYS-File in rom0 ).

[kevstah2004]

Odd control pad 2 behaviour, I have two official dual shock 2 control pads in either control pad slot, whilst a FMCB MC is installed the analog led of control pad 2 breifly flashes on before going off at the OSD, I've switched the control pads around to see if was due to one of the control pads but the same thing happens. When the FMCB MC is removed the analog led doesn't come on unless I press it to do so.

[SoNick]

First of all, you all have my apologies if this bug has already been posted.
Here is the short version, a trimmed snippet from an IRC channel that I frequent:

[19:19:04] <%SoNick> Welp, I broke my PS2
[19:19:27] <%SoNick> It sits at the "FreeMcBoot" splash screen and doesn't do anything from there
[19:20:13] <%SoNick> Nevermind, I think I fixed it
[19:20:28] <%SoNick> It was probably trying to read mass:// since I had a USB-SD card reader there
[19:20:41] <%SoNick> I just removed the card as it's the one I use in my phone

I've only tested on an older, fat-style PS2; I'd report the model number for completeness but I can't seem to find it anywhere on the PS2 or in the menus; if this bug cannot be reproduced on a slim or other newer PS2 I can look up how to find the model number and report it for you.

In any case, the bug seems to occur when the user has a device - such as a card reader - plugged into one of the USB sockets (tested first socket, have not tested second socket) that CAN have a drive but does not currently hold one. This is based on a single reproducible error, however, and as such there are many assumptions in this statement.

I do not think this bug is highly important if it has not already been reported; I personally would like to be able to keep my (empty) card-reader plugged into my PS2 so that I don't lose it but if the bug isn't fixed it won't kill me to simply keep better track of my electronics..! =P