Detected monitor type is not passed from VIDC20Driver to kernel

I think I’ve stumbled across a bug in the handling of the monitor ID bits.

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, 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 MonitorLeadType which is assigned a default value in kernel.s.PMF.osinit. This is passed to TranslateMonitorLeadType, which sets default modes based on monitor ID.
• VIDC20Video reads 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.

Can anyone who’s familiar with the HAL / Kernel layer and video driver interface possibly speculate as to how this might be fixed?

PRM 5a says “Mono VGA monitors are interpreted as TV standard monitors, so this class of monitor requires manual configuration before use. Other monitor types are detected and an appropriate mode is selected.”

I recall back in the day that I would always explicitly configure the monitor type as the automatic detection often wasn’t right (probably an issue with the monitors rather than RISC OS, or maybe it needed something done to the plug? special cable?).

I’m surprised they didn’t hardwire the ID high to appear as a TV style device, but, then, it was probably simpler to fiddle this in software than to fiddle it in hardware.
Have you looked at NVRAM and/or the defaults? Are you using NVRAM at all?

I can see the tags file (defaults?) says ¹:

MonitorInfo:&85,,,&7D,L

but I don’t know what that actually translates to in RISC OS terms.

¹ http://heyrick.eu/assembler/resources/stbnvram.html

The NVRAM module is an odd beast. That particular definition is – I think – a CMOS RAM variable. I think it’s only defined in the NVRAM tag file to stop someone from overwriting it.

In any case the NVRAM module isn’t doing anything – I don’t have the tag file loaded.

And I figured out what’s stopping interlacing from working … there’s a module called “Interlace” which is in the NC/Bush ROM.

It seems to be using OS_Memory 0 to get the physical address of logical addresses 0×5000000 and 0×2C0C000… I have no idea what they’re meant to be…