Cannot Save Screen Settings

I’ve recently upgraded my Iyonix to RISC OS 5.20

However I can’t save my screen settings, I’ve set my Monitor Type, Colours & Resolution but the monitor type then defaults back to Auto on the next boot.

Am I missing something?

Hello! It’s me again. Are you just setting the details in the Display Manager? If so, you’ll need to do it from Configuration > Display configuration > Monitor configuration. The Display Manager only sets it for the session.

However I can’t save my screen settings, I’ve set my Monitor Type, Colours & Resolution but the monitor type then defaults back to Auto on the next boot.

Check the file 1Boot.Choices.Boot.PreDesk.Configure.Monitor

It may have | (vertical bar) characters at the start of the line – remove those.

It may have | (vertical bar) characters at the start of the line – remove those.

…and if that vertical bar keeps reappearing, a hacky fix is to write protect the file (without the bar) so the part of the startup that thinks the settings are invalid…gets told to shut up. ;-)

I have been setting this via Configuration > Screen
If I setup the screen settings, then click ‘Try’ then ‘Set’ everything works.
However opening the screen settings again, the monitor type has gone back to Auto.

I Checked the !Boot.Choices.Boot.PreDesk.Configure.Monitor file, there are no |

This file contains the following;

LoadModeFile BootResouces:Configure.Monitor.LG.FlatronL1910B7
WimpMode X1280 Y1024 C32K

Isn’t this a CMOS issue?

…and if that vertical bar keeps reappearing, a hacky fix is to write protect the file (without the bar) so the part of the startup that thinks the settings are invalid…gets told to shut up. ;-)

As per some of my previous posts :)
Hacky? One of my middle names (just after awkward)

I’ve had this problem too, for quite some time. It used to save the settings in the early releases, I don’t recall when it started exactly.

What’s putting the bars in?

AIUI When the OS boots after a CMOS reset it spots that CMOS reset has just occured and changes the L for a |
It can be difficult to spot as |oadModeFile looks very like loadModeFile in system font.

Contemplate the file ADFS::Iyonix4.$.!Boot.Choices.Boot.PreDesk.Configure.!Run, the first line should be :-
Set Alias$VIDCBandLimit X VIDCBandwidthLimit 2000000000 2000000000 2000000000
Note the ‘X’.

Chris – Why does a CMOS reset (ie ROM upgrade) need to alter the screen resolution? In the good old days, you held a key to reset the monitor settings at boot, I don’t understand why the OS is changing it, now it’s not part of the CMOS.

I think it is a bit of a bodge from Acorn.

With RO 3.5, some settings were disc-based, so clearing CMOS could still result in, say, loading a bad MDF, and ending up with no picture. I guess Acorn felt that delete-on should be a safe mode.

Chris – Why does a CMOS reset (ie ROM upgrade) need to alter the screen resolution?

…perhaps because some versions of RISC OS (do you have an SDCMOS module running?) save the configuration at the end of the ROM image; so changing ROM image is akin to clearing CMOS and restoring the default settings.

Reminds me – I ought to patch my version to read/write to something like “cmos/img” so I can replace my ROM image when I want without the side effects.

Reminds me – I ought to patch my version to read/write to something like “cmos/img” so I can replace my ROM image when I want without the side effects.

Perhaps all versions should store the settings in a text file, as per Dave Higton’s suggestions, and then we would have an OS that doesn’t need mystic numbers stored in obscure locations.

Now there’s a patch for you to try.

Perhaps all versions should store the settings in a text file, as per Dave Higton’s suggestions, and then we would have an OS that doesn’t need mystic numbers stored in obscure locations.

It might make things more extensible; however the downside is that if the configuration is in a text file (in what format, wasteful XML?), people will be inclined to fiddle which means the parser will need to be absolutely bulletproof and therefore complicated.
At least with a blob of magic values (which, frankly, the user should not be tweaking directly), it ought to get left alone. And parsing is thus pretty simple – *Load. :-)

Now there’s a patch for you to try.

I’d rather wish I had the time/concentration to rip out TerritoryManager and replace it with something that can be customised without the need to build new modules for territories. I ought to power up the ancient PC (has MSDN installed) and read up on the sorts of things Windows can do in this respect, to see if there are any good ideas that can be folded into this design. Certainly, I think a distinction needs to be drawn between the “language” aspect (which affects upper/lower tables (etc)) and the user-orientated stuff (what’s the first day of the week? what is the timezone?) and that while the former will probably be baked in to some settings someplace, the latter needs to be able to be freely adjusted at a UI level.

That I rolled a replacement module to alter the timezone and change the currency to € is… amazingly eighties. I mean, I felt like I should have been listening to Duran Duran on a tape Walkman while I was coding it. [I actually have a (clone) Walkman around someplace, but the tape is probably Erasure’s Wild! album – not used any of that tech since I got my first MP3 player that could eke eight hours out of a single AAA!]

Contemplate the file ADFS::Iyonix4.$.Run, the first line should be :-
Set Alias$VIDCBandLimit X VIDCBandwidthLimit 2000000000 2000000000 2000000000
Note the ‘X’.

That did the trick! (The ‘X’ was missing)
Thank You!

Reminds me – I ought to patch my version to read/write to something like “cmos/img” so I can replace my ROM image when I want without the side effects.

Perhaps all versions should store the settings in a text file, as per Dave Higton’s suggestions, and then we would have an OS that doesn’t need mystic numbers stored in obscure locations.

Jeffrey mentioned a couple of weeks ago in another thread that he’s thinks there is now a way that enables the CMOS to be removed from the end of the Pi’s ROM. I think it is on his to do list. Though if someone else could do it properly…

Should a failed CMOS load/save generate an error?

Reason I ask is that being a lazy updater I though I’d rename the RISCOS.IMG to just RISCOS and change the Pi’s config.txt accordingly so that when I drag the latest build from ROOL I can just copy it over from the ZIP.

What this meant was that it would never load or save the CMOS (presumably hard-coded to append to RISCOS.IMG?) but gave no indication of it bar the you’ve-got-a-new-ROM loss of settings each time (edit !Boot.Choices.Boot.PreDesk.Configure.Monitor to remove the | if required.)

Would it be easier to have a separate CMOS file or somehow know the filename of the ROM loaded to allow for easier swapping of images?

‘CMOS’ includes information telling the OS where to boot from. So AIUI the information must be within the FAT partition. From what Jeffrey wrote it would have to accessed in a particular way (As a parameter?). I think you could could on the fingers of one hand¹ the number of people able to add that to RISC OS.
¹ You’d have a few spare as well!
As with many things in RISC OS it will probable happen in the future, but we will have to be patient.

Hmm, that makes more sense in my head now – the Pi ROM has a skeleton CMOS in it at build that allows it to boot?

Otherwise we’d be in *Supervisor hell each time we updated sending new users weeping back to Raspbian, so it seem to be more a case that the saving the CMOS back is what I broke.

I’ve no illusions that it needs to be fixed as per my inveterate tinkering but the first part of the post still stands – should there not have been an error when it couldn’t write the settings?