Display mode issues after updating to 5.28, RPi 1

Probably missing something here… updated to 5.28, and I’ve lost the display mode I was using, which is from my monitor’s EDID.

The mode in question is a VESA-specified pre-GTF 1600×1200 85 Hz mode, which exceeds the default bandwidth limit of a Pi 1. My config.txt contains the following:

fake_vsync_isr=1
framebuffer_swap=0
gpu_mem=64
init_emmc_clock=100000000
ramfsfile=CMOS
ramfsaddr=0×508000
kernel=RISCOS.IMG
hdmi_pixel_freq_limit=300000000
hdmi_blanking=1
hdmi_group=2
hdmi_mode=55
hdmi_drive=1

And the relevant mode from the EDID (saved in MDF form):

# Mode: 1600 × 1200 @ 85Hz
startmode
mode_name:1600 × 1200
x_res:1600
y_res:1200
pixel_rate:229500
h_timings:192,304,0,1600,0,64
v_timings:3,46,0,1200,0,1
sync_pol:0
endmode

I’ve tried adjusting the VIDCBandwidthLimit in Choices:PreDesk.Configure.!Run to 3000000000 instead of the default of 2000000000 in case that was my problem, and rebooting, but no change – the mode I want isn’t available, and trying to force X1600 Y1200 C16M F85 still returns “This screen mode is unsuitable for displaying the desktop”.

Any idea what I’ve missed?

(And yes, this is a CRT going through an HDMI adapter, hence wanting the 85 Hz mode specifically – otherwise I’d just use a reduced blanking 60 Hz mode and be done with it.)

…think I know where the problem is, and it’s the RPi Foundation’s bug, I think.

https://github.com/raspberrypi/firmware/issues/1406

RISC OS can’t get hdmi_pixel_freq_limit (verified with *vcgencmd get_config hdmi_pixel_freq_limit using both the firmware shipped with 5.28, as well as the latest firmware from the RPi firmware repo), and therefore is falling back on what it knows. And, because it’s not a Pi 4, it knows 162 MHz, which obviously won’t work with a 229.5 MHz mode. (If it were a Pi 4, it’d set it to 300 MHz and everything would be happy.)

Skimming through the BCMVideo sources, I’m not seeing any convenient way to override this limit and set MaxPixelClock from within RISC OS, am I correct?

And for a final post, my initial attempt to fix this was to do a quick binary patch of RISCOS.IMG (replacing offset 0×234F40, which contains the value 0×09A7EC80, with the value 0×11E1A300 – basically forcing the default MaxPixelClock in BCMVideo to something acceptable for me), but couldn’t get it to sync – the monitor was reporting a significantly lower refresh rate when it was partially locked on, as well.

I then verified that the mode was equally unstable in Raspberry Pi OS, where the workaround I had attempted was unnecessary (I assume they’re working around the bug), so there’s a bigger problem in my case than just this bug.

…so now I’m running the January 2019 firmware with 5.28. Seems to work as a workaround, vcgencmd works as expected, it allows the desired mode as expected…

(Worth noting that I had to run that firmware on 5.24, as well, my Pi doesn’t like booting with the firmware shipped with 5.24.)