Screen mode not persistent over boot

It may be a coincidence, but since trying to run the !Iris browser (without success) my ARMX6 boots up in wimpmode X1280 Y800 C16M F60.

It is possible to change this either through the iconbar screen icon, or using !Configure Screen.

If using the latter it updates the file !Boot.Choices.Boot.PreDesk.Configure.Monitor
appropriately, but ignores the change at the next reboot.

Can anyone tell me how to resolve this nuisance?

It is quite possible to have an ObeyFile in Tasks, perhaps called ScreenMode, which uses the WimpMode command to set any combination of X,Y, C, F values one wishes.

As this is obeyed late in the sequence it will over-ride anything set earlier in the Boot sequence.

Possibly not the ideal solution, but a resolution of the nuisance whilst you sort out what’s over-riding the configured setting and where it’s doing so!

Possibly not the ideal solution,

Alternately move the Choices.Boot.Tasks directory out of the way, create an empty “Tasks” directory in its place, then copy the tasks back one by one until you see which is messing with the display setting?

PS: John, forget your password or something?

Thanks Rick,
Reporter showed
/BootResources:Configure.ClrMonitor
File ‘BootResources:Configure.ClrMonitor’ not found

Don’t know how that happened!
Anyway I have restored the missing file and things are better. That is the WimpMode setting is respected on boot.

However, !Configure will now not run:-(
This is what Reporter says:-
Reporter 2.71 (04 Dec 2015) List Thu 6th Feb 2020 17:16

• Error ** Error : &80000002
  Message: Internal error: abort on data transfer at &201BAF08
• Error ** Error : &00800E07
  Message: Internal error, no stack for trap handler:
• WimpError ** from unknown task

Reporter 2.71 (04 Dec 2015) Listed 46 lines

John, forget your password or something?

The ukgateway.net addresses are being closed down by TalkTalk if one doesn’t pay a monthly ransom, so I have had to resubscribe anew, losing any previous postings and concomitant street cred!

Putain!

RMEnsure SharedCLibrary 5.17 RMLoad System:Modules.CLib Exec

I don’t use Reporter… Does the “Exec” mean it actually did that? Doesn’t !Boot.!Run load CLib?

so I have had to resubscribe anew,

You didn’t have to – I don’t think the forum uses the email address for anything other than if you happen to forget your password… Mine is a Yahoo! address and I do keep wondering how long it’ll be until they either charge or shut down…?

You didn’t have to

But I did for everything else; banks, services, even ITVPlayer (which can’t get past Vera’s first ad break here).

Apologies for thread hi-jack!

Nothing is quite what it seems. Messenger appeard to be corrupted – abort on data transfer, The filer was misbehaving
- errors when deleting a file -and as mentioned !Configure was crashing. These behaviours were consistent over reboot.

However, I have now stripped what is run at boot time to a minimum, and the above problems have gone away.

So now begins the slow process of bringing stuff back one application at a time to try and find the culprit or culprits.

I will report findings if they are interesting.

But I did for everything else; banks, services,

Ah, but in the case of a forum like this the email address you use has two functions:

1. A means of ROOL sending you specifically a message (unlikely)
2. A visible username on the forum with a matching password.

Most of my postings come from a machine at home but some come from a machine on a domain that isn’t visible to the outside world and any mail from there is seen outside as from a UHCW domain that isn’t used internally – meanwhile I post from there by signing in with a BT email address.

So now begins the slow process of bringing stuff back one application at a time to try and find the culprit or culprits.

One comment: Harinezumi, it’s small and does a simple job of recording what happens in the !Boot. Yes, !Reporter does more but sometimes you need less.

Yes, !Reporter does more but sometimes you need less.

I do not think that is the situation here. Reporter is simply listing one line for every command that has passed through OSCLI. I think it is our friendly Textile wrapping that whole block – and the Exec is really on a line of its own, after a bunch of RMEnsures. And we all know that *Exec with no filename causes the exec file to be closed.

If you’re having weird problems, do check the clock/time. Richard had some very odd issues last year when his clock battery failed. They manifested in all sorts of filer-related aborts and so on. It was ugly.

Also, clrmonitor (if memory serves) gets called if there is a (perceived) issue with cmos. This could imply the clock/cmos module failing. I could be wrong on this – didn’t get much sleep last night, but I remember having issues of clrmonitor (I think) being run too often and forcing reset of monitor file. IIRC it put a vertical bar character in the first line of Monitor file if it sensed cmos was in a non-checksum state.

Food for thought before tearing everything down.

Easy way to test cmos integrity would be to set something like: *configure lmtransport netbeui and reboot, then see if it preserves that or reverts back to “IP”. Remember to *configure LMtransport back to IP after changing.

Steve – installed harinezumi(hérisson).
Interesting, I will leave it installed, but in this case not too useful as my trouble is occurring at or after the Desktop phase and harinezumi has stopped logging by then.

Andrew – thanks for the suggestion about CMOS. However clock/cmos appears to be working AFAICT.

Most stuff is now back and functioning correctly.

… IIRC it put a vertical bar character in the first line of Monitor file if it sensed cmos was in a non-checksum state.

This also occurs when a power on delete is done¹ but it is much more subtle than that rather than add it to the start of the first line in $.!Boot.Choices.Boot.PreDesk.Configure.VRAM
it replaces the first character, which is the L of LoadModeFile with the |
|oadModeFile BootResources:Configure.Monitors.Acorn.AKF60
in system font is very easily missed!

¹ I don’t think a ‘power on delete’ works on an Iyonix or anything later

And we all know that *Exec with no filename causes the exec file to be closed.

Ah, so it’s not an annotation of “done that”. Okay.

They manifested in all sorts of filer-related aborts and so on. It was ugly.

Hmm, I wonder what the cause of that was? I considered that perhaps it was getting unexpected values in the Filer Flags byte (CMOS 198), but that is fully populated – bits 0-7 are all assigned and accounted for, so there’s no byte combination that would lead to invalid values. It’s possible that the DirCache/Buffers might be getting weird values, but these appear to be single bytes for possible values of 1-255 (DirCache) or 0-255 (buffers). Hopefully these will be clipped to something sensible (as I can imagine a directory easily consuming over 1K these days).

but I remember having issues of clrmonitor (I think) being run too often and forcing reset of monitor file. IIRC it put a vertical bar character in the first line of Monitor file if it sensed cmos was in a non-checksum state.

Oh, so that was the annoying thing that used to reset my monitor definitions all the freakin’ time in the days before SDCMOS.
I “fixed” it by Locking the monitor file so it couldn’t mess with it. :-)

I “fixed” it by Locking the monitor file so it couldn’t mess with it. :-)

Me too. Great minds thinking alike or fools not differing? :)