*TV

As part of my current efforts to tidy up mode handling in the kernel, I’m wondering what can be done for *TV. At the moment the offset & interlace settings are applied by the kernel to any VIDC list, prior to the VIDC list being sent to the GraphicsV driver in the mode change request. In some cases the updated VIDC list isn’t vetted after the changes have been made, which isn’t particularly sensible either.

*TV has two functions: To control the vertical offset of the display, and to control whether progressive or interlaced syncs are generated.

MDFs can be hand-tweaked to apply the correct vertical offset for each mode, and EDID is theoretically never wrong, so there’s no need to support using *TV to adjust the vertical offset of these modes.

The interlace sync setting only affects the type of interlace signal that’s generated by the graphics card – it doesn’t affect the pixels at all. So e.g. a non-interlaced mode 28 would be a single field of 640×480, while an interlaced mode 28 would be two fields of 640×480, producing a 640×960 frame. But unless you’re writing to the screen very quickly or flipping between two different screen banks, both of those fields will contain the same pixel data. This is different to the “interlaced” control list item, which generates an interlace sync and alters the DMA so that each field contains either the even or the odd rows from the framebuffer. These two different types have caused me some confusion in the past, but now that I think I finally understand what they’re doing hopefully that will come to an end. AFAIK no GraphicsV drivers pay attention to the sync/pol “interlace” flag (i.e the flag *TV affects), but some archaeology may be needed to see if it was ever supported on VIDC20 machines (I’m not even sure how much of an affect it would have on Arc machines – I vaguely remember playing around with it as a kid on an A3010, but can’t remember what the result was or what type of display was in use).

In any case, I’m thinking that usefulness of the *TV interlace setting is marginal enough that we don’t need to worry about supporting it for MDFs or EDID.

So this brings me to the point of this post: I’m thinking of changing the kernel so that the *TV adjustments are only applied to VIDC lists that are generated from the list of built-in VIDC lists. I.e. the settings will only take effect if (a) MonitorType is set to a suitable ye-olde value, and (b) you’re changing into a numbered mode known by the kernel (or using a mode selector block to select a mode which matches a mode known by the kernel – since one of the main things I’m doing is hoisting most of the numbered mode logic out of the VDU driver and into Service_ModeExtension / Service_ModeTranslation / Service_EnumerateScreenModes implementations). Numbered modes which aren’t known by the kernel won’t have *TV applied, so they’ll have to apply any offsets manually, but since user-defined numbered modes for >=3.5 are rare as hen’s teeth (and *TV users are likely even rarer) I doubt this will cause any serious problems.

Remember you built me a Beagle ROM image with S-Video output? I tweaked the screen position by altering an MDF. On the Pi… well… the GPU did everything for itself.
Would it not be simpler to have *TV do nothing until somebody can demonstrate a need for it?

Well yes, that would be one option. But I’m assuming that there might be one person out there (or some obscure software) which relies on it still. It would also be a bit mean to completely remove it if we don’t yet have an in-OS replacement (like allowing each GraphicsV driver to have its own Configure plugin, for hardware-specific configuration of overscan, TV-out formats, etc.)

ROFL

Did you create that, Patric? Or is it an xkcd? I don’t remember it if it is, but it has that look about it.

I did not expect to see XKCD here!

So this brings me to the point of this post: I’m thinking of changing the kernel so that the *TV adjustments are only applied to VIDC lists that are generated from the list of built-in VIDC lists. I.e. the settings will only take effect if (a) MonitorType is set to a suitable ye-olde value, and (b) you’re changing into a numbered mode known by the kernel

That sounds a reasonable logic, since as you say MDFs/EDID allow offset fiddling, it’s only the built in modes that don’t and hence would require *TV.

Does RISC OS get *TV right in MODE 7? It should move in character cell quanta, not pixels of emulated characters.

I’m wondering what can be done for *TV

Apart from the vetting issue, aren’t you creating unnecessary work for yourself? !!

I’m thinking of changing the kernel so that the *TV adjustments are only applied to VIDC lists that are generated from the list of built-in VIDC lists. I.e. the settings will only take effect if (a) MonitorType is set to a suitable ye-olde value, and (b) you’re changing into a numbered mode known by the kernel

There’s also VDU 23,0 for overriding the interlace. I presume it’s altering the same internal variable as OS_Byte 144 does.

I’ve always thought of *TV was a botch to (a) Allow vertically adjustment where the monitor doesn’t have manual adjustment and (b) force a particular interlace. Wasn’t there a power-on key to turn interlace on/off in RISCOS 2, +/- on the keypad possibly?

I had to implement *TV in ADFFS for IOMD, but I don’t appear to have documented why in either the code or the change log. So, there is a legacy game out there that’s using it, but we’re probably talking pre RISCOS 3.

If I understand correctly, you’re going to restrict it to Monitor Types 0-2 and 8? Incidentally, should there be a type added for EDID, given its restrictions?

