!Dozer Screensaver

There is screensaver program called !Dozer that can be downloaded from the package management program – PackMan. The BASIC program is activated by moving mouse into a screen corner (selected by user in !Run file). Each graphic routine will run sequentially or randomly or chosen using CTRL+keypad number. Unfortunately non of the graphic examples seem to run – each creating error: “Screen mode not available in Library” on my ARMX6. Has anyone got it to work on RISC OS 5.29 (03-Nov-20)?

Richard have you read the file called IMPORTANT within the !Dozer application? It advises you need to change a setting in the !Run file.

Indeed I have Chris by implemented the line pointing to SaversMX6 directory but still get the error.

Be interested in hearing from anyone who’s got it to work.

The note in IMPORTANT is junk, the decision is made in Line 4 of !RunImageX.

B$="<Dozer$Dir>.SaversMX6":SYS88,8 TOb%:IF b%=1 THEN B$="<Dozer$Dir>.SaversRPC"

I can get some signs of life on RPCEmu, but only some!

The problem looks to be that, bizarrely, the screen savers set their own modes. A bit more digging would be needed to see why that is going wrong.

The problem looks to be that, bizarrely, the screen savers set their own modes.

Probably easier to whizz stars around the screen if you know you can drop to an 8bpp mode to treat each pixel as a byte.

Not so useful if the desired mode is not available, and there’s no fallback.

SYS88,8 TOb%:IF b%=1

Read platform class from OS_ReadSysInfo. 1 is a RiscPC.

Given that 5 is HAL, wouldn’t this test fail if using RISC OS 5 on RiscPC era hardware?

Sometimes the screensavers work, other times I get "Screen mode not available in “Library”.

Ah, here we go. It looks like several of the MX6 screensavers (what I’m using) start up with

PROCLIBmode(1920,1200,5)

That’s a weird size, and not a mode that I have in my definitions.

That’s a weird size, and not a mode that I have in my definitions.

It is a weird size, but I think there must exist monitors for whom it’s native, since for some reason (I forget now what) it’s among the sizes I made in my mode definition files. It works, and the Pi’s GPU kindly scales it to 3840 × 2160 for me.

Hmm, changing Aurora to 1920×1080 (I use GPU scaling) crashed the machine. The sort of behaviour I’d expect if it was double/triple buffering but didn’t restore the screen banks on exit… only I don’t immediately see any calls to OS_Byte 112,113,114…

Going any further would be a deep dive, and I have been staring at code for most of the afternoon, so I’m going to go make fish and chips instead. ;-)

Given that 5 is HAL, wouldn’t this test fail if using RISC OS 5 on RiscPC era hardware?

RPCEmu returns 5, so it would fail on RPCEmu at least.

It is a weird size, but I think there must exist monitors for whom it’s native

I’m using two of them as we speak :)

1920×1200 is the 16:10 variant of full HD, so not that uncommon. If you change the size of standard Full HD, you’ll have to look carefully for comparisons with 1200 (or 1199, often in hex if assembler) and change them to 1080, or the code may write off the end off the screen.

SYS88,8 TOb%:IF b%=1 THEN B$=“<Dozer$Dir>.SaversRPC”

Changing the comparison to ‘5’ puts the RPC savers on the case on RPCEmu, and they work.

On the Titanium, with its 1920×1200 AOC monitor, ‘LTRGB’ needs adding to the Mode change procedure. Some are working there now. Any savers thinking they are going to start up in 256 colours are wrong though!

Of the iMX6 savers all are 1920×1200, except Star++ which is 1280×800. That will be the original problem, wrong size monitor.

Of the iMX6 savers all are 1920×1200

Throttling back to 1080 works here on the Titanium. The Mode is defined near the top of the saver BASIC.

(I can’t get Star++ to work even after adding an MDF entry for it.)

Simply changing all saver code to start up in PROCLIBmode(1920,1080,5) to match my monitor definition (1920×1080×16m cols) ensures the program works (thanks for that David).

Not sure why you can’t get Star++ to work. Is there mileage in modifying Star++ to work stand alone – ie without references to the library. Seems programmer has tuned it for specific machines.

Best way to test all savers is to set the delay in the !Run file to 10 seconds (Set dormant 10) and set the “Screen saver – Blank delay” to Off under Boot > Configuration > Screen. After testing, to stop Dozer constantly interrupting your work reset the delay to 30 minutes (1800 secs).

