Purpleberries

I tried updating ROM, OS and “firmware” for RPi, and was greeted by a familiar sight. Using 16M colours causes all the colours to be messed up. It happens on the Pi Zero and 3. RPi4 Can’t get past trying to init the USB ethernet so we’ll ignore that. Hicolour and below works fine.

Every time I reboot it forgets and sets itself to 640×480×256.

I remember this rubbish from about 2016 when EDID came in. Is there a fix for this, besides reverting to a years old ROM which apparently worked better?

I think the option ‘disable_mode_changes’ might sort this out.

A file ‘cmdline/txt’ in Boot:Loader containing a single text line including ‘disable_mode_changes’ is worth a go.

Using 16M colours causes all the colours to be messed up.

Check that config.txt contains the line:
framebuffer_swap=0

Every time I reboot it forgets and sets itself to 640×480×256.

I can think of three possibilities off the top of my head.

Firstly, the CMOS file (!Boot.Loader.CMOS) may be missing/damaged/read-only. Use *SaveCMOS to create a new one, if necessary:
*saveCMOS !Boot.Loader.CMOS

Alternatively, EDID may not be working (or you have disabled it).

Finally, if you’re using a FAT-only SD card (with !Boot moved to another drive) ensure that the boot partition is smaller than 4GB. If it’s over 4GB, the Pi will boot but RISC OS won’t be able to access the boot partition: this will (among other things) mean that configuration changes won’t survive a reload.

While I did update everything, my Config.txt remained unchanged. Then I started trying to get it work, by changing things in it. Things like manually specifying a resolution and various other things. It either didn’t do anything or had negative effects.
One of the negative effects that switching to 1600×1200 may have is the screen becomes a series of vertical bars. Like a single line of the display is just getting repeated for every row.

Not running a big FAT partition or anything like that.

I tried putting framebuffer_swap in config_txt, and did a manual re-add of the CMOS. It “worked” in that it now boots straight to the vertical bars. Another weird thing is my monitor now tells me the resolution is 2160×1200. Where on earth is it getting that horizontal resolution?

Try running !ScreenHelp and see what is going on. Also you do need disable_mode_changes – with that option, the GPU talks to the monitor and outputs at the monitor’s native resolution and accepts RISC OS output, stretching and scaling it to suit the monitor.

Weird thing is the config has worked fine for ages.

I’ve got as far as getting sane colours and resolution now with truecolour. CMOS seems to be saving alright but I keep needing to re-select the autodetected monitor and resolution.

I keep needing to re-select the autodetected monitor and resolution

RISC OS may not behave itself if you use EDID – monitor type “Auto(your-monitor-name-here)” – as well as disable_mode_changes: it’s not a combination I’ve tested.

What I have seen is RISC OS choosing the “wrong” resolution if it considers the monitor’s native resolution unsuitable.

Try going to Configure > Screen and explicitly selecting 1600×1200 pixels (and a colour depth of your choice). Don’t change the monitor type, just the resolution.

What do you have in !Boot.Choices.Boot.Predesk.Configure.Monitors?

!Boot.Choices.Boot.Predesk.Configure.Monitor
After changing monitor / resolution

LoadModeFile Resources:$.Resources.ScreenMode.Monitors.EDID0

Before changing monitor / resolution:

|oadModeFile Resources:$.Resources.ScreenMode.Monitors.EDID0
| WimpMode best from monitor

No. I did not delete the ‘L’

I would like to point out that this is a relatively recent install of RO. Maybe a couple of months or so. I accidentally snapped my old MicroSD card in half inserting it into my Pi Zero.
The config files were copied from another RO SD that I also have. Everything worked fine up until maybe last week when I updated things.

I also want to say I badly garbled the first post. I was tired and cranky.
The essence of what I was trying to say was that I don’t want to go back to an earlier ROM because of an issue that was fixed a few years ago.

I omitted the second line comment in one instance above. They were the same.
Can confirm that once I change back to 1600×1200, it’s back to LoadModeFile
This is weird.

Just tried rebooting so it’s 640×480×256, Editing the |oadModeFile to LoadModeFile, Saving and rebooting. It still reverted to |oadModeFile.

Again, I want to stress that Auto(monitorname) used to work.

Try running !ScreenHelp

I don’t know what that is.

Don’t change the monitor type, just the resolution.

Can’t. It defaults to monitor type: Auto. All fields are set to unknown adn grayed out.

edit: Since adding disable_mode_changes to cmdline.txt the hardware resolution is 1600×1200 but the RO resolution is 640×480×256. Though I’d better add that.

Just tried rebooting so it’s 640×480×256, Editing the |oadModeFile to LoadModeFile, Saving and rebooting. It still reverted to |oadModeFile.

I forget the specific item in boot, but there’s a bit in there that tries to match your mode with the selected monitor capabilities as in the file and when it fails to do that it “helpfully” makes that change and the system defaults to the 640 × 480.

There was supposedly a fix (damned if I can remember it), but at the time I just crowbarred in my selected resolution by making the !Boot.Choices.Boot.Predesk.Configure.Monitor file read only.

Interesting. Mine also worked fine before updating from an older nightly ROM and HD4.

