Free McBoot Configurator

[TnA]

Originally Posted by JNABK

lol, thats exactly what i did too! I put the CNF with 'Test 51' at the bottom and have it on the USB root. Mine just says Free McBoot at the top.

Not exactly,...
The Beta-CNF I've putted to my MC looks like this:


(...changed it right now to this...)

Top: "Free McBoot 1.6b"
Bottom: "Test-Build 51"


...on mass:

Top: "Free McBoot 1.7" (I assume, it comes as 1.7-release, instead of 1.6b or not?)
Bottom: "FMCB-USB-Extension 0.1"

I can clearly see the difference,... (not only in the different OSD, but also in the text,...)

[JNABK]

Originally Posted by TnA

Not exactly,...
The Beta-CNF I've putted to my MC looks like this:


(...changed it right now to this...)

Top: "Free McBoot 1.6b"
Bottom: "Test-Build 51"

Well maybe not the same words you use, but you get the idea of what i mean....

Originally Posted by TnA

(I assume, it comes as 1.7-release, instead of 1.6b or not?)

Im assuming it will, but no absolute confirmations have been mentioned afaik.

[suloku]

Originally Posted by JNABK

Exellent!!

edit:

Dont know if your aware, but there are 2 entries for "Free McBoot Configurator" , @ Item 30 and Item 100 with the same filepath of mc?:/SYS-CONF/FMCB_CFG.ELF as a default setting in the OSD settings menu when you save. So you get 2 displays in the OSD Menu by default, if you didnt change those 2 Items.

I knew someone would say that, I forgot to mention it. This is the same that happened before: default installed cnf has configurator in item 30. Your cnf files when you first used the new configurator didn't have any entry for item 100, so it was set by default by the configurator (i think default place for configurator should be last OSD entry).

As before, it won't happen again as long as I keep writing the hole cnf file. I wanted to keep non used OSD and launch key items out of the file but jimmi had some bugs in fmcb's parsing code and that's why your cnf files have up to 100 entries.

