Topics

Proposal to rationalise VDU variables

 

Same here and thank you for many years of fun!

On 2/22/2020 5:30 AM, Ian Boddy wrote:
I don't have any problems with this proposal.

Cheers
Ian Boddy

On Fri, 21 Feb 2020, 17:10 Richard Russell, <news@...> wrote:
I'm contemplating doing something drastic: making an incompatible change to BB4W (and indeed to BBCSDL subsequently)! I'd appreciate people's views on whether such an exceptional step can be justified.

Because of the way BBC BASIC's capabilities have grown over the years, anomalies have arisen in respect of the location of some 'system' variables. Specifically the 'cursor movement' flag (set using VDU 23,16...) and the 'line thickness' value (set using VDU 23,23...), which should both logically be part of the VDU variables structure @vdu{}, aren't. The cursor movement flag is currently at ?444 and the line thickness value at @vdu%?248 (in BB4W).

Apart from being 'illogical', not being part of the VDU variables structure has the practical consequence that in programs which deliberately save and restore this structure (e.g. banner.bbc, Ceefax.bbc, telstar.bbc and multiwin.bbc) these variables are not automatically saved as they should be. Some (but not all) of these programs deliberately save and restore the cursor movement flag separately, but none currently saves the line thickness value. Moving them into the VDU structure would fix this.

I have reluctantly accepted this situation in BB4W to date because of the compatibility implications of moving them. But BBCSDL has already set a precedent for moving the line thickness value (it is no longer at @vdu%!248, and indeed isn't even in the same place in 32-bit and 64-bit editions), and updating BB4W to v6.13a provides what might be the last ever opportunity for putting this anomaly 'right'.

So what are your views? If I don't fix this now, there will forever be frustration at the anomalies. But if I do there will definitely be programs that break (I know for sure that some programs set the line thickness using @vdu%!248=n because once upon a time it was the only way). Most likely the consequence will only be 'cosmetic' but it could be important, and such programs will need to be modified.

If I do make this change I will at least ensure that ?444 and @vdu%!248 become 'unused' locations, so that if any unmodified program does write to them no harm will be done.