ROOL Forum: Recent Posts

Colour Cast

Tue, 16 Aug 2022 11:39:45 -0000

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

Colour Cast

Tue, 16 Aug 2022 10:34:35 -0000


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.

Colour Cast

Tue, 16 Aug 2022 07:32:41 -0000

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!

Colour Cast

Mon, 15 Aug 2022 22:24:02 -0000

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


Mon, 15 Aug 2022 19:21:32 -0000

Doesn’t specify, but usually when a struct is defined, it’s listed as defined (useful for those using BASIC!).

See also RFC 3493, so non-compliance would be a peculiar, and potentially problematic (if applications built from different headers gave the struct as having data in different places).

SDFS and eMMC-SD Devices

Mon, 15 Aug 2022 17:41:59 -0000

Oooh! That does sound promising that eMMC support has been added to the Pinebook.
Hopefully it’ll filter into the Pi ROMS too.


Mon, 15 Aug 2022 17:36:34 -0000

The <netdb.h> header shall define the addrinfo structure, which shall include at least the following members:

int               ai_flags      Input flags. 
int               ai_family     Address family of socket. 
int               ai_socktype   Socket type. 
int               ai_protocol   Protocol of socket. 
socklen_t         ai_addrlen    Length of socket address. 
struct sockaddr  *ai_addr       Socket address of socket. 
char             *ai_canonname  Canonical name of service location. 
struct addrinfo  *ai_next       Pointer to next in list. 

Doesn’t specify that they are in that order though?

Although it would be rather helpful if they stayed in the same order as before on our platform…


Mon, 15 Aug 2022 17:28:27 -0000

Same order with bsd, it’s a POSIX definition.

Have you raised a bug report?

Incidentally… it would be nice if Resolver could handle DNS-SD and the ability to look up SRV records (that is to say, given “thisthingy.local”, to return an IP address and a port).
These are, by the way, standard modern DNS behaviours… I can dream, right? ;)

Haskell on Risc OS

Mon, 15 Aug 2022 16:45:43 -0000

I’ve managed to make a module using jhc. I can’t make it runnable though, and RMKill goes wrong.

I can call (say through a *-command) functions like

Test1 :: CInt -> CInt
Test2 :: CString -> IO ()

however jhc won’t let me export a function

foreign export ccall "test3" test3 :: IO (StablePtr [Int])

which is bad as I was hoping to hold some Haskell data like a [Int] as the module’s global variable.

Maybe they never actually finished putting in support for StablePtr in jhc?


Mon, 15 Aug 2022 15:39:00 -0000

There is an incompatibility between the new lib and the ROD Resolver.

ROD Resolver_GetAddrInfoAsync seems to follow the classical Linux format:
struct addrinfo {
int ai_flags;
int ai_family;
int ai_socktype;
int ai_protocol;
socklen_t ai_addrlen;
struct sockaddr *ai_addr;
char *ai_canonname;
struct addrinfo *ai_next;

in the TCP-IPBeta1, the the order of elements ai_addr and ai_canonname are inversed.

SDFS and eMMC-SD Devices

Mon, 15 Aug 2022 09:58:17 -0000

eMMC on the Pinebook was added pretty recently, I’m not sure if something similar needs doing to support this?