Screen Settings do not stay over booting.

Hi Folks,
I am hoping someone will have a spare moment to help here with this “old, much hashed” question.
I have scoured the literature and web sites to find out how to get my monitor/screen settings to remain in effect after a reboot.
Short story is I have finally got my RISCPC out (with a freshly re-installed RISCOS 4.02, StrongArm and 128Mb of RAM, and 1Mb Video card) and found my trusty Phillips LCD HNS7190T monitor (my Acorn monitor had been binned years ago) would not fire up at all. After much “blind typing” of configuration settings I managed to get it setup so that I could read the start up boot-screen clearly and followed by a mashed up coloured screen with the desktop just revealed, but looking dreadful. The relevant CMOS settings (I think) are as follows:
MonitorType 4
Mode 31
WimpMode 31
Sync 0
TV 0,1

By issuing many [F12]wimpmode experiments I was able to get the OS into a stable 4 grey scale desktop. I was then able to run the !Boot configure routines and used the Screen option to find the string X1025 Y768 C16 EX1 EY1 F60 is quite workable for me. However after a reboot the mashed up mode 31 screen always reappears and the desired script that works is in the text entry for the selectable screen mode, if I click on “OK”, the string is applied and all is good. Likewise if I use [F12] it does not return properly.

My question is how do I make this screen/mode setting “stick” between reboots and [F12]s?? I have tried for hours putting the monitor definition file in various parts of the !Boot process and had no luck. Any direct help, or redirection to a good site would be greatly appreciated.

RobW

Have you checked the battery? Seems like a likely failure. I replaced the (leaking) battery with a chargeable AA battery.

Have you checked the battery? Seems like a likely failure

While checking / changing the battery is a good idea, a likely reason for the loss of working video settings is the system rewriting / resetting the display definition settings

The file !boot.choices.predesk.configure.monitor will have a line :
WimpMode X1025 Y768 C16 EX1 EY1 F60

If you make that file read only, the settings should remain across soft reboots

If you make that file read only

Yes, there’s definitely some sort of bug in this respect.
I had to lock my file to stop the boot from messing with it (and thus mucking up my settings).

Yes, there’s definitely some sort of bug in this respect.

Some people have suggested that the problem comes from the EDID changes, however this (above) relates to RO4.02.
There is, as I recall, a utility that runs and that resets things¹. Unfortunately, what it may be resetting to is a config that doesn’t work on modern display units.

I have a vague memory of Sprow pointing this out some while (years) back.
?? ClrMonitor ??
Run from !boot.choices.boot.predesk.configure.!run

I think it might have been fixed in current release.

I have a vague memory of Sprow pointing this out some while (years) back. ?? ClrMonitor ??

This post by Jeffrey Lee explains what is going wrong with ClrMonitor (and that it had been fixed in some builds at least), and this post gives a workaround that doesn’t involve locking the file.

… but I repeat myself :-)

Thank you folks for the responses.
First the battery has been replaced sometime ago, and there is no loss of any setting over a reboot in CMOS, so am confident it is ok.
I will change this post to point form to improve brevity and update findings

• The most recent configured screen mode is saved into the VRAM file in Choices in !Boot, if I save a screen with 4greys it boots correctly to that state.
• When the computer boots with the 16 colours or more in the Wimpmode setting, the colours are scrambled and are wrong.
• If I then use the settings of X1024 Y768 C16 XE1 YE1, that prompt in the Mode select icon, that does produce a valid, correct display.
• I can then use the Screen Config app from !Boot to successfully set 256 colours and 32K colours at that resolution.
• I can set the Backdrop to a single colour and this applies correctly, but when it boots the colours are again mixed up. But the backdrop is one colour, only the wrong colour.

However it appears that that the palette is scrambled on boot. So the Wimp resolution is OK and the wimpmode is OK, but the pallet is strange and is only fixed after a Screen Mode change, either at the task bar or using Screen Config

Is there somewhere where the palette for a given screen mode is defined that maybe the cause of the weird screen colours?

Rob

I left the RISCPC screen mode/booting problem for a week and returned. I had set the clock to display on the icon-bar and discovered it was way out when I rebooted. I am now suspicious that the battery maybe badly discharged, if not due for replacement. So Michael Grunditz may well have been close to at least one of the factors giving me bad reboots. I am now planning on swapping fully charging an AAA or AA NiH cell to avoid future PCB damage and to also a full recharge if I leave the machine for a long time again. I suspect for the short amount of time that I have been using the RISCPC it has not been enough to seriously recharge the battery to a usable level. Using a replaceable battery I can externally give a full charge when required could be handy.

A supermarket NiH battery may not hold a charge for that long but could be a more workable compromise in the long run.

Just as a note to others cleaning up after a mild battery e corrosion experience about 10 years ago. Just make sure the expansion memory slots are cleaned thoroughly INSIDE as well. Brush the cleaning fluid into the main memory slots and the Video memory as well. I originally replaced the battery, cleaned up the board and re-coated it with a clear enamel to protect it (c 2010) but did not realise there was also leakage into the base of the sockets that could not be seen until I had the memory boards go wonky this time around. The single board 128Mb card had solder type card edge and had suffered complete failure after I had tried to clean it, so two 64Mb boards were sourced quite cheaply and they are now working quite well. The 1Mb video memory fared better with its gold contacts, but I ordered a 2Mb anyway as a backup and it appears to be good as well. So hopefully getting the battery off the motherboard will put an end to this sort of silent disaster re-occuring.

I hope to report more good news next week. Thanks to all those that have responded so far. Rob

an AAA or AA NiH cell

My RiscPC is probably toast – same issue. I’ve not looked and it is under a lot of things so rather inaccessible.

