1280x768 Resolution

I’m sure this has been covered previously but cannot find any references or useful information.

Can anyone advise me how to get a resolution of 1280×768 in RPCEmu? Currently working with 1024×768 which leaves big black borders on the sides of the display…

Have you installed the AnyMode module in Boot.Choices.Boot.PreDesk? From memory, once you’ve done that, you can simply open a Task Window and they type Wimpmode x1280 y768 C32k. I don’t know if the latest ROMs with EDID will work with RPCEmu. I can’t access a copy of RPCEmu at the moment, but there may also be an MDF somewhere in Boot.Resources.Configure.Monitors that will allow it as standard.

I believe ‘AnyMode’ has only ever worked on a Pi ¹ which previously didn’t support mode timings. AIUI AnyMode provides no timings and relied on the GPU doing its own EDID. Recent Pi builds now support Mode timings (a very useful improvement!) unfortunately support for modes with no timings was removed. I hope it is reinstated soon.

¹ It can also be used with RPCEmu only I’ve just read!

I don’t know if the latest ROMs with EDID will work with RPCEmu

The ROMs will work, but you won’t be able to get EDID from the “monitor” because the VIDC hardware doesn’t support reading EDID.

Recent Pi builds now support Mode timings (a very useful improvement!) unfortunately support for modes with no timings was removed. I hope it is reinstated soon.

If you want, you can switch back to the old behaviour by adding the string “disable_mode_changes” to cmdline/txt in the Loader partition (create the file if it doesn’t exist) and then rebooting.

Why do you want to see the feature reinstated? If we can get a better idea of how/why people were using AnyMode then that will help with planning future work, so that we can eventually arrive at a “best of both” solution.

Why do you want to see the feature reinstated?

I’m not sure exactly what this is about, but I’ve got “disable_mode_changes” so I can have my own defined modes beyond 1920×1200 – a whole range of them right up to 3840×2160 (at 24Hz), all working beautifully (but with the GPU clocking ~20% faster than spec, iirc).

I think the beauty of “AnyMode” was mainly in conjunction with ADFFS that, no matter what creative resolution a game requested, it “just worked”.

Apart from 1920×1200, all the modes I’m using are 16:9. I just like being able to choose where on a scale to pick the compromise between lots of detail and bigger icons, depending what I’m doing.

I’d echo Steffen’s comments. AnyMode and the Pi GPU strangeness are a brilliant pair for getting old fashioned resolutions working on modern screens.

If RISC OS were to one day include an automatic upscaler (with doubling for rectangular pixels) then happy days!

One “creative resolution” is RISC OS’s own teletext emulation, which a few people might want to use by asthetic choice. Some transparent solution as an fallback if the monitor can’t deliver would be nice to have. In short, I agree with Steffen.

I’m not sure exactly what this is about, but I’ve got “disable_mode_changes” so I can have my own defined modes beyond 1920×1200 – a whole range of them right up to 3840×2160 (at 24Hz), all working beautifully (but with the GPU clocking ~20% faster than spec, iirc).

In your case, you could probably do without disable_mode_changes if you were able to construct an MDF (or custom EDID block) containing valid mode timings for all the modes you use. But the “if” is the key part here, since our current MDF authoring tool (MakeModes) is a bit outdated. At the least, it could do with extending to add support for generating timings using the GTF and CVT algorithms, so that you only need to specify the width+height+refresh rate.

If RISC OS were to one day include an automatic upscaler (with doubling for rectangular pixels) then happy days!

That’s basically what I was hinting at when I raised the question. AnyMode only works on the Pi and RPCEmu, and doesn’t take into account things like differing refresh rates or aspect ratios. A solution that’s built into the OS should be able to improve on that.

One “creative resolution” is RISC OS’s own teletext emulation, which a few people might want to use by asthetic choice. Some transparent solution as an fallback if the monitor can’t deliver would be nice to have.

In preparation for the arrival of EDID, I did make some improvements to the teletext emulation, to bring it closer to the flexibility offered by RISC OS Select. In particular, the OS will try a series of different fallback modes if you try selecting mode 7 but the custom 640×500 mode definition isn’t available. It’s not perfect (e.g. if you’re in a fallback mode then reading back the mode number won’t give a result of “7”) but it should work for the majority of cases.

https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Kernel/VersionNum#rev4.118

We use a ‘no timings MDF’ for the pi-top display. I don’t think it supports EDID and there is no data sheet available or source code for the Linux driver (It was promised at the launch but they backtracked and would give us no information at all). From experience getting MakeModes to produce a usable MDF is time consuming and while the Pi’s GPU does such a good job it seems a waste of effort. Whilst I appreciate that having a way of supporting 99% of uses in the OS is the best, I’d hope that it would not be a lot of work to add a check for all timing are zero so “disable_mode_changes”. Some ‘users’ are are not up to fiddling with Loader partition files!

