Screen Settings do not stay over booting.
Clive Semmens (2335) 3276 posts |
Thanks, Steve. Interesting. Much the same at Microvitec in 1980, except we were considering whether it was worth stocking 10% instead of 20% 8~) (it was). |
Rob Ward (9450) 42 posts |
Hi Folks. I have found that if I boot up with the Delete key held down it will boot through to a C256 or C32K mode desktop screen with the colours mixed (same every time but incorrect), and simply going to the screen mode icon on the icon bar, and re-choosing the screen mode text shown eg X1024 Y768 C256 EX1 EY1 by clicking OK (ie making no changes to the string) will produce a correctly coloured display at the right resolution. This will be the original screen mode previously selected in the Screen Config from the !Boot option. If I don’t hold down the Delete key the screen boots to a desktop again, but the colours scrambled (mixed but same each time) and the screen mode icon simply has the text “32”, which is what wimpmode is configured to, but with a reduced resolution. I feel there is some intermittent, most likely hardware that is at fault, maybe battery, maybe CMOS/Clock? It has become very frustrating. |
Stuart Swales (8827) 1357 posts |
Once you have configured MonitorType 4 Mode 31 WimpMode 31 Sync 0 TV 0,1 etc. can you read them back with *status after a few minutes of the system being up and running? If the system doesn’t return sensibly to a desktop after F12 that suggests the CMOS has already corrupted. |
Rob Ward (9450) 42 posts |
Thank you Stuart for your suggestions. If I hold down the Delete key, it then reliably boots to the correct wimp mode, but again with scrambled colours (they are always the same), so I can see and work the desktop, but it is hard to see because the colours are not logical ie normal. If I middle click on the Display Icon on the Task Bar and choose Mode I am prompted with this text X1024 Y768 C256 EX1 EY1 and if I click on ‘OK’ the Wimp Mode is 100% correct. The ShareFS icon does not re-appeared. After it has been running a while I can press F12 and it returns very reliably to the correct Wimp Mode. It seems it trips over some last final hurdle, and just fails on installing the Wimp mode it should and can do. I would be grateful for any thoughts on this. |
Andrew Daniel (376) 76 posts |
Hello, It has OS 4.02 ROMs fitted and uses the current Rool !Boot, with a few bits of the 4.02 !Boot grafted in. It is quite happy booting into 4.02 or 5.28. Hope this is of some help. |
Rob Ward (9450) 42 posts |
Thank you Andrew for giving me some sense of optimism with this drawn out debugging. By volume I think the Cell I have would be somewhere between a AA and AAA cell. The smaller AAA cell should charge better on the “trickle charge” (ie recover quicker from a serious long term discharge, but the AA cell would have better capacity to survive longer time between charges. I am using RISCOS 4.02 ROMS, and also have the 5.x ROMS to try, and will look up the Rool !Boot as well. Can’t help but feel there is some glitch in the !Boot sequence I have introduced at some time. Just to add another quirk in the story, I set the time this morning and about 10 hours later tonight, I switched on the RISCPC with the Delete key held down, and the clock was correct. The screen booted into the mode I set it on this morning, but with the colours shuffled around (very garish!) and these were corrected once again by using the Mode selector on the Icon Bar (just selecting ‘OK’). I am going to check the time etc again in the morning. So I feel the battery is not a voltage problem, but definitely a potential leakage problem and must be changed soon. At least one thing will get fixed. |
Andrew McCarthy (3688) 605 posts |
I think I followed this article or similar advice a few years ago. Also, Stardot has several battery-related threads that may provide valuable insights. |
Andrew Conroy (370) 740 posts |
The CMOS battery, as fitted by Acorn or supplied by CJE, is nominally 1.2V. The clock chip should retain settings and keep the clock ticking so long as that voltage stays above approx. 1V. The clock losing time could be a faulty 8583P, a faulty crystal, faulty trimming capacitor (C500 from memory), or damage to the board around the chip/crystal/capacitor circuit. Have you tried starting up with Shift held down, to be sure that it isn’t something being run in the boot sequence which is messing up the colours? |
Rob Ward (9450) 42 posts |
Thanks folks for your support in cracking this one. |
Bryan (8467) 468 posts |
You can disable ROM modules by ‘unplugging’ them. eg Type See also |
Andrew Conroy (370) 740 posts |
That is what you would expect to see when starting with Shift held down as this stops anything in the boot sequence being run, including your monitor definition file which gives you selectable resolution & colour depth. If the colours are corrupted here, then we know it’s not something in your boot sequence causing it.
Delete power-on resets your CMOS settings but still runs your boot sequence, so the monitor definition file gets loaded and your chosen resolution & colour depth are selected.
We’ve deduced from this that the colour corruption is not caused by anything run in the boot sequence. The ignoring colour depth on starting with Shift but not with delete is entirely correct behaviour
I think Alarm settings are saved in !Boot.Choices.Alarm (?) if you save your settings. Just changing the display from analogue to digiotal and not doing anything else won’t necessarily get carried through to the next power-up.
You can disable a module by typing A list of currently unplugged/disabled modules is shown if you just type |
Stuart Painting (5389) 714 posts |
For the clock display settings, that’s only true from Alarm 2.94 (26 Feb 2020, RISC OS 5.27) onwards. I think Rob is using RISC OS 4, in which case the CMOS settings (byte 220 bits 0-2) should control. It being a CMOS setting, this should of course carry forward to the next power-up. Question: Is Rob using a desktop boot file (also known as a “desktop settings” file)? Best to get the obvious edge cases out of the way… |
Andrew Conroy (370) 740 posts |
So, try doing a Shift-boot so as not to run anything from the boot sequence, and then run Alarm, see if the display settings are carried over now. |
Rob Ward (9450) 42 posts |
Good point Stuart and Andrew. I did indeed try a desktop settings file as I thought that may have triggered a proper palette for the final desktop display. This did not work, but other things like open directories showed up ok. If I change the palette to 4greys it reliably stores the wimpmode setting and boots correctly into it. Andrew I appreciate your elaboration on what differences the Delete key and Shift key boot do. I have previously added a Spool settings1 into the Boot file to trap output a "show" modules and then repeated the same using F12 and *Spool Settings2 after it has booted. I hope to compare the two closely when I get back in a couple of days time. I think without the Delete key pressed the Mode31 crashes and the full boot up is not processed. I can’t see any error messages. |
Bryan Hogan (339) 593 posts |
I’m really puzzled as to how the colours can be messed up when you boot up with Shift held down, which means it is using very basic 16 colour SVGA (mode31) unless the VIDC was faulty, but then it wouldn’t correct itself. Could you show us a picture of what it looks like? Something else to try – remove the VRAM and see if you get the same effect. |
Rick Murray (539) 13850 posts |
That would be good, as the base desktop works in 16 colours, so anything from a 16 colour mode upwards ought to look “correct” (although, obviously, images and such would look a bit naff at lower colour depths). As Bryan says, it’s hard to imagine there’s some sort of hardware problem if software can cure it.
Not necessarily. Booting with Shift just means to skip the !Boot stuff. Can you, from the command line with the wrong colours, do two things please. The first is to enter *Status to see what Mode and WimpMode are set to. The second is to go into BASIC and enter PRINT MODE Just in case, somehow, the machine is booting in a 4 colour mode or something… |
Rob Ward (9450) 42 posts |
Hi Rick, Thanks you for your interest in this problem. I have checked the CMOS using *status and Mode/Wimpmode are set to 31. I have found this the best option so far as when I reboot the RISCPC the initial Text boot up messages can be seen (memory size etc). I then ran BASIC in a Task Window and tried PRINT MODE. This is the answer I got 29413900. I then ran BASIC from F12 prompt and got the same. This seems really weird to me. Bryan, I have tried removing the Video RAM and booting without it and the same thing happens. I even bought an upgrade to 2Mb to check that as well. I read somewhere that Delete Key Boot up resets the CMOS apart from: I find if I boot with the Delete Key held down the initial Text Screen text up does not appear, the monitor reports it cannot display the video, however it almost boots properly, screen resolution, depth of colours is correct, but pallette not right. When this is corrected with the display the colours are almost right. However if I don’t hold down the Delete key, it does show the start up text and then swaps to the wimpmode, all be it with incorrect palette and resolution. I have managed to capture the palette problem with my phone camera. The sequence shows what is happening to the palette really well, but I can’t see here how I can add images and how much space we are allowed for such things in a post. Any suggestions? Rob |
Rick Murray (539) 13850 posts |
That will be pointing to a mode block. You’ll need to convert that to hex using: PRINT ~MODE It will reply something like Then to see what’s there, do: *Memory 1C0D20C +20 (replacing the hex value with the one you get, if different) How that memory is laid out is https://www.riscosopen.org/wiki/documentation/show/Mode%20Selector%20Block
Delete resets all CMOS – http://www.riscos.com/support/developers/riscos6/startup/resettypes.html Code here: https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/blob/master/s/NewReset#L567
It looks like monitor type and sync are set to auto, which means the mode will be determined at boot; but I’m not sure the IOMD (RiscPC) can do that correctly.
Do you have YouTube? You could drop a quick video of it booting there? For images here, it’s simply a matter of an exclamation mark followed by the URL to the image followed by another exclamation mark. The complication is that you need to host the image somewhere else (like Imgur?). |
Rob Ward (9450) 42 posts |
I have added some still images of the frustrating Boot process: This is the boot up when the Delete Key is held down. Note the palette is way off, only half of it is remotely correct, about half is completely un-initialised. After performing the Display/Mode option on the icon bar, the text X1024 Y768 C256 EX1 EY1 is present and clicking on OK corrects it. This is the unaltered screen from the previous image, but with the text executed, I have called it up a second time her to show you what appears in that text box. In the following image there is a bright yellow colour at the bottom of the palette aray of colours, if I go to the Display/Mode option and repeat it, the colour palette has been totally corrected. So this image demonstrates the palette is now correct. However note the CDROM icon, normally on the left hand side has not appeared, even though it is set on in the Configurations and CMOS. This comes up with the AUN icon when booted without the Delete key down. If I use Rick, I have also made a Youtube video at https://www.youtube.com/watch?v=Yknk5RAB0Dc I am at the point where I feel I should just try creating a new RISCOS 4 !BOOT directory with the IOMD Set Up provided on the installation CDROM. I may have messed with too much and not been systematic enough. So if anyone wants to suggest trying that I am happy to go back to the beginning and work though it again. There is a good chance some “bad” alteration I have previously tried is lingering in the system and not been deleted, stuffing things up. Thank you for all your assistance so far. Rob |
Rob Ward (9450) 42 posts |
Just to summarise a long story: |
Andrew Conroy (370) 740 posts |
If the !Boot is not completing without error, then definitely nuke it and install a totally clean, fresh copy of the !Boot from the RISC OS 4 CD or from here NB. If you boot with Delete held down, then you shouldn’t expect to see a CDROM drive icon present since the default CMOS setting is cdromdrives=0. It will also boot into a default low-res mode as the configured MDF will be disabled, you’ll need to run !Boot and select your desired MDF and resolution/colour depth again. This is standard behaviour when doing a delete power-on. |
David J. Ruck (33) 1636 posts |
If you get errors during boot, most likely the screen settings when the desktop is reached wont be correct, which was my initial though when this whole topic started. |
Rick Murray (539) 13850 posts |
True, but there’s incorrect and then there’s the first photo posted which is gonzo. Interesting to note, by the way, that pretty much the only colours on the right half are laid out as the standard Wimp colours, except blue. Something is definitely messing with the palette there. |
David J. Ruck (33) 1636 posts |
First time I’ve seen that, and I’d say the VIDC is broken – you just can’t get half palette in a 256 colour mode via programming registers incorrectly. No amount of fiddling with the boot sequence or CMOS is going to fix that. The only thing I can suggest is to remove the VRAM (if present) and see if anything different happens. |
Rob Ward (9450) 42 posts |
Hi folks, Yes Andrew, using Delete/Boot does nuke the CDROM icon, so I now have it back. Thanks I agree David, I am partly to blame as my Mode/WimpMode/MonitorType/Sync were all set to standard “rescue” values that I had grown to trust, when I check the CMOS now using *Status I find that they are working well with all set to “auto” (and TV0,1). I also notice that earlier comments about battery condition are also maybe more important too. If I leave the RISCPC on longer it becomes more reliable. I have measure the voltage on the battery (big coin cell replacement c:2009) and found it was charging from 1.36V to 1.46V over 4-5 hours. So while its voltage maybe looking good, its actual current delivering capacity maybe very poor, hence poor retention. The clock is reliable now and keeping good time. The problem with a trickle/top up charger, they are very bad at recharging a very flat battery. I have a second identical battery bought at the same time and its voltage is 0.86V and it has not been connected to any circuit at all, so just gradually discharged to that state. Well below 1.2V acceptable for a NiMH cell. Finally returning to the screen state on Booting, the screen is coming up in the right mode, but with a slight bluish tinge (a huge improvement). If I go to the Display/Mode icon and refresh the wimpmode string in there with just an “OK” the colour cast disappears, and the palette is 100%. To have a look at that, I have used your advice earlier Rick, of getting a memory dump of the current mode. Here are the two dumps, the first with the blue tinge and the second without it. >REM Reboot the computer, the screen gets to X1024 Y768 C256 ok, but there is a blue cast. Address : F E D C 3 2 1 0 7 6 5 4 B A 9 8 : ASCII Data Address : 3 2 1 0 7 6 5 4 B A 9 8 F E D C : ASCII Data Many thanks so far, I am going to replace the NiMH battery this weekend with a fully charged AA NiMH. Cheers, Rob Chi Mei 19" CMV-945A LCD, 1280*1024 resolution, 500:1 contrast ratio, 8ms respon |