VDU 23,18 extensions

VDU 23,18 specifies various things for the MODE 7 teletext display emulation:
VDU 23,18,0 – set mix/box display mode
VDU 23,18,1 – set update type
VDU 23,18,2 – reveal concealed display
VDU 23,18,3 – enable extended control characters

VDU 23,18,3 enables/disables the ability for &80 and &90 to be ‘black text’/‘black graphics’. The hardware SAA5050 implemented Level 1 Teletext which implemented &80/&90 as NULs, Level 2.5 Teletext logically extended the colour controls to allow black foreground.

Level 2.5 Teletext also implements double width (&8E) and double size (&8F) characters. See http://mdfs.net/Info/Comp/SAA5050/Controls

I propose pencilling in/reserving a VDU 23,18 option to enable this L2.5 feature as well.

What I would recommend would be:
VDU 23,18,3,xor,and,0,0,0,0,0 to change the L2.5 setting to setting=(oldsetting AND and) XOR xor as with many other calls, and b0=black enabled (as currently) and b1=double enable.

Another option I think would be useful to pencil in is being able to select which SAA character set to use. The Beeb used the British SAA5050, and RISC OS emulates that. There are eight extant teletext character sets, see http://mdfs.net/Info/Comp/SAA5050/

What I would recommend would be:
VDU 23,18,4,fontnum,0,0,0,0,0,0 to select the teletext font, numbered as per the SA505x series, defaulting to 0.

As a note, Brandy Basic developers have pencilled in VDU 23,18,16 to specify the display quiality of the teletext characters.

That sounds good to me.

FWIW, this document describes the VDU 23,18 codes that RISC OS 5 supports (sub-codes 0-3), and this document covers RISC OS Select/6 (1, 2 and 16)

Would it not be safer to use VDU23,18,3 to directly select the Teletext Level rather than switching individual features on and off?

There’s a great deal more to Level 2.5 than double-width characters – there’s row colours, non-spacing attributes, multiple simultaneous character sets, additional colour palettes, accented characters, user-defined characters (DRCS), smooth mosaics etc.

At 3.5 there’s definable colours and four different font ‘sizes’ too

And there’s much more than 8 character sets as well – there’s four different scripts for a start.

The (pre-)existing interface only switches a single feature on/off, so if it had been intended to be a Level 2.5 switch it would have been specified as such, even if it was documented as (Level 2.5 features (only black foreground switch currently supported)). And there’s nothing to stop a programmer doing VDU 23,18,3,255| to switch all possible extensions on. Pre-existing code could well be using VDU 23,18,3,1| to turn black foreground on, and be surprised if it turned other stuff on as well.

VDU 23,18,4,num| allows up to 256 fonts. Even 65536 fonts if you want to read it as VDU 23,18,4,numLo,numHi|. Up to 2^(9*256) fonts in extremis. As the recommended code is to send zeros for unused bytes in the VDU stream, VDU 23,18,4,numLo,reserved for numHi,reserved for some other font characteristic,reserved for some other font characteristic,reserved for some other font characteristic,reserved for some other font characteristic,etc. with zero being to default to the current implementation. Them in future, one of those ’reserved’s could well be font size, font weight, whatever. As long as the ’reserved’s are specified to be sent as zeros it allows future extension without restricting any future extensions.

Level 2.5 Teletext logically extended the colour controls to allow black foreground.

Not entirely correct. It was codified in the Level 2.5 specification, but it has been widely used with pages intended for Level 1.5 hardware – German teletext used it extensively (well, it did back around the millennium, dunno if there’s any teletext left on digital satellite these days).
My FTA receiver at the time, a little Comag box, was basic plain teletext (but useful in that it was nippy enough to capture the entire page set in one roll around) but it too supported black as a foreground colour.

https://www.etsi.org/deliver/etsi_en/300700_300799/300706/01.02.01_40/en_300706v010201o.pdf page 70 mentions the use of Alpha Black in older hardware.

To this end, I’d consider anything newer than an SAA5050 that did not support Alpha Black to be a defective implementation. A good example is the fourth picture down on this page: http://heyrick.eu/software/ttx/ttxouse.html

I don’t see the point in roll-your-own Teletext feature sets that are incompatible with every standard ever published. “Does have green! Doesn’t have red!”. Under what circumstances would you want a novel width, height and font, but require &80 to be a NOP? If you’re using existing content you need an accurate emulation of a particular level. If you’re producing your own content you don’t have to switch features off… just don’t use them.

The (pre-)existing interface only switches a single feature on/off

Since I was talking about VDU23,18,3 and it only takes parameters 0 and 1 currently, I don’t see how you can assert that it’s a bitfield and not an enumeration.

So I’ll ask again: Why not VDU23,18,3,<teletext level> – what’s the usage case for pic’n’mix Teletext?

what’s the usage case for pic’n’mix Teletext?

While the idea of a teletext level is a good one, it turns out that there are many complications in supporting teletext.

Consider the idea of language support. First of all we can ignore everything on MDFS.net; it’s all based around the SAA5050 which is a ridiculously simple chip from the dawn of teletext.
Contemporary with the BBC Micro is the likes of the SAA5243. This contains not only a higher quality output font (that problem solved) but also rolls most of the common European languages in together because it is possible to switch langage and even have different header and page languages. Instead the SAA5243 is available in different versions depending on what sort of language support is required – western European, Cyrillic, Arabic…

incompatible with every standard ever published

As pointed out Alpha Black is a level 2.5 feature that was widely used before level 2.5. Only the ancient hardware didn’t support it…

ETSI spec: https://www.etsi.org/deliver/etsi_en/300700_300799/300706/01.02.01_40/en_300706v010201o.pdf

Description of SAA5243 “EuroCCT”: http://heyrick.eu/software/ttx/eurocct.pdf

it is possible to switch language