Some legacy screen modes have unexpected text resolutions
Stuart Painting (5389) 709 posts |
The revised mode substitution logic introduced in RISC OS 5.27 does a good job of selecting the nearest available pixel resolution to a legacy (i.e. numbered) screen mode. What it doesn’t do so well is pick an appropriate text resolution. The following figures were obtained with a Raspberry Pi 4B, RISC OS 5.28 and an Acer B247Y monitor:
Three of these text resolutions (mode 9, mode 48 and mode 52) are significantly adrift from the expected values, and a further three (mode 35, mode 39 and mode 46) could do with a tweak in the Y-axis. Some of this might be due to the Raspberry Pi not supporting rectangular pixels, but is that a complete explanation? I readily appreciate that spending a lot of time reworking the algorithm (to produce the best possible eigenvalues) may not be the best use of scarce resources, so I will understand if this is marked as “close enough for government work”. 1 The mode string as reported by Display Manager. |
||||||||||||||||||||||||||||||||||||||||
Rick Murray (539) 13750 posts |
They’re also significantly adrift from the resolutions. MODE 9 is reported as “X720 Y400 C64 EX2 EY2” when it is supposed to be 320×256.
It can support rectangular pixels (stdv_aspect and framebuffer_aspect), but I’m not sure how well this can be changed on the fly, or even if it is sensible to do so these days?
Yup. 64 actual colours and four levels of tint. I’m working with 256 colour sprites right now (that’s why I’m breaking Paint ;-) ) and I’m running into this nonsense. I think, to be honest, it’s useful to have something visible on-screen for the legacy modes, the values given (like 720×400 and 576p) were likely selected as standardised resolutions that a typical HDMI device ought to be capable of showing. However, given that the colours will all be very wrong (as 2, 4, and 16 colour modes aren’t supported), the dimensions of the text is only a small part of a larger puzzle. It’s some support so something is visible. But really, anything using these modes in this day and age ought to be translated to something that modern hardware can show without weird side effects. |
||||||||||||||||||||||||||||||||||||||||
David J. Ruck (33) 1585 posts |
We’ve had discussions before about the OS’s choice of closest mode is less than optimal. You can make it do much better if create an MDF with the the closest resolutions or multiples of (e.g. 640×512 for 320×256) that your monitor supports. |
||||||||||||||||||||||||||||||||||||||||
Stuart Painting (5389) 709 posts |
That is actually the closest supported resolution on the monitor (for Y resolution, anyway). RISC OS is reading the monitor capabilities via EDID so the pixel resolutions are pretty good choices. It was the text resolutions that seemed to be the real problem.
The latest revision of the User Guide contains the text “When selecting a numbered mode RISC OS 5 may substitute it with one of the same resolution, but with a different number of logical colours, in order to match the capabilities of the graphics hardware in your computer.” This is all the warning a user ever gets that they should check what mode has actually been supplied when requesting a legacy mode.
Agreed. Like I said at the outset, the way it operates at the moment may be “close enough for government work”.
It’s also possible that AnyMode would be the go-to solution for people with lots of programs that use legacy modes. |