Is vertical adjustment via modifying the VIDC parameters required these days? I can see a case for it on an original Archimedes, but has it been required since? Unless its going to free up a load of code, or is causing issues with future development, is it even worth worrying about?

Regarding the interlace setting, is that now just a veneer to GraphicsV 3 so no changes required?

Does RISC OS get *TV right in MODE 7? It should move in character cell quanta, not pixels of emulated characters.

For all modes it moves in terms of character rows, adjusting appropriately to the VDU font size.

I’m wondering what can be done for *TV

Apart from the vetting issue, aren’t you creating unnecessary work for yourself? !!

Moving the code for *TV from one place to another isn’t a great deal of work. Also I think the current implementation means that the kernel will try modifying the VIDC list that’s been returned from Service_ModeExtension, which isn’t very friendly.

There’s also VDU 23,0 for overriding the interlace. I presume it’s altering the same internal variable as OS_Byte 144 does.

VDU 23,0 takes effect immediately (via GraphicsV 3), and doesn’t seem to affect the stored *TV value (at least for RISC OS 5). OS_Byte 144 (I believe) only affects the settings that are used for the next mode change.

If I understand correctly, you’re going to restrict it to Monitor Types 0-2 and 8?

0-5 and 8, since those are the ones the kernel has built-in modes for.

Incidentally, should there be a type added for EDID, given its restrictions?

Internally EDID is handled as type 7, but with an extra flag set somewhere to indicate that it’s EDID and not MDF. I’m not sure offhand what the API is for reading that flag.

Is vertical adjustment via modifying the VIDC parameters required these days?

If you’re stuck using a TV/monitor which applies overscan to VGA/DVI/HDMI, or you’re using composite/S-Video, then it’s definitely useful to have some form of computer control over the image size/position. Long-term I’m hoping *TV will get replaced with driver-specific controls for this kind of thing (e.g. the overscan parameters on the Pi can be tweaked at runtime via the mailbox interface), but until that happens I’d imagine people would appreciate it if *TV was kept around.

Regarding the interlace setting, is that now just a veneer to GraphicsV 3 so no changes required?

The *TV interlace setting is passed to the driver via bit 3 of the sync/pol flags in the VIDC list. GraphicsV 3 just allows it to be changed without requiring a full mode change.

I did not expect to see XKCD here!

https://www.riscosopen.org/forum/posts/search?q=xkcd&submit=Go
[more amusing is that patric posted the exact same thing three years ago]

For all modes it moves in terms of character rows, adjusting appropriately to the VDU font size.

Yup, adding on some extra rows for gap modes.
I’m looking at the RISC OS 2 source, probably the last time this did anything particularly useful (no combination seems to have any effect on my Pi). It looks like it mucks with the VIDC’s vertical display start register (offset) and the control register (interlace).

0-5 and 8, since those are the ones the kernel has built-in modes for.

Would it not be more logical to restrict this to numbered modes rather than monitortypes?

but until that happens I’d imagine people would appreciate it if *TV was kept around.

As I mentioned above, my Pi has the GPU control the display (rather than RISC OS), so *TV does nothing.

I’ve always thought of *TV was a botch to (a) Allow vertically adjustment where the monitor doesn’t have manual adjustment and (b) force a particular interlace.

It’s “yet another” leftover from the BBC Micro (where it was useful as sometimes the TV would put the computer’s image in the wrong position, especially in MODE 0). BBC User Guide, page 17.

Wasn’t there a power-on key to turn interlace on/off in RISCOS 2, +/- on the keypad possibly?

Wasn’t that composite/vertical sync?

So, there is a legacy game out there that’s using it, but we’re probably talking pre RISCOS 3.

Some old games used to do horrible things. I had one, a billion years ago, that thought it was totally okay to *Unplug the Econet stuff and then force a reboot. I. Was. Not. Pleased.

0-5 and 8, since those are the ones the kernel has built-in modes for.

Would it not be more logical to restrict this to numbered modes rather than monitortypes?

For consistency with Arc machines, yes it would make sense to apply it to all* numbered modes. But that would require more effort, for potentially zero gain (on a Venn diagram containing “users who use RISC OS 5 compatible numbered mode modules” and “users who use *TV”, how big is the intersection?).

It would also perpetuate the practice of modifying VIDC lists after they’ve been returned by Service_ModeExtension, potentially resulting in inconsistencies depending on what code it is that’s calling Service_ModeExtension.

(* all = “all numbered modes that are handled by the kernel’s builtin mode list or mode extension modules”. I.e. modes which don’t take their VIDC lists from MDFs or EDID. Numbered modes which are transparently converted to mode selector blocks (as happens with built-in numbered modes for monitor type 7 & EDID) won’t count.)

and “users who use *TV”, how big is the intersection?).

I’m still on the side of “make the command do nothing, see who complains”…

Given the inherent complexities of stuff like overscan, surely we’d need a more coherent method (maybe in the MDF?) than simply shifting the entire display up or down a bit.

