Large screen modes under 5.19?

After talking to Ben & Sprow at the MUG Show yesterday, I brought my RPCemu install up-to-date and ROS 5.

In RPCemu, under 4.02, I’ve got a ViewSonic VA2212W monitor definition which gives 1680×1050, 1920×1050 and 1920×1080 screenmodes.

However, on 5.19, this’ll only go up to ~1440×900.

I can see that Boot:Choices.Boot.PreDesk.Configure.!Run has a suitably high VIDCBandwidthLimit, so what could be the difference?

Thanks in advance,

Andrew

has a suitably high VIDCBandwidthLimit

Currently that’s just tacked in place with staples because the boot sequence is really that from an Iyonix, hence the large bandwidth numbers. It sets the memory bandwidth limitation.

However, the mode is also vetted to check it can vagely be achieved on VIDC and at (say) 60Hz for 1920×1080 that’d be 124,416,000Hz pixel clock which is out of spec.

Since you’re emulating flicker is unlikely to be emulated, so you could try just dropping the frame rate.

Since we’re already supporting 8MB of VRAM for RPCEmu, could the video driver just disable most/all of the timing limitations when 8MB of VRAM is detected? (I’m assuming it’s impossible for a real RiscPC to have 8MB of VRAM, otherwise we would have had 8MB upgrades a long time ago)

Note that this may be a bit more involved than just disabling the checks in VIDC20Driver, as I’ve seen some code in the ScreenModes module which checks for the presence of VIDC and uses its own rules instead of/in addition to asking GraphicsV. So that could probably do with being updated to disable its own checks entirely when on RISC OS 5. ScreenModes is also responsible for VIDCBandwidthLimit, IIRC.

otherwise we would have had 8MB upgrades a long time ago

I’m pretty sure you’re right (and would be surprised if you weren’t TBH): "The Risc PC can have up to three different screen memory configurations, no VRAM (DRAM only), 1MB VRAM or 2MB VRAM." AFAIK there were no third party workarounds.

ScreenModes is also responsible for VIDCBandwidthLimit, IIRC

My suggestion to drop the frame rate was merely an attempt to avoid up front code changes. VIDCBandwidthLimit is perched at the edge of a gang plank and might well get kicked overboard (or at least made into a no-op) when I pick through the boot sequence. It should probably be up to GraphicsV to police.

VIDCBandwidthLimit is perched at the edge of a gang plank and might well get kicked overboard (or at least made into a no-op) when I pick through the boot sequence.

That’d be nice. There certainly were a few anachronisms I found picking through !Boot to get a combined version for 4.02 and 5.19.