Screen Settings do not stay over booting.

Chi Mei 19" CMV-945A LCD, 1280*1024 resolution, 500:1 contrast ratio, 8ms respon

That’s very similar to the Philips 170S, which at least in the current OS has an MDF included. Maybe give it a try and see what happens.

Hi Folks,
Back again. Thanks again to the people showing interest in this problem (well probably a group of problems, I am sure).
I now have a RISCPC that boots satisfactorily and presents an almost perfect desktop with respect to the palette.
I have tried Chris’s suggestion above and found with the Auto CMOS settings, it will allow me to select the Philips 170S, choose 1024×768, 256 colours and reboot into that monitor/wimp combo. Very nice, thanks! It will display the 1280×1024 (looks really amazing!!!) but dies on the less demanding 1122×900 (this then involves recovering from the crash with blind typing etc, not fun :-( ).

But, there is one more problem. My old simple MDF and the Philips 170S both boot up with a color cast. Everything has a slight bluish tinge. Here is a photo of the screen from my old definition.
http://www.laketyersbeach.net.au/RISCPC/T2_1.jpg Note that colour 248 is a strong yellow and not a faint cyan.
When the Display/Mode app is used to reselect the same set up, the colour cast disappears and the desktop greys are once again the proper greys, and the 248 yellow is now a cyan.
http://www.laketyersbeach.net.au/RISCPC/T2_2.jpg
The colours also look a lot more vibrant, though my camera may not capture that so well.

So when I select the Philips 170S, 1024×768, 256 colours, it comes up with the bluish tinge again and the 248 colour is now a cyan???
http://www.laketyersbeach.net.au/RISCPC/T2_3.jpg
If I use the Display/Mode app on the icon bar again to re-affirm the settings, the colour cast disappears. If I go to the Screen app in Configure, it returns.
So choosing a Monitor from the Screen app, refreshes the bluish colour cast. But reaffirming the exact same set up in Display/Mode clears it.
Any ideas folks? I have shown the monitor definition memory dumps in a post above where it has the blish cast and then the same thing without the bluish cast. When the machine is rest and rebooted, the yellow 248 returns.

I maybe nitpicking here trying to correct this last fault, as you have helped me come a long way from a dysfunctional monitor set up to one that is usable on every boot, it is just the colour cast that is getting me. I have read stuff mentioning colour cast but been able to backtrack to how to deal with it.
Thanks again, Rob W

If the monitor definition is too tight (insufficiently large values for the non displayed part of each screen line) the monitor may not be able to correctly determine the black level of the signal, and end up displaying either a washed out or colour casted image.

The issue with the display app and !Configure could be the monitor type setup by !Configure (stored in !Boot.Choices.PreDesk.Configure.Monitor) is being overridden by another LoadModeFile command somewhere else in the boot sequence.

Was sync-on-green still a thing by the Risc PC? I would have hoped not.

Hi folks,

I find the colour cast intriguing (and very frustrating) as it comes back even when I execute and finish an F12 access to the command line, and then later can be removed by the Display/Mode confirmation. So there is no rebooting and traversing all the complexities of !Boot, setting Display though !Boot+Configure etc. Obviously the hardware and software can produce a properly rendered desktop, but the two incarnations of the desktop eg from an F12 return, or from a Display/Mode request differ in some small but significant way.

I am inclined to agree with David’s suggestion the monitor definition maybe at fault, but presumably the two entry points use the same definition. Is there some way of investigating this disparity?

I have tried many of the monitor definitions to find a ‘magic’ one for my monitor, but so many lead to a hung system with no display at all, and that results in repeated sessions of blind typing are a nightmare. I need to be more methodical! Any ideas?

Rob W

and that results in repeated sessions of blind typing [which] are a nightmare.

Make a little script as an obeyfile of what you need to blind-type to recover something useful as a display, and save it into your Library directory under a simple name you can remember and can blind-type easily.

I might suggest calling it “restore”, but you might have a simpler idea! Even “z” would work!

I am going to close this thread, as I think you folk have helped me overcome my the main problem the thread was asking, “How to get reliable screen modes after booting up”. As I said above I think there were a number of problems, taking turns to obscure the answers. Briefly I think these are the salient points:

1. Cells may have a working voltage while being charged, but can lose that voltage very quickly if under-charged and losing current capacity. That is as the battery gets older, its functional charge capacity gets smaller, and while it may charge quicker, it also loses that charge quicker. So checking with a mulitimeter the voltage “in-circuit” ciuld not explain why if I turned the machine on the next day settings were being lost. So a battery replacement required.

2. Setting MonitorType 4, Mode/WimpMode 31 and TV 0,1 will get an LCD to show something, which can be immensely reassuring, but it will also screw up the !boot sequence and screen modes cannot be set, and then return to the same mode on the next boot. Setting MonitorType to Auto and Mode/WimpMode to Auto and TV 0,1 will initially look bad as the monitor will not detect the mode for the initial boot up screen, but will come good with proper desktop after that. I am not sure if my RPC600 is actually detecting the monitor, but it works. Even after replacing the battery, and killing the CMOS completely, the boot up sequence worked. Boot up with Delete key defaults to Auto where required.

3. Finding a Monitor Definition File for your unlisted monitor can be a difficult process if you resort to “suck and see”. Luckily Chris spotted the similarity between my “Chi Mei CMV-945A LCD, 1280*1024 resolution” and the Philips 170S, which has an MDF included in RO4.02. This is quite good but I have a colour cast that comes in when I use F12, and disappears if I use the Display/Mode app on the icon bar to simply reaffirm the text in the prompt (X1024 Y768 C256 EX1, EY1) with OK.

The new battery (an AAA NiMH) fully charged has been swapped in with flying leads off the motherboard to avoid any further battery leak damage. However it will remain to be seen if I have chosen a good enough quality battery (ie slow self discharge), and one with enough capacity (does not dip in voltage too much when clock & CMOS operating operating).

Thanks again folks for your invaluable support and encouragement. I will start a new thread on the colour balance problem as I think it is not to do with the boot up sequence but as david suggested, to do with Monitor Definition parameters and how they are applied. My next big project is to get it talking to my NAS with NFS to get some more convenient file transfers going. The maybe RISCOS 5 (I have the ROMs :-) )