The last times I ran into such problems:

• PC on an IBM CRT. The SVGA image was shifted to inches to the left. No idea why. Resolved by changing to a different monitor.
• Sony TV with VGA socket, RiscPC. Scaled up the image so about thirty or so pixels were lost all around.

I get in the days of analogue TVs, some of them lost more of the top of the picture than others (possibly to hide the VBI, teletext, etc). But is this simple up down adjustment so useful these days?

I’m still on the side of “make the command do nothing, see who complains”

I wouldn’t. I didn’t even know of the existence of the command.

I didn’t even know of the existence of the command.

That’s possibly because it is provided by the “hidden” RISC OS module…

There’s a module before UtilityModule, it’s the low level kernel. But you can’t ask for help on “RISC OS”. The only way, as far as I’m aware, of seeing this help is to enter *Help . and spotting it in the mass of output.

RISC OS         5.23 (18 Jul 2017)
Append  Build   Close   Create  Delete  Dump    Exec    FX      GO      Help    Key
Load    List    Opt     Print   Quit    Remove  Save    Shadow  Spool   SpoolOn TV
Type

[yes, I know my build is… getting on a bit. ;-)]

There’s a module before UtilityModule, it’s the low level kernel. But you can’t ask for help on “RISC OS”. The only way, as far as I’m aware, of seeing this help is to enter *Help . and spotting it in the mass of output.

I’ve always used *help utilitymodule

I’ve always used *help utilitymodule

Different module, different commands… :-)

Aside: Looking at the RISC OS commands, I wonder how many of them (Append, Build, Close, Create, Delete, Exec, List, Load, Opt, Save, Spool[On], Type) probably belong in FileSwitch?
Many of the rest (FX, Go, Help, Key, Shadow, TV) look like BBC MOS commands. ;-)

But you can’t ask for help on “RISC OS”.

You can see all commands available, including those provided by the RISC OS module, by entering: Help Commands.

Thanks Fred. I’d forgotten that. Better than the “help on everything” deluge. ;-)

some archaeology may be needed to see if it was ever supported on VIDC20 machines (I’m not even sure how much of an affect it would have on Arc machines – I vaguely remember playing around with it as a kid on an A3010, but can’t remember what the result was or what type of display was in use).

For RiscPCs (running 3.x/4.x) the *TV interlace setting does appear to do something useful.

• For CRTs, enabling interlace will reduce the size of the gaps between scanlines in low-res modes (see druck’s AutoInterlace module)
• For LCDs, it can make the difference between modes working and not working.
  • E.g. the “copes with almost anything” AOC Q2577PWC will happily display every monitor type 0 mode my RiscPC throws at it if interlace is enabled (although the picture does jiggle up and down a bit, and it looks like it’s trying to resample to 720×576, so pixel sizes can be a bit irregular). But if you turn interlace off then you just get an “input not supported” error. Also, “high-res” modes like mode 28 only work if interlace is disabled.
  • Other monitors (BenQ FP737S-D from 2004) don’t appear to detect the difference between interlace and progressive sync – so mode 28 works whatever the interlace setting is, and monitor type 0 doesn’t work at all.
• RISCOS Ltd. even thought interlaced modes were important enough to roll them into RISC OS 4.05. The details there are a bit vague, but since 3.x has always supported interlace sync generation, I’d imagine this is about introducing support for the MMU-based interlace hack that was used on STBs (i.e. 480i with a 640×480 framebuffer, instead of line-doubling a 640×240 framebuffer)

AFAIK no GraphicsV drivers pay attention to the sync/pol “interlace” flag (i.e the flag *TV affects)

VIDC20Video did until I removed support for it. D’oh!

https://www.riscosopen.org/viewer/view/apache/RiscOS/Sources/Video/HWSupport/VIDC20Video/VersionNum#VIDC20Video-0_05

So since the *TV interlace setting is useful (and different in functionality to the interlace control list item), I’m thinking we’ll want to un-deprecate (and fix the description of) the relevant VIDC list sync/pol flags, and restore support for the flag in VIDC20Video. Then in the future we can decide on whether/how ScreenModes should be able to generate VIDC lists containing the flag (easy fix for MDFs would be to tweak the sync_pol parameter validation), and then in the far future once GraphicsV drivers finally gain control over memory mapping, we can reimplement the MMU-based interlacing hack in VIDC20Video.

RISCOS Ltd. even thought interlaced modes were important enough to roll them into RISC OS 4.05.

Did that actually escape into the wild? Or did people decide that £60 was a bit much to replace softloaded patches with hardware based patches? – “no new features”

RISC OS 4.05 was primarily aimed at users of Millipede Professional Graphics systems, and other users who have been unable to utilise the Alphalock systems, due to changes to the memory map and page tables between RISC OS 3.7 and RISC OS 4.

Has anybody seen or have a RISC OS 4.05 rom? I have a Alphalock system.