However, I think the button cell is 3V so you would need two AA cells.
Furthermore, NiMh is not tolerant of overcharging. The trickle charge current is a fraction of that required by the old NiCad cells, and too much charge can damage/destroy them.

I think, given the miniscule current draw by the RTC chip, your best bet would be two regular Duracell in a holder (to get the 3V) and a little diode to inhibit charging.

I think, given the miniscule current draw by the RTC chip, your best bet would be two regular Duracell in a holder (to get the 3V) and a little diode to inhibit charging.

That’ll only give you about 2.3V, because of the forward voltage drop of the diode. That would probably be enough though. Or you could do a pukka job with three Duracells and two diodes in series.

Datasheet for the NXP part suggests that it needs at least 2.5V when “in use” with an active IIC bus (perhaps because of what IIC requires as a minimum), but when the IIC bus is unused, it’ll happy run from anything over a volt.

Either way, Duracell and diodes are a better bet than NiMh unless one fancies hacking the charging circuit to provide the appropriate current for the different battery chemistry.

Either way, Duracell and diodes are a better bet than NiMh

Definitely

CJE supply NiMh coin cell replacements, I seem to recall on the basis that the charge would be too low to carry much risk. I’ve had these in my 2 RPCs for a few years without problems.

I may have just killed two old friends.

That’ll only give you about 2.3V, because of the forward voltage drop of the diode.

Germanium diodes are still available, dropping about 200mV!

Germanium diodes are still available, dropping about 200mV!

True, but you’d have to specify them & source them specially – most are silicon. And Rick’s information tells us that 2.3V would be absolutely fine unless the IIC bus is in use even when the power’s down.

The last two of my own RPCs got a pair of NiCads each in holders a very long time ago (when NiCads were still a thing), which worked fine. Whether Cambridge Computer Museum, to whom I gave them when I got my first Pi, have done anything different, or whether they still work anyway, I’ve no idea.

The obvious choice for a diode in this situation is a Schottky. Small signal ones are readily available.

I cheerfully defer to Dave’s superior knowledge of electronics, & happily learn…now reading up about Schottky diodes…

Thank you for your interest in the problem folks. I think given the range of past experiments the battery situation in a RISC PC is probably fairly flexible in what will work. The charging rate for the battery from the circuit is most likely not much above a trickle charge and unlikely to blow up either a Ni-Cad or a Ni-MH. This is most likely the core of my intermittent problem. The charging rate is not likely to lift a badly discharged cell quickly to a reliable voltage, let alone a robust charge. So I work on it for a few hours, it charges a little, setting begin to make sense and reliable as it gets a bit of charge, I think I have the Eureka moment, leave it for a few days and then things are back to scratch.

I do have a second Varta coin cell battery bought at the same time as the one giving trouble now (10yrs ago?). I am tempted to connect it up to a standard Ni-Cad charger and see what happens. Either way I will definitely be taking this opportunity to move the battery off the mother board. If I find the second Varta is viable I might 3D print a holder. I will definitely investigate the “trickle charge” current to see if it is likely to be dangerous with a single Ni-MH cell (quite a few of the commercial offerings use them with no diode (greatly overpriced!!!)). The operating voltage/current for the CMOS or the clock would be driven off the supply voltage, the resting current required to run the clock/CMOS would be much lower, so 1.2V should be OK.

Thanks again folks, Rob

Oh, okay… I thought it was a 3V cell in there.
The TRM says:

A 1.2V rechargeable cell is used to provide the battery back-up. This is trickle charged from the +5v supply when
the computer is on.

It doesn’t go into any detail about charging current. In the schematic, +5V passes through a diode (looks like it might say BAS16), and then has a 180 ohm resistor either side (that is, 180 to +V and 180 to 0v).

BAS16 is quite likely – https://pdf1.alldatasheet.com/datasheet-pdf/view/15967/PHILIPS/BAS16.html

From that, with 5V across it (V_F ~1V) and a 1.2V cell leaving 2.8 volts across your 360ohms giving a current of about 8mA – it’ll be slightly more than that, because at 8mA V_F is a bit less than a volt.

You could work it out more precisely using the graphical info about the relationship of V_F to I_F – but there’s not much point because the 180ohm resistors are +/- however many percent anyway.

the 180ohm resistors are +/- however many percent anyway.

Fitted “Off the shelf”, or SOT ?

I didn’t specify what tolerance they are – I don’t have a TRM for a RiscPC, nor even a RiscPC these days. But I suspect they’re probably +/- 10% – I can’t see any reason why they’d bother to specify any tighter than that, and that was probably the norm at the time. (Dunno what’s normal nowadays…not done any of that kind of work since the early 1980s, when I did contracts as a draughtsman for MicroVitec.)

I think you’ll find that most resistors from that time were 5% tolerance, except for very low values.

Okay – as I said, I last did anything like that in 1984, and that last contract wasn’t really mainstream – screen printed resistors & conductors + surface mount everything else on ceramic wafers, and I was just the draughtsman, not the circuit designer. As a circuit designer I’ve only ever been an amateur, and that a LONG time ago.

But +/- 5% still counts as ‘± however many percent’ I think…

I can’t see any reason why they’d bother to specify any tighter than that

In general, you specify the tightest tolerance likely to be required anywhere on the product mix that you (or your subcontractor) are building, unless the cost of doing so outweighs the savings from reduced inventory and change-over times on the pick and place lines at the factory.

Certainly by 2000-ish, 1% was standard on commodity SMD resistors at the places where I was designing, because as soon as you needed 1% somewhere on any of your products, the extra cost of that over 5% was vastly less than the cost of paying someone to swap reels over between 5% and 1% on the pick and place feeders when products changed, not to mention the cost of having the lines stopped for longer whilst they did it.