Colour Cast

Hi Folks,

Edit: New Readers, please just skip to the end, and check out the latest. Much has turned out to be repetitive, I don’t want exhaust your curiosity or enthusiasm to contribute by having to grind you way all though it. Come back and browse for more clues if you need to. Cheers and many thanks, Rob

I have a problem with a colour cast (bluish) on a RISCPC RISCOS4.02 (I have 2Mb of VRAM, 128MbRAM and a StrongARM), when I set a Screen using Configure and also when I return from F12.
This is a photo of the screen in 32K mode after F12 has been pressed and then returned.
“Colour Cast”http://www.laketyersbeach.net.au/RISCPC/img_10.jpg
The banding in the !Paint palette colours is obvious and the mismatch in the general GUI colours can also be seen.
Using the Display/Mode control on the icon bar just to use the preset string, click on the OK and the colour cast is gone. These are the expected colours.
“No colour Cast”http://www.laketyersbeach.net.au/RISCPC/img_11.jpg
When the RISCPC boots from a Reset it boots into the wimp with a bluish colour cast, using Display/Mode option (nothing extra need be entered), just clicking OK corrects the colour cast.
Pressing F12 causes the colour cast when returning (not when F12 is pressed).
I have captured the EDID values from my monitor using a RPi running RISC OS. I created an MDF for the Chimei monitor and it can be used reliably to select wimp modes (Resolutions, Colour and Frame rate) that otherwise work well. It was suggested by another reader in my previous thread that maybe the MDF I found was usable, ie the Philips170S did not have accurate enough definitions, and was “washing” out the colours due to black levels etc not being properly defined. The Screen MDF reference gets written properly to the Boot VRAM file. So somehow Display/Mode can correct it so the system can display correctly, but when configuring a new display set up, or pressing F12 it takes some other route.

Any suggestions how to solve/debug this would be welcome.
Rob
PS Thanks to all the other people who contributed on the previous thread.

Hi
So at first glance it’s not a hardware problem, so much the better. I assume that in your boot.desktop file there must be a change of palette of the wimp at startup and I think that file must be called after an F12.
On my ARMX6, in boot.predesk.configure there is an obey file called monitor wich use the WimpMode command.

Good luck

Ok I will look into that, Thanks Jean-Michelle. Rob

there must be a change of palette of the wimp at startup and I think that file must be called after an F12.

More likely setting the palette upon a MODE change, which will correspond with startup and returning from the command line.

I can’t bake a cake right now (risk of thunderstorms and cake baking is slow), so… let’s have some fun picking this apart.

What happens when you press F12

(nerdy stuff, if you’re not particularly interested, feel free to skip to the next section)

Pressing F12 for the command line is handled by Switcher (task manager). This, very simply, looks for an F12 keypress, and if found, will call the ShellCLI command using Wimp_StartTask.

Wimp_StartTask (in Wimp07) is quite complicated. It will shuffle the parent task out of the way, and allocate memory and a task handle for the child task, assuming it’s a single tasking task (they all are, until Wimp_Init is called). It will then call Wimp_CommandWindow to pop up a text window on the screen if there’s any text output.
Finally, the system calls Wimp_CloseDown (to fully switch to this new task) and then OS_CLI to run the command.

ShellCLI, interestingly, does a Wimp_Initialise. This may be in order to be able to take over the screen without the Wimp interfering. It then switches to VDU4 (text cursor) mode, resets all the text cursor stuff, sets the text colours, moves to the bottom of the screen, turns off the pointer, and then prints the familiar message. It also sets up an exit handler to return to it (rather than the Wimp) for when something run calls OS_Exit.
Then it just loops passing commands given to OS_CLI until there’s a blank line (zero length) at which point it will close itself down, mark CommandWindow -1 (to cause a screen redraw), and exits back to the Wimp.

Exiting back to the Wimp will notice the CommandWindow state, and force a mode change to the current Wimp mode. Then the logical colours will be set up unless the mode is 2/4/16 colours in which case the actual palette will be set up to match.
I think the palette itself is set during the MODE switch, and for 256+ colour modes, the Wimp just uses the applicable colours.

What Display Manager does

