Make AnyMode settings persistent on RPCemu

I have placed the AnyMode module within $.!Boot.Choices.Boot.PreDesk and it is available from startup, setting the resolution with:

*WimpMode X1600 Y900 C256 works as it should do.

But attempting to do:

*Configure WimpMode X1600 Y900 C256 gives the error “Numeric parameter needed”

Each time I restart RPCemu RISC OS opens up in 800×600.

How do I set RISC OS to open in 1600×900?

Use the Configure application, Screen, to set the screen mode?

I’m not sure if the Configure app will work correctly with AnyMode. But you manually add the correct WimpMode command to !Boot.Choices.Boot.PreDesk.Configure.Monitor (that’s the main file that the screen setup plugin will modify)

Jeffrey was right, the Configure application doesn’t work with AnyMode, but adding it manually worked perfectly.

Thank you,
Andrew

Jeffrey was right, the Configure application doesn’t work with AnyMode, but adding it manually worked perfectly.

Useful to know. Did you put in a frequency parameter out of interest?

Whoops – framerate!

@John Williams

Sorry for the slow reply. I didn’t put a frequency parameter.

!Boot.Choices.Boot.PreDesk.Configure.Monitor

is as follows:

LoadModeFile BootResources:Configure.Monitors.Acorn.AKF60
WimpMode X1600 Y888 C16M

The Y888 (rather than Y900) is so that the vertical resolution is a multiple of 8 to ensure that the command line scrolls correctly. I can’t notice any visual difference from the native resolution myself.

896 is also a multiple of 8

Putting ‘AnyMode’ 0.6 in RPCEmu Poduleroms – gets the module loaded – but when listed in *Rom. it is dormant.

Any ideas?

[Edit 1]

Is ‘AnyMode’ supposed to work with VRPC-DL?

Hmm with a little mod – it seems too.

Looking into ‘AnyMode’ seems to need a different checking method- bypassing the check – it now starts from ‘PoduleRoms’ Dir in RPCEmu.

[edit 1]

Is there a module called ‘BCMVideo’ on the ‘pi’?

Is there a module called ‘BCMVideo’ on the ‘pi’?

Yes, and BCM Support and BCMSound.

Is there anyway of a module loading from ‘PoduleRoms’ checking out whether certain modules are loaded when the Init code is called?

Like say the – 32bit ‘SharedCLib’ module.

[edit 1]

Is loading in different order – ie CLib before the module that uses it – does this come into play?

When do the modules come on line to ans ‘OS Module 18’ ?

[edit 2]

Could there be a numbered mode added to R05 – for ‘1024 × 768 C256 f60’ – handy for when starting up with no boot being run.

Is it possible to add a ‘Number Modes’ module – like it used to be.

Is there anyway of a module loading from ‘PoduleRoms’ checking out whether certain modules are loaded when the Init code is called?

Depends upon what exactly you want. For looking up the existence of a given module…

https://www.riscosopen.org/wiki/documentation/show/OS_Module%2018 ?

Like say the – 32bit ‘SharedCLib’ module.

However, for this, I’d look up the SWI SharedCLibrary_LibInitAPCS32 (or something like that, I’m writing this on my phone). It’s a SWI specific to the 32 bit compatible CLib. If it replies with the correct SWI number, then the SWI exists and therefore so does 32 bit CLib.

Is loading in different order – ie CLib before the module that uses it – does this come into play?

I can’t recall, I think ROLtd mucked this about with priority flags… but generally speaking the OS will begin initialising by scanning the module chain and all extension modules to work out which available module is the latest. For example if you have put BASIC v 9.99 into an extension ROM then this will be loaded in preference to whatever may be in the ROM image with a lower version number.
Then it’ll initialise the modules in the order that they are located in the ROM (I am guessing that podule replacements are loaded in the place of the ROM modules that they replace). This is because early initialisation has a very specific order, for example you need the kernel first. Then you need FPE before CLib which comes before anything written in C, etc. So unless you’re replacing something, a podule module will likely be executed at the end of the initialisations.

When do the modules come on line to ans ‘OS Module 18’ ?

Once their Init code has been executed, at which point they’ll be present in the module chain. The PRM states, of the initialise call: During initialisation, your module is not on the active module list, and so you cannot call SWIs in your own SWI chunk. Instead you must directly enter your own code so I would imagine the name lookup to be valid after initialisation, not before or during. In the case of any module, those initialised before it will be present and valid.

Could there be a numbered mode added to R05 – for ‘1024 × 768 C256 f60’ – handy for when starting up with no boot being run.

No. Because I’d want a 1280×1024 mode to fit my Pi’s monitor, plus 1440×900 for the PC (emulation), and then of course everybody else would want their preferred modes to be a simple number and not gibberish, and… :-)

Plus, there’s the problem that if anybody uses said mode for images/sprites, it will have no correlation on other systems. This was a big problem in the early days of DTP when Ovation and Impression both came with modules that added extra screen modes to maximise the available space on TV-resolution monitors (as were common in those days). Any images created while in such a mode would only be usable if said mode was present via the relevant extension mode module. And if somebody else’s modes module had a different geometry to the same mode number, expect some really freaky results as the OS interprets the data incorrectly…

The way I fixed this on my Pi was to include a 1280×1024 mode into the default mode set (instead of the rather restricted set of modes that are built in by default) and then change the OS to select that mode instead of trying to start up in 1080p.
But… is this still relevant? Doesn’t EDID these days teach the OS what modes the monitor supports, and automatically selects the most appropriate? Probably wouldn’t help with RPCEmu (unless some mechanism could be added for the emulator to report the resolution back to RISC OS?)…

Whenever I need to get to a known mode outside of the normal boot sequence, I just use MODE 28. 800×600 in 256 colours, it’s “good enough” for command line use.

Is it possible to add a ‘Number Modes’ module – like it used to be.

Mmm, I don’t see why not?

I have used a utility on my windows 7 laptop to save a file of the edid data from the built in display. If I drag this file onto the display manager icon in RPCemu it reads it and behaves correctly. There doesn’t seem to be a way of exporting this as an MDF. It strikes me there could be a module in podule roms to read this data and feed it to the display manger directly.

Thanks for the pointer Rick.

That was interesting – now got it to work ok loading from ‘PoduleRoms’ with RPCEmu & ‘Chunks’ with VRPC-DL.

Seems the module checking code was getting upset by a bad swi &1E pointer :-(

By adding another check for VRPC upset it.

Seems no error number before msg :-(
So using ‘swi Module &12’ now works ok.

So does the SWI String To Number – giving a error if there is no swi of that name.

Only – the way RPCEmu loads the Podule ROMs – AnyMode’s needs something like a ‘V’ in front so it loads after the RPCEmuHostFS module.

Added RO4.02 fast Service support.

Looks a interesting module.