Thanks again!! RobW
PS Any further insights of course will be welcome.

Finding a Monitor Definition File for your unlisted monitor can be a difficult process if you resort to “suck and see”.

Do you have access to a Pi and an HDMI to VGA adaptor?

I think part of the problem is that your machine is too old to be able to read the EDID, so you’re relying upon picking various definitions that are “sort of similar” to your monitor and hoping for the best.

Instead, if the monitor is plugged into the Pi, and the mode type is set to Auto, simply spam the Escape key as the machine boots, and when you get dumped into the command line, *SaveModeFile will save the current monitor setup as an MDF that can be reloaded later on.

That’s how I get the MDFs for my monitors, as (like with the printers) those supplied with RISC OS are decades out of date. ;)

Is there not a generic mode file built in that can manage at least VGA and SVGA? Rhetorical question as it’s been forever since I last used my RiscPC, and I think I set it up for, what was it, the AKF52? Acorn’s generic multisync jobbie.

but I have a colour cast that comes in when I use F12, and disappears if I use the Display/Mode app on the icon bar

Yeah, I can’t quite get my head around that.

Here’s a quick test.

• Boot the machine while spamming the Escape key (to bypass all the boot stuff).
• When you get to the desktop, drag your MDF to the display manager icon. This should load the definitions.
• Switch to your X1024 Y768 C256 mode.
• Does the problem still occur?

And, does it happen immediately as you press F12, or after the mode change that happens when you return to the desktop from the command line?

avoid any further battery leak damage

I dread to think what my RiscPC is like. Luckily it’s under a bunch of things, so I can procrastinate for a few more years…

It is, however, an extremely stupid reason for a dead motherboard, isn’t it? :/

I will try the RPi approach to finding an MDF this weekend. It sounds promising. Fingers crossed!!
In the interim, I have found the bluish cast occurs when I use F12, or set the Monitor/Screen Mode through the Configure Screen setting, whereas when I use the Display/Mode icon it is corrected.
Simply, what is the difference?
Rob