The Display Manager works out what to do to describe the current mode (most likely a mode specifier like “X1024 Y600 C16M F60”, and then calls *WimpMode which, in turn calls the Wimp_SetMode SWI, which in turn calls the same internal setup stuff as was used by the Wimp returning from F12.

So… hmm… what’s the difference here?

An idea

Just a little bit of cargo cult madness to rule out glitching… if you have a bad set of colours, does turning the monitor off and back on again make any difference? Likewise, does anything change if you do that when you have a good set of colours?

What about, if you come back from F12 with bad colours, if you go into F12 and come back out again?

Another idea

On my ARMX6, in boot.predesk.configure there is an obey file called monitor wich use the WimpMode command.

Yes. That is necessary in order to set up the proper screen resolution. Without that, you’ll get whatever the system configuration specified, but the system configuration only understands the old style numbered modes. That’s why the WimpMode command at start up, to drag us kicking and screaming into the 21st century.

Though, it’s worth noting, that *WimpMode is exactly the same command as is used by Display Manager.

Hmm… might be worth looking at that file and at what Display Manager would set (iconbar menu → Mode) to see what the “F” value is. Perhaps, initially, the wrong timing is set which the Wimp remembers, and Display Manager fixes it by choosing a more applicable timing?
Just a guess, mind you…

So at first glance it’s not a hardware problem

Take a glance at the original thread , the colour change etc. is reportedly still there after a shift-boot, suggesting it’s not something inside !Boot causing the issue.

In that case it will have chosen some sort of default mode.

I’m really a bit stuck on the simple issue of return-from-F12 messing things up but Display Manager fixing them, given its pretty much the same thing that’s being done in each case.

The only difference is that in the F12 case, the Wimp is setting a cached mode (what it remembers as the current Desktop mode) whereas Display Manager is setting a specific mode. As I said at the end, I wonder if it’s a subtle difference in timing or something? Like 60Hz vs 75Hz? But, then, pressing F12 again ought to remember the newly set mode, so….?

Take a glance at the original thread , the colour change etc. is reportedly still there after a shift-boot, suggesting it’s not something inside !Boot causing the issue.

But surely if not booting, all the Window Manager has to go on is the Configured WimpMode – just a number – whereas the OP gets rid of the colour cast by using the Display Manager and setting a different, non-numbered, mode (probably not even available as a numbered mode?)

Hi all
I keep thinking it’s a palette problem.
@Rob,
Why do you use mode 31 in the configuration setup, this mode exists for compatibility with the BBC.

To test, try typing 31 in the MODE text field and if no change put the mode “auto” in the configuration.

Hi Folks,
@Jean-Michel: I have looked up that file VRAM which I have been aware of, but when I clicked on it to inspect it (ie no leading |‘s), I found I had ctrl/clicked on it to run it, instead of shift/click to load it into !Edit and that also produced the colour shift too. So just running the VRAM on its own will cause the colour shift. I have also found that if I enter 31 into the Display/Mode service it will drop back to a 800×600 16C mode, and no colour cast. But if I then use F12 it returns a horrid mainly yellow concoction. Going back to Display/’Mode cures it. Entering Auto into Display/Mode does not cause the colour shift, but the nasty yellow concoction returns on F12.

@Rick Murray: Once the colour shift has been caused only Display/Mode can fix it. Not even Configure/Screen, which also breaks it and causes the colour shift. I went through all the VRAM and NoVRAM files to put in the Chimei definitions manually (in RO4 etc). I am sure the Configure/Windows also caused the colour cast too, but now it doesn’t. (Edit: Double checked and Con/Win does cause the colour cast if an alteration to the settings is confirmed.)

The CMOS is holding settings and clock is losing a little time, but otherwise the battery seems ok. When I boot from a power off state I still have that really awful black boot up screen, but again Display/Mode comes to the rescue. When I Delete/Boot the CDROM disappears, and the Clock mode definition is lost, so it is not totally the same as power boot up where the CMOS settings are retained.

Thank you for your interest in this frustrating problem.
Cheers, Rob

If you leave the computer alone but instead unplug/replug the monitor cable does that change the picture? or turn the power off/on for the monitor? might help!

RISCPC RISCOS4.02

We’ll need to see if Charles notices this, of he has any input regarding screen handling on RISC OS 4…

…however, while the mode changing behaviour is a bit convoluted, the basic method of dealing with mode changes, either by a return from a single tasking app or using Display Manager, looks to be largely the same.

Indeed, Display Manager calls the WimpMode command to get the Wimp itself to do the change.

Hi Folks
@ Mike: Interrupting the monitor did not have any effect.

@ Rick: I can’t help but feel I have introduced some extra file or maybe “damaged” a file in the boot structure somewhere in initial experiments to get any image on the monitor at all. I have tried to be scrupulous to return all experiments to original, but the experiments may have rewritten other files that I am unaware of.

Plus the Chimei monitor maybe super sensitive and reacting in some way other monitors don’t.

My wife and I are off for a break and will be back in a few weeks. I will be still reading this thread for any comments but will be away from my machine to try any suggestions.

I will be happy to try a complete RISCOS 4.02 install when I return. I also have RiscOS 5.02 ROMs waiting in the wings as well. Now I have a workable Chimei MDF of a sorts working (99% confident it is usable), I maybe able to get a working monitor up quickly without causing other problems.

I truly appreciate everyone’s effort to help solve this. I had no idea I had such a puzzle on my hands.
Cheers, Rob

I can’t help but feel I have introduced some extra file or maybe “damaged” a file in the boot structure somewhere in initial experiments to get any image on the monitor at all. I have tried to be scrupulous to return all experiments to original, but the experiments may have rewritten other files that I am unaware of.

A couple of weeks ago it was suggested that you install a completely clean !Boot to avoid problems with incorrect files at boot. Did you do this?

Hi Andrew,
I was working with a clean RO4 install to begin with. I was very careful about experiments along the way. In another thread on this site people were talking about Display/Mode being a rather large chunk of old assembler code, and as a result not well understood. It appears to me to have some “secret sauce” that it uses when creating a monitor driver environment the other functions eg returning from F12 don’t have. It makes the correction of the colour cast look tantalising simple, though obviously it is quite obscure as no-one has hit on an explanation.

I would be happy to leave it if I can, and not solve it myself right now. I too have other unknowns I want to work on. I was hoping this problem was not just a good example of the fragility of the RO4 BOOT structure in general and still hope it can be debugged and not just reformatted away.

Thank you though, I can’t keep expecting others to to debug my own machine from afar. I am in great debt to all who have helped with progress thus far.

Cheers, Rob

128MB of SDRAM and a StrongARM card could be causing a timing issue on the Risc PC if the C32 capacitor has not been removed. I would not have expected the colour cast to be a symptom of this, things crashing or hanging would be more likely. However it is something to consider.

128MB of SDRAM and a StrongARM card could be causing a timing issue on the Risc PC

I’ve never seen this as a symptom of timing problems before, have you?

if the C32 capacitor has not been removed

Ahh, the fabled C32 removal, claimed to be the cure of all evils!

I only mention it as where I worked a long time ago had lots of Risc PC’s and parts were always being swapped in and from those in the field. One had somehow gained some out of spec PC RAM, and seemed to work correctly except for weirdness on the screen. So VIDC can get unhappy about memory timing, and large (for its day) multi chip memory modules can also upset an unmodified Risc PC – 2+2 may well be 5 in this case, but if Rob has some 32MB or smaller DIMMs he could try, that would eliminate it as an possibility.

That will be really worth a try. I have kept my original ARM CPU, RISCPC RAM, and my 1MB Video. So I can return it pretty much to original condition. The hard drive is about 22Gb. So plenty of room for trying out new !Boots as well. The two new SIMs I bought recently are a pair of matched 64Mb boards (ie same manufacture, from the one seller, so should be the same batch?). I previously had a single 128Mb SIM I bought C:2010, but the evil battery juices messed up the tinned connector. I had no complaints about it until I bought RO5 ROMs recently and anticipated a quiet nostalgic trip down Acorn Lane for a few quiet ones at the local Penrith ARMs Hotel.

No such luck, though still optimistic.✔️

But I will be away in Northern NSW for the next two weeks so unable to test your very welcome suggestions to try out. I will be reporting back ASAP.

Many thanks again for suggesting this new avenue of exploration. Other hints/comments still accepted too. I would love to know why Display/Mode corrects it 🤔
Rob

Thank you for your patience to all those who might be interested in this problem I have with the RISCPC.

To recap: I have tried the suggestion of using original hardware to eliminate the possibility of Strong Arm, plus 128Mb RAM may have been the cause of the colour cast. The original problem was the bluish tinge colour cast being triggered after an F12 session, or configuring the Screen monitor. In each case the colour cast can be removed by using the Display/Mode app at the right on the Icon Bar. I have found it useful to use Paint to create a 1024×768 sprite in 256 colours the palette of colours is on the screen. The colour cast is shown by the greys in the window bars becoming tinged with blue and the whole screen lightens generally. The photo is pretty accurate.

Following hardware suggestions above I tried the following:

I replaced the StrongARM with the original ARM CPU and the problem still occurred ( with 128MbRAM). I replaced the 128Mb of RAM (2×64Mb) with one stick of original Acorn 8Mb RAM and the same result. Pressing F12, and returning, caused the colour cast, Display/Mode fixed it.

I also noticed that with the 256 colour sprite opened and its palette on display that when I pressed F12, and returned, the colour cast with lighter colours and a bluish tinge occured, but otherwise superficially the palette looked properly distributed (though obviously incorrect). If I pressed F12 a second time, and returned, then colour 248 in the sprites palette had gone a bright yellow. Here is an image of the situation. http://www.laketyersbeach.net.au/RISCPC/T3_1.jpg If I used Display/Mode I can correct/reset the cast out, and it would then take two consecutive F12 sessions to turn colour 248 into yellow again. So there is something cumulative happening.

I had also taken the precaution to re-install RISCOS 2.04 over again to get as clean a starting point as possible. The installation went smoothly and booted OK though power on booting results with the screen looking like this: http://www.laketyersbeach.net.au/RISCPC/RISCPC_01.jpg Using Display/Mode fixes it. this is not good.

Using the Reset button to reboot, or gui Restart, the almost normal screen eventuates, but with the colour cast. The clock and CMOS settings are running OK.
Any suggestions will be appreciated to get this kink out of my RISCPC system. It does not appear to be a hardware fault as Display/Mode fixes it 100%, but there is some magic code missing in the rest of it eg return from F12, or some bad code that runs instead.

Cheers, Rob

Hi Folks,
I have probably worn out my welcome in this thread, so I appeal to my previous readers to read the above post. It outlines how F12 causes a bluish cast (on return) and if that is repeated with a 256colour sprite palette displayed, colour 248 is returned as yellow. Using the Display/Mode function lower right on the Icon Bar, the colour palette is cleared and the cast disappears. This is some new information.
Is it possible the CMOS is corrupt but not completely reinitialised with a Delete plus power-on re-boot? Such that on each power on it detects corrupt CMOS and does a “reset CMOS” (ie either does part of it, but not all of it, so some remains corrupt). Is there a program that dumps the complete CMOS in Hex?
Currently the !Boot works without reporting any faults (though apparently it does not reveal to the user all problems it runs into). However !Boot/Configure runs fine and all options work as expected. Though Screen causes the colour cast).
Anyway I will repeat myself and bore you to death with any more.
Best wishes, and thank you if you have any suggestions,
Rob