A favourite is star++. An intricate ever changing star like pattern. My absolute favourite is +Bouncy. This is the best ball collision routine I’ve seen. Not an easy thing to code reliably – objects often stick to each other in other examples.

Would be nice to incorporate the savers into…
Boot > Configuration > Screen > Screen saver
but I fear this would involve a lot of work – is anyone feeling confident enough to do this just for my favourite, +Bouncy.

Not sure why you can’t get Star++ to work.

A bit more WimpSlot, 32k, was needed, on the Titanium. The simpler RPC version was OK on RPCEmu.

Impressive!

Glad you got it to work.

As an experiment, copied !Dozer to Raspberry Pi – RISC OS 5.28 (16-Dec-20). Savers don’t render nearly as well compared to ARMX6.

Results as follows:

+Bouncy: Poor colour rendering, screen flashing/jitter.

Meteors: Top part of screen missing.

Star++: Effect spoiled by intermittent sudden variation in brightness.

Screen buffering problems perhaps: first one uses triple screen buffering, the other 2 use double screen buffering.

Other effects seem to run OK.

I have had a very quick look on the RPi4. Savers trying to set a 32k colours Mode, 4 in the Mode selector, either fail with “Screen mode not available” error or, in the case of Bouncy, by stiffing the Pi. Meteors, two banks, does not start. The three that are left, Aurora+, Snow+ and Spiro, are just fine.

(AnyMode is not in use here.)

The Pi4 doesn’t support 32K colours, it does support 64K colours which you can select using MODE X,Y,16

The Pi 4 does support 32k colours if you use disable_modechanges as the GPU will convert as necessary. It was a retrograde step when the GPU was not allowed to do its stuff for RISC OS.

The Pi 4 does support 32k colours if you use disable_modechanges as the GPU will convert as necessary.

I’m fairly sure that’s wrong.

It was a retrograde step when the GPU was not allowed to do its stuff for RISC OS.

Indeed. My monitor is old (1280×1024) and can in no way cope with the vast selection of modes that the Pi can output… and I’m not sure I have anything here that is really up to displaying the default FullHD mode that the Pi starts up in. The analogue monitors cannot, and whilst the HDMI LCD panels can, given that one is ~3.5" and the other is ~7" they’re hardly going to be readable at that sort of resolution.

With a fixed constant 1280×1024 to my monitor and the GPU dealing with all of the scaling, pretty much everything is visible. The GPU does a good job of scaling stuff to fit. And, an extra bonus, mode changes are immediate, not a case of the monitor scratching it’s arse for eight seconds while it tries to work out what sort of signal it’s getting now.

I understand that it’s more flexible to let RISC OS control the GPU directly, and it can allow some things to be fine-tuned (perhaps important for those insanely large modes?), but the default still ought to be “the GPU deals with it”, because that way works quite solidly.

This is what is required to persuade the 32k colours savers to light up on the Pi in 64k colours.

REM out the call to LIBmode and call MODE directly.

For Facets :-

REM PROCLIBmode(1920,1200,4)
MODE "X1920 Y1200 C64K LTRGB F60"

For Star++

REM PROCLIBmode(1280,800,4):REM '4' means 32K colours
MODE "X1280 Y800 C64K LTRGB F60"

Having also added a correspondimg entry in the MDF :-

*cvt 1280 800 60

# 1280 x 800 (60.00Hz) 32bit (CVT)
startmode
mode_name: 1280 x 800
x_res:1280
y_res:800
pixel_rate:83500
h_timings:128,200,0,1280,0,72
v_timings:6,22,0,800,0,3
sync_pol:3
endmode

Tested on RPi400.

The LTRGB flag can also be added to the Mode selector block in PROCLIBmode in !Dozer.Library as follows.

S%!12=C%:S%!16=-1:S%!20=-1:REM terminate with -1
IF C% = 4 THEN
  S%!20 = 0
  S%!24 = &40C0
  S%!28=-1
ENDIF
SYS"OS_ScreenMode",0,S%:REM now change Mode
ENDPROC

Also tested on the RPi400.

One catch is that we finish up machine specific code. Another is that if the Pi is already at a 64k colours desktop then the LTRGB flag needs to be unset to for the 32M colour savers to work.

There should be a way to ask the machine what flags are required for the mode about to be used.