Just before I saw your post I summoned my inner Jedi and used the Force. With the (probable) aid of AnyMode I plopped an Obey in PreDesk setting the WimpMode. Life is too short to fight with broken things.
I just wish I could pick the brains of the EDID to generate a definition file.

I don’t know what that is.

It is on !Store. Also here

I tried it. Didn’t help much unfortunately.

I feel the problem is a mixture of some kind of bug regarding the permanence of the EDID detected monitor, and RO being kind of weird about 1600×1200.

I just wish I could pick the brains of the EDID to generate a definition file.

Perhaps *SaveModeFile would help.

The business with the pipe being placed in the LoadModeFile thingy is because the Boot sequence thinks you are resetting your CMOS/MonitorType. This logic is being triggered on your system for some reason!

There is something you can do to clear this, but I forget what!

Jeffrey Lee’s post from 2015 explains that the ClrMonitor module is responsible for turning “LoadModeFile” into “|oadModeFile”, and also why it does it (the OS has reported CMOS as having been reset).

An even older post by Jeffrey Lee suggests that you can avoid the !Boot.Choices.Boot.PreDesk.Configure.Monitor file from getting clobbered by putting two lines with ‘|’ in them at the beginning of the file.

Everything points to a problem with the CMOS file, but Tristan stated upthread that CMOS updates are being saved. It’s a puzzler…

Before this reply I made absolutely sure the CMOS is saving. The date stamp updated so it must be.

*SaveModeFile is a gift from the depths of the PRMs! I had no idea it existed. Thank you!
As mentioned earlier I forced the correct mode at boot with an Obey file so I didn’t have to do it manually. That results in the active moitor being “Auto” instead of “Auto (HP LP2065)” or however it’s laid out. I’m not at the Pi right now.
I switched to HP LP2065 and ran SaveModeFile. It looks sane to me. Anyone interested in a ModeFile for another monitor?

What I found interesting was that the ModeFile referred to by the monitor file in Choices for the EDID is a binary file. I’m sure it’s fine, but I thought it would be a text file.
Jumping back to this from a little later. After typing it, it does seem suspicious. But then the modes wouldn’t appear in the mode choices.

I seem to recall tacking in a WimpMode command in Monitor and it outright disappeared. I did put it in right under LoadModeFile. I’m a bit hazy because I’ve tried a lot of things.

It seems odd that functionality that haas worked fine for a few years has broken, at least for me, after doing a regular update. Previous to this recent update of everything, EDID worked fine. It didn’t need any special treatment like disable_mode_changes or anything really. It’s just weird.
Next chance I’m going to plop the new modefile in with it’s friends to make things a little easier for me. But I still want to knw what’s broken in EDID.

Jeffrey Lee’s post from 2015 explains that the ClrMonitor module is responsible for turning “LoadModeFile” into “|oadModeFile”, and also why it does it (the OS has reported CMOS as having been reset).

Thanks for digging back.

Perhaps if ClrMonitor only took action when the CMOS file was absent or had a specific value for the date time (0000 Jan 1 1970 perhaps)

It strikes me that the EDID code may be slightly buggy.

I plopped the modefile in, and experimented with removing AnyMode and the forced resolution in the Obey file. No good.
AnyMode got added back in. At least the right resolution could be selected again in Auto(HP-LP2065).
The generated Modefile wasn’t displaying 1600×1200 in the modes selection in Configure, even though they did exist in the file.
Not that it matters. On reboot it just changes back to “Auto”.

If you use ScreenHelp it will tell you exactly what information your monitor is returning in response to an EDID request.

I just had an odd monitor issue too with the “Auto” configuration. During the weekend I brought my PI3 at a friend’s home and connected it to it’s Samsung HUD TV. The desktop started in 640×480 mode and I had to change the resolution back to 1920×1080. I thought it must have been due to a boot issue due to the fact that we had no network cable at hand.

After that I was a little busy, and only just started the machine again at home today. The machine seemed to start normally but only 1920×1080 was listed as screen resolution and the color menu was entirely greyed out.

Checking, the file “!Boot.Choices.Boot.Predesk.Configure.Monitor” was totally empty. I have copied the version from RO520Hook over it rebooted and all is fine again. Seems like the issue with Samsung TV may have been more than just a boot failure.

I used ScrHelp. After removing AnyMode and the forced resolution again here’s what I got:

RISC OS 5.27H
(16 Aug 2020)
RISC OS:
640×480 C256
GPU:
1600 × 1200 C256
Monitor:
1280 × 1024 85Hz.
1600 × 1200 60Hz.
1600 × 1200 @60H

After doing this I noticed two things. Auto(HP LP2065) no longer has a “Native” resolution option. Possibly saving and adding the ModeFile to the definitions poisoned the well. 1600×1200 wasn’t even an option. At least not immediately.
Through Configure→Screen I changed the colours to 16M, and left it on whatever the absurdly low default resolution for that was. The colour depth changed but not the resolution. Upon checking the resolution menu again 1600×1200 had appeared. Selecting it worked as expected. Odd.

I set up a fresh SD card. Same issue with screen modes.