Is there a program that dumps the complete CMOS in Hex?

It’s relatively easy to write one for yourself. Just call OS_Byte 161 for each of the first 240 bytes of CMOS RAM.

If that sounds like too much work, save the current CMOS settings via *SaveCMOS and then open the saved file in your favourite hex editor (either StrongED or Zap will do this).

FWIW, I have been tinkering with a (single-tasking) program that reads the contents of a saved CMOS file and attempts to decode the contents: output is to a plain text file, not the screen. I’ve also been wasting my time constructing a StrongHelp manual with as much detail as I can find on the usage of individual CMOS RAM bytes – the aim was to augment the wiki page rather than replace it. Distinctly unofficial and E&OE of course, but I could email either (or both) if you are interested.

I don’t think you are going to get any further until you can work out which piece of equipment is at fault. Does the Risc PC exhibit this issue with a different monitor, and does monitor does exhibit this issue with a different computer – such as a Raspberry Pi running RISC OS with the same monitor definition file.

Thank you Stuart, I will explore the *SaveCMOS option first. I guess I can run it at different time in the boot to monitor changes. If I find changes I can’t explain I will contact you.
Also thank you David. I have a 4:3 Phillips I can swap in to check. I have the Phillips MDF’s that come with RO5 to try. I did create the Chimei MDF from running the monitor with a RPi and scraping it. So it is a back of sorts. I will try the Philips definitions with the Philips monitor.
Thanks Foks, I will report back, Rob

If you have to use a different MDF with the 4:3 monitor, it the problem many not show up anyway. It really needs to be a like for like swap, and with an MDF which works on both.

Hi David,
If I recall corectly I was using the Phillips (170S?) definition with the Chimei before someone suggested trying to get an MDF for the Chimei from a RPi+HDMI-VGA adapter set up. I will go back and double check. If I found any monitor/RISCPC combination now that was 100% I would take it and move on. The Chimei does a larger screen though, and can do the 1280*1024 with 32k colour quite nicely, but with all the above booting and colour cast problems as well(ie looks very nice after a Display/Mode refresh, however F12 line is also not shown, so not quite perfect).

Many thanks David for your interest in this ongoing problem. If the display after Display/Mode refresh did not look perfect I would have given up ages ago. The hardware appears to be able to do it, just not when booting (really bad) or after F12 (colour casting) etc

Cheers, Rob