Ticket #620 (Open)Tue Oct 31 03:20:39 UTC 2023
Monitor type inconsistency: Kernel does not read monitor type from VIDC20Video and vice versa
| Reported by: | Phil Pemberton (7989) | Severity: | Normal |
| Part: | Release: | ||
| Milestone: | Status | Open |
Details by Phil Pemberton (7989):
Previously mentioned on the forum: https://www.riscosopen.org/forum/forums/4/topic…
This one causes issues on the Bush IBX during boot (the boot messages aren’t visible). There is a workaround: configure MonitorType, Mode and Sync, and/or add a CMOS override for them.
It seems like it’d be better to have some way for the Kernel to request the monitor ID bits from the video driver, but there’s no defined API for that (at least that I have found).
Description from forum thread follows…
Historically, RISC OS machines up to the RISC PC and A7000 had four ID bits which identified the type of the connected monitor. On earlier machines there are four bits, on RISC PC/A7000 hardware there is only one.
On boot, if MonitorType, Mode and/or Sync were set to Auto, then RISC OS would set reasonable defaults for the Auto values based on the ID bits. On RO4 and earlier (pre HAL), this was entirely the responsibility of the kernel.
The HAL changes have split the responsibility for this across the Kernel and VIDC20Video; both are doing part of the job, and neither side is talking to the other:
- The Kernel has a variable called
MonitorLeadTypewhich is assigned a default value inkernel.s.PMF.osinit. This is passed toTranslateMonitorLeadType, which sets default modes based on monitor ID. VIDC20Videoreads the ID bits when it starts up, stores them internally, then does nothing with the ID-bits value.- Neither side of these processes are talking to each other: which means the Kernel is always assuming a VGA monitor is connected (which screws up the early boot messages), and the VIDC20Video knows what the correct value is, but hasn’t told the Kernel. (and the Kernel hasn’t asked for it either)
I’m hitting this bug as part of the Bush IBX work. The IBX doesn’t have any monitor ID bits, they’re hard-coded. To work around that, I modified VIDC20Video to force the monitor ID bits to a value which the Kernel would recognise as a PAL TV. But because both sides aren’t talking to each other, the video mode for early boot is stuck at MODE 28 on a VGA monitor — which the TV can’t display because it has separate syncs. (the CSYNC pin only has the VSYNC pulses in that mode)
It seems like the “fix” is to move the bulk of TranslateMonitorLeadType into a service call handler in VIDC20Video, then have the kernel function return “VGA” if the service call isn’t present. However that raises an issue, in that VIDC20Video needs to be up and running, and the type detection is happening before the modules are loaded … so it’s not quite that easy.
This doesn’t really scupper the Desktop, because there’s a “PAL TV” MDF which provides the interlaced and non-interlaced PAL modes. (there’s a separate bug which stops interlacing from working in RO5 – VetModes rejects them because the VetMode validation fails). But it’d still be nice to have the MODE 15 early-boot (“RISC OS nnnn KB, Acorn ADFS, …”) messages working for debugging.
Changelog:
Modified by Sprow (202) Wed, November 08 2023 - 22:38:56 GMT
In the context of RISC OS 5, I’d count this “not a bug”. A conscious decision was made when abstracting the kernel’s graphics system to rip all of the kernel’s TV handling out, it wasn’t needed (for the Iyonix) and just made things hard, so in effect the RISC OS 5 kernel believes the whole world is an SVGA monitor when Service_MonitorLeadTranslation is asked.
The code in VIDC20Video was transplanted from the kernel, and was respectfully preserved (translation: minimum work was done to make it look like a GraphicsV driver) so may well detect stuff and do nothing with them. In a resource constrained development you don’t do work that nobody’s going to use!
It’s worth consulting the ‘Mode change procedure’ analysis https://www.riscosopen.org/forum/forums/3/topic… to see how the whole arrangement is wired up.
If the only use case here is to see some text prior to an MDF being loaded into ScreenModes, then the less work options would be:
- Have a different initial table (VIDCTAB in HAL_IOMD/Video.s) to bang in an interlaced 640×480 1bpp mode instead of progressive if IOSystemType = STB or something
- Just add a CMOS override so the kernel knows its a TV type and never tries Service_MonitorLeadTranslation
Or