Hmm, yeah the pi-top (and lapdock) are a bit of a tricky case.

This mailing list message suggests that the Pi-Top does have EDID (which is what I would expect, since the Pi’s firmware is heavily reliant on EDID) but it may only list one mode (1366×768). And 1366×768 isn’t a mode that works with RISC OS yet (due to framebuffer pitch/padding issues within RISC OS, much like those mentioned on the linked message).

Long-term I suspect the best behaviour for the Pi-Top would be for the OS to drive the LCD at 1366×768 and rely on the GPU to scale the RISC OS screen output, much like disable_mode_changes. It’s just a question of finding a suitable way to represent that within the MDF/EDID system.

In preparation for the arrival of EDID, I did make some improvements to the teletext emulation, to bring it closer to the flexibility offered by RISC OS Select. In particular, the OS will try a series of different fallback modes if you try selecting mode 7 but the custom 640×500 mode definition isn’t available. It’s not perfect (e.g. if you’re in a fallback mode then reading back the mode number won’t give a result of “7”) but it should work for the majority of cases.

I have underestimated you again, sir. :D In my defense, I only recently started using my RISC OS Pi again.
On a slightly unrelated note: Could the numerical form of BASIC’s MODE command be extended to set other aspects of a mode like colour order and eigen values?

Can I confirm something… I have my Pi hardwired to 1280×1024 via mode selection in the config.txt file. The Pi itself then has a variety of modes available, none of them with timings, and when RISC OS goes into a different mode, the GPU just rescales it to 1280×1024.
As such, my Pi outputs a solid video signal with no problems, unlike the Beagle xM that really doesn’t behave nicely with the HDMI to VGA adaptor.

Question is – is it still possible to keep this behaviour? To have the GPU run at a fixed size and fake everything else by scaling?

I suspect “disable_mode_changes” (=1?) is it, but then what will RISC OS do with an MDF that has dummy values for everything except the size?

Question is – is it still possible to keep this behaviour? To have the GPU run at a fixed size and fake everything else by scaling?

Yes.

I suspect “disable_mode_changes” (=1?) is it

Just disable_mode_changes.

but then what will RISC OS do with an MDF that has dummy values for everything except the size?

It will accept it as valid.

disable_mode_changes isn’t a GPU thing; cmdline/txt is intended to be used for specifying Linux kernel boot args. RISC OS isn’t Linux, but we can still use the feature as an easy way of getting arbitrary configuration parameters into the HAL/OS.

our current MDF authoring tool (MakeModes) is a bit outdated

I wasn’t aware it existed. I write them manually in StrongEd (used to do it in Zap), have done for about twenty years. It’s a lot easier now that everything’s dummy values except the size!

I have my Pi hardwired to 1280×1024 via mode selection in the config.txt file. The Pi itself then has a variety of modes available, none of them with timings, and when RISC OS goes into a different mode, the GPU just rescales it to 1280×1024.

Me too likewise – except that mine’s hardwired to 3840×2160@24Hz.

What is the best option for 4 colour modes.
I think the Ti manages 4 colours.
There is module called PixDoubler for running low res games – is there anything like it to display 4 colour modes?

I’ve just installed AnyMode and its working beautifully so thanks everyone! :—)

What is the best option for 4 colour modes.
I think the Ti manages 4 colours.

Correct, Titanium supports 2bpp (4 colours) on the primary head. In the desktop this is offered as 4 greys by Display Manager (because the mouse pointer is overlaid in hardware, it’s still its usual blue colour), but can be reprogrammed to any 4 colours using the palette too.

Thanks.

What does the little BASIC prog produce – with the ‘Ti’?

Anyone want to try the Sib7 demo with the ‘Ti’?

 x%=&2800-4

 DIM R6 x%

SYS “OS_ScreenMode”,2,0,0,0,0,0,R6,x% TO R0,R1,R2,R3,R4,R5,R6,R7

What does the little BASIC prog produce – with the ‘Ti’?

A hex number. But the number can’t possibly answer any question you have because it’s merely saying how many bytes are left in the buffer, and since the buffer contains the names of the modes in the currently loaded MDF, and that varies depending on which monitor is plugged in, that hex number means nothing.

Can you rephrase the question to ask what it is you’d like an answer to? If you have pre-sales technical questions feel free to contact Elesar directly, or pose the question on a Titanium related thread here (it’ll be lost in the RPCEmu forum).