Hi Folks
I have been working on advice given early this week, and have some results to report.
First of all I must reply to Rick Murray as I have set up a RPi+RISCOS with a HDMI+conveter and found it would not produce an image at all. Using a Philips TV to get the RISCOS to produce an image in the first place and then transfer the HDMI+converter cable to the Chimei monitor gave a working image though somewhat displaced “off screen”.
http://www.laketyersbeach.net.au/RISCPC/img_00.jpg these results were encouraging, at least an image of some sort.
Choosing a screen with a 4:3 ratio allowed me to get a more balanced view of the whole screen, though essentially still using the Philips TV MDF. Hence the big borders etc
http://www.laketyersbeach.net.au/RISCPC/img_01.jpg
I then used the Shutdown/Restart option, where I did not have to turn off the whole RPi to get a reboot (because it would not re-boot with the HDMI Adapter to the Chimei, and spammed the Escape key to get to the * prompt. Then I could do a MDF save of an “unknown monitor” definition.
So back to the RISCPC….
I transferred the saved Chimei MDF to an USB stick, then to a DOS disc and to the RISPC. I converted that to a proper MDF in the !Boot monitors folder and rebooted to try it out.
I first tried the lowest resolution and it popped up perfectly stable.
http://www.laketyersbeach.net.au/RISCPC/img_02.jpg
I then Tried the next resolution and it worked ok too 800×600
http://www.laketyersbeach.net.au/RISCPC/img_03.jpg
When I tried my prefered resolution 1024×768 it was really jumpy and had two images super-imposed, not good at all…(Edit: Changing refresh rate to 70Hz fixed this)
http://www.laketyersbeach.net.au/RISCPC/img_04.jpg
When I tried the highest resolution 1280×1024 it was again crisp and stable, with one minor reservation I will reveal later.
http://www.laketyersbeach.net.au/RISCPC/img_05.jpg
The sharp eyed amongst you that have followed this thread will also notice the bluish cast has been present in all of these.
I checked the palette in a !Paint file and found the palette was close to ok, but with a distinct bluish tinge
http://www.laketyersbeach.net.au/RISCPC/img_06.jpb
And using the Display/Mode icon, I was once again able to correct the bluish cast.
http://www.laketyersbeach.net.au/RISCPC/img_07.jpg
If I rebooted the computer softly with either the reset Button or the Power Off/Restart cycle it would boot back into 1280×1024, but with the bluish cast.
For all of the above the “Auto” screen adjust button on the Chimei was used liberally to optimise the different resolutions.
If I rebooted by turning the power off it rebooted into the wrecked palette of mainly blacks again
http://www.laketyersbeach.net.au/RISCPC/img_08.jpg
This last reboot is identical the booting with the Delete key held down (which is is not held down here). Once again it is corrected with the Display/Mode icon as well.

I have replaced the battery with an AA NiMH and tested the voltage, it is around 1.34V, the clock appears to be keeping time and settings like CDROM=1 are holding over time. So I think the clock and CMOS are working OK. When I first put the cell in, it was losing time and the clock was not running, though the CDROM settings were holding. Am I right in understanding the CMOS has a checksum and if just one bit in a setting changes it will upsert the checksum and it reboots like a Delete/Reboot? So maybe parts of the CMOS are flaky, or the supply voltage is not fully charged and keeping the whole CMOS stable?

Lastly the 1280×1024 would not show the command line properly when F12 was pressed like the Philips107S definition would. So something is also amiss there.

So I believe I have constructed an MDF directly from the Chimei monitor, but the bluish cast still occurs and the 1024×768 is very poor, though the other three are stable. Any ideas or should I start a new thread “Colour Casts?”?

I have begun the new thread… Thanks folks.

When I tried my prefered resolution 1024×768 it was really jumpy

Seems a particularly picky monitor – my new one won’t sync well to any 1024×768 on RISC OS 4.xx (RISC PC 600), but is 100% solid when driven by RISC OS 5 on the same RISC PC! It was a lot easier in the days of CRTs.

All those pictures of the screen seem to show the image displaced or stretched – is there an Auto control on the monitor you can hit to try to sync better? Looks like you are losing some of the bottom on the 1280×1024 which would explain why you don’t see the star prompt with F12. [Edit: I just saw your – ‘For all of the above the “Auto” on the Chimei was used liberally to optimise the different resolutions.’ – comment. I guess its Auto function isn’t up to dealing with ancient systems.]

is there an Auto control on the monitor you can hit to try to sync better?

This is normal, so if there’s no obvious Auto button, try pressing every button that isn’t Power or Menu.

On my monitor, Up changes the colour temperature (just keep pressing, it’ll cycle through the options) and Down will sync the display to the screen. This tends to be especially needed when changing frequency but not resolution, like 75Hz → 60Hz and the picture is displayed a little too big (so XP’s task bar is off the bottom). A quick prod of the button and all is good.

It was a lot easier in the days of CRTs.

I’d happily have lousy automatic sizing in place of the CRT flicker and shimmer. And how big would the tube be to get the screen sizes we are used to these days?

Not to mention how we, as a generation, spent half a lifetime being blasted by the lovely things that come from a high voltage cathode ray used in close proximity. If there’s a sudden upwards trend in face cancer in the next twenty years, I think I’d know where to point the finger, and it’s not that big old ball of fire in the sky…

I’d happily have lousy automatic sizing in place of the CRT flicker and shimmer. And how big would the tube be to get the screen sizes we are used to these days?

Of its time! We are talking RISC PC era hardware, so 1280×1024 on 17 inch CRT no problem. Pretty sure that’s what I used. Not all phosphors are created equally, you could get very flickery displays and pretty solid-looking ones.

blasted by the lovely things that come from a high voltage cathode ray used in close proximity

Unless you spent your life staring at the back end of your telly, you weren’t being blasted by anything significant at all. The glass in the front of a CRT was quite thick, and was a lead-silicate glass. Even the sides were thick enough to stop 95% or more of the X-rays. Put yourself close to the back of a CRT and the dose could be significant though – a point I wasn’t popular with MicroVitec management for making to fellow employees. (I only ever worked a few fairly short temporary contricks for them.)

I think I have resolved the Boot reliability as per the colours of the Wimp.
If I do a “power up” boot iget the following scrambled wimp colours:
http://www.laketyersbeach.net.au/RISCPC/img_08.jpg
But if I re-select my chosen Wimpmode (set by using Configure/Screen), by using Display?mode it returns to proper colours (no bluish cast)
If simply press reset it boots with a good Wimpmode with reasonable colours (quite usable, but with a bluish colour cast).
I am going to ascribe the flaky power on boot to the new CMOS cell still charging,
and open a new thread just looking at the colour cast problems.
Check it out. (Unless you can offer something on the power up boot problem).