My CMOS won't work

Well it does but only after continuing beyond the given instructions. My widget arrived today, thanks Steve & Sprow. Installing the adapter and and switching on stalled at the waiting for drive message because, I presume, there’s now no CMOS settings. My memory of command line’s rusty but I resolved it by ESCaping into the Supervisor then entering *drive 4, *Pling-Boot.Pling-Run. Despite a non-completion error that then gave me a Desktop from which I could ‘Load CMOS’. Is it an issue because I’m using a HDD rather than memory stick?

(Damn Plings)

Apologies for the topic title but I thought it might help someone track a solution.

The CMOS chip is blank when supplied, so on first power up after installing it is filled with the Kernel’s default values – which includes a default SCSI boot drive of 0.

If you’re using drive 4 (a harddisc) then you’ll need to either press escape to get to a command prompt and do
*CONFIGURE SCSIFSDRIVE 4
or mount drive 4 manually and do
*LOADCMOS PlaceWhereYouSavedIt
ordinarily you’d use the save and load option in !Configure but if you interrupted the boot sequence you wont be able to run !Configure from the desktop.

Thereafter you’ll be back to normal.

Unfortunately *LoadCMOS won’t work if the boot sequence hasn’t been run – it checks Boot$OSVersion against the version number in the CMOS file, but Boot$OSVersion is set by one of the utilities in the boot sequence. I guess you could always work around it by doing this beforehand:

*Set Boot$OSVersion 510

We actually provide software to automate the upgrade procedure with the widgets. It’s available free of charge to any of our customers/users who wants it. Perhaps Fred would like to get in touch?

@Andrew

Thanks but I don’t need it. I explained how I sorted it in my original post. Just pointing out that further instruction might be needed for some on the instruction card.

Since updating to RISC OS 5.18, my BB ignores the setting I have made in CMOS. I have raised the problem on the ARMini users list but nothing suggested there works. My BB is a revC board of vintage 2010. I have tried the ARMini route. I then tried using SDCreate and was rewarded with BB getting stuck on the orange screen. :-((
I don’t have a widget and even if I get one would still like to get the CMOS working without one. I know something is being saved to the SD card when I use !WriteCMOS or !BBFlash, but the setting is being ignored on boot up.
Someone on the ARMini users list claims that his setting of the !Alarm clock to digital view is being ignored and that is just my problem too.
I noticed that at the end of using !SDCreate the window that describes what has been done ended with “File too big at 184”.

To follow up my own post, I have tried the SDCreate route again and the SD card appears to work satisfactorily, my settings are no longer ignored on boot up.
However, the Report produced by Martin Avison’s Reporter has 600 odd lines at the beginning of the form “20000014 448 Alloc” immediately after the line “Heap RMA=&20000000 Max=252M Size=2364K Free= …….” and ending just before “15:49:13.46 | End of Reporter !Run file”. What does it all mean?

Try updating to Reporter 2.66d. In RISC OS 5.18 the restrictions OS_Heap places on how memory is allocated were relaxed a bit. This causes old versions of Reporter to get a bit confused and spit out lots of warnings.

When I get a chance I’ll look into that “File too big” error you were getting with SDCreate (I thought I’d fixed it in the latest version, but maybe not)

However, the Report produced by Martin Avison’s Reporter has 600 odd lines at the beginning of the form “20000014 448 Alloc” immediately after the line “Heap RMA=&20000000 Max=252M Size=2364K Free= …….” and ending just before “15:49:13.46 | End of Reporter !Run file”. What does it all mean?

I would be able to explain if I knew (a) what version of Reporter you were using, and (b) what provoked the Reporter output – did it happen at boot, or after you entered a *ReportHeap command?

But, as Jeffrey says, you should be using Reporter v2.66d on RO5.18. I suspect you were still using v2.66.

Hi Martin. Problem solved with updating to Reporter V2.66d. The problem was with Reporter v2.66b and it happened at boot. No, I didn’t give a *ReportHeap command. Thanks for prompt reply.

David, Reporter v2.66 did have an automatic *ReportHeap at startup, but that debug code was removed in v2.66a within days. Odd. But I am glad that v2.66d has resolved your problem. This version is recommended for anyone using Reporter with RO5.18.