Should I try to find some solution to this (maybe there isn't one) or just write the hole cnf file so all works OK? CNF file takes space, but that ensures there will be always space for configuring.

[TnA]

Originally Posted by suloku

I knew someone would say that, I forgot to mention it. This is the same that happened before: default installed cnf has configurator in item 30. Your cnf files when you first used the new configurator didn't have any entry for item 100, so it was set by default by the configurator (i think default place for configurator should be last OSD entry).

I handle it the same way,...
The idea about jumping back to last item, if first item is reached (or vice versa) isn't that bad, if we have 100 Items.

As before, it won't happen again as long as I keep writing the hole cnf file. I wanted to keep non used OSD and launch key items out of the file but jimmi had some bugs in fmcb's parsing code and that's why your cnf files have up to 100 entries.

Should I try to find some solution to this (maybe there isn't one) or just write the hole cnf file so all works OK? CNF file takes space, but that ensures there will be always space for configuring.

Well,... I think, it can be done, after the new source is release,...
But really,... Every CNF-Entry should be optional,... I agree in this point,... (so a big-fix should be found, I think.)

[JNABK]

Originally Posted by suloku

I knew someone would say that, I forgot to mention it. This is the same that happened before: default installed cnf has configurator in item 30. Your cnf files when you first used the new configurator didn't have any entry for item 100, so it was set by default by the configurator (i think default place for configurator should be last OSD entry).

i agree the last Item should be the configurator.

Originally Posted by suloku

As before, it won't happen again as long as I keep writing the hole cnf file. I wanted to keep non used OSD and launch key items out of the file but jimmi had some bugs in fmcb's parsing code and that's why your cnf files have up to 100 entries.

Should I try to find some solution to this (maybe there isn't one) or just write the hole cnf file so all works OK? CNF file takes space, but that ensures there will be always space for configuring.

I think writing the whole CNF is the best solution , so when someone has an older CNF file, even if they installed it by mistake, they will always get a compatible CNF for the current release its for. If it turns into a file size problem, you can just go back to writing only the changes in the CNF until a better solution is found.

[suloku]

Originally Posted by JNABK

i agree the last Item should be the configurator.

I think writing the whole CNF is the best solution , so when someone has an older CNF file, even if they installed it by mistake, they will always get a compatible CNF for the current release its for. If it turns into a file size problem, you can just go back to writing only the changes in the CNF until a better solution is found.

Well, there's no kind of uncompatibility regardless complete cnf is written or not.

Anyway this one does write a full cnf, so after first configuration it should always load and preserve the settings, even blank ones.

I also added the credits jimmi was asking for, but I need someone to try it on a NTSC device to make sure it's displayed OK.

[katananja]

TNA

About your b51 test, i did not noticed any difference in the 90K model, the FMCB config has a few problems with alignment, the menu text is a little off at the lower menu frame.

In the 10K is another story:

1 - I can't launch FMCB config from the installer.
2 - FMCB install OK.
3 - FMCB crash at the logo screen if i press R1/START or any other shortcut that I've made.
4 - FMCB logo changed to a more higher resolution (??) Because the letters and logo is a bit smaller but much more smooth in the 10K, in the 90K still jaggy.
5 - FMCB goes to browser fine, but I still can't do nothing, the controller doesn't work.
6 - If i disable the OSD hack at the configuration, I still can't do nothing, the controller doesn't work.

All the modules and DVDELF.BIN that I use in this version was the same used in the previos (working) version.

That's it

[katananja]

Originally Posted by suloku

Well, there's no kind of uncompatibility regardless complete cnf is written or not.

Anyway this one does write a full cnf, so after first configuration it should always load and preserve the settings, even blank ones.

I also added the credits jimmi was asking for, but I need someone to try it on a NTSC device to make sure it's displayed OK.

Working fine here
The menu is in the right place!

[TnA]

@katananja: Can you try to specify ESR in your CNF and also try to run a ESR-disc, or another one with fastboot enabled?

Btw.: Lets move to FreeVast-Thread.

[JNABK]

Originally Posted by suloku

I also added the credits jimmi was asking for, but I need someone to try it on a NTSC device to make sure it's displayed OK.

Its just a little off to the left and down of the screen, but otherwise can be seen well enough.

Heres an exact screenshot as seen on my TV for NTSC.


Edit:

Heres what i came up with as a default idea, if my suggestion is taken:

OSDSYS_menu_top_delimiter = -=< Free McBoot >=-
OSDSYS_menu_bottom_delimiter = -=< Version 1.7 >=-

I attached screen shot, its what im going to use.

[kevstah2004]

The blue OSDMenu is starting to remind me of the old betamax players with the blue led displays.

[jimmikaelkael]

Originally Posted by suloku

As before, it won't happen again as long as I keep writing the hole cnf file. I wanted to keep non used OSD and launch key items out of the file but jimmi had some bugs in fmcb's parsing code and that's why your cnf files have up to 100 entries.

It's now fixed with the test51.
You can have only the entry used...

[artdevil]

guys, please make it AUTO:NTSC for non multi-system TV...

[suloku]

Originally Posted by jimmikaelkael

It's now fixed with the test51.
You can have only the entry used...

I'll make some tests, I thought only change was scroll_speed removal as stated in changelog.

Originally Posted by artdevil

guys, please make it AUTO:NTSC for non multi-system TV...

What problem are you having? Is it detecting PAL for you? Do you have this problem with latest version of ulaunchelf?

[dlanor]

Originally Posted by suloku

As before, it won't happen again as long as I keep writing the hole cnf file. I wanted to keep non used OSD and launch key items out of the file but jimmi had some bugs in fmcb's parsing code and that's why your cnf files have up to 100 entries.

That will be a real pain each time someone needs to edit the file by hand (which will inevitably happen sometimes, at least in debugging setups). But why do all the unused entries have to exist at all ?

The general usage needs here are a little reminiscent of the PathPad array of uLE, for which unused entries are never included in the saved LAUNCHELF.CNF.

Should I try to find some solution to this (maybe there isn't one)

The best solution IMO would of course be to fix the parsing problem at jimmi's end.

Edit: And apparently he has now done so, as stated in his post#62 above

Since we are talking about a parsing problem here, this means that the 'syntax' of the CNF entries may need to be adjusted though, just like the PathPad usage in the LAUNCHELF.CNF differs from that of all other CNF variables, so that only those PathPad entries which are non-blank need to be included in the CNF file. The parsing routine reading that file just initializes the entire PathPad array to hold blanks for all entries, and then inserts only those PathPad entries really found in the file. (Each PathPad variable name in the CNF includes its position index for the array.)

The exact same method should work fine for the OSD menu definitions of FMCB, except that there would be more than one string for each OSDSYS entry, but that is very simple to implement. All four variables would use slightly different names, but identical index, just like in the current FREEMCB.CNF. The only real change would be that the indexes need to go higher, and that all four variables for each unused index could be suppressed.

or just write the hole cnf file so all works OK?

This will work too of course. And I assume you really meant "whole set of OSD menu entries", rather than "hole cnf file". We obviously need to write the whole file, regardless of how we define the subsection of its content holding the OSD menu entries.

CNF file takes space, but that ensures there will be always space for configuring.

No it doesn't. It only ensures that the number of entries will be the same. But the space needed for the entries may still be much larger. (Unless you plan to use max-length strings of spaces for each default entry.)

Best regards: dlanor

[suloku]

This version should work OK.

- Blank OSD items and launch keys aren't written.
- Default values for OSD items and launch keys will only be put on failed CNF loading. Note that all other values will fall to default if not present in the CNF.

This will only work properly on test 51. Oh, and tell me if it displays correctly on NTSC now.

Best Regards

[JNABK]

Very nice and yes it displays great on NTSC now.


Oh and a request idea if its possible to do without too much trouble. Could an option be added to reset all de