Proposal to rationalise VDU variables


Hi Richard
I’m so pleased you’re able to keep making improvements to BB4W. What you’ve proposed won’t affect me at all and, like others, I’d accept your expertise and go along with your recommendation. 

On 21 Feb 2020, at 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.,, and 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.

Richard Russell

On Sat, Feb 22, 2020 at 09:18 AM, nbadderley wrote:
I’m so pleased you’re able to keep making improvements to BB4W.
I'm not sure "improvements" is the right word.  If it wasn't for the recently-discovered bug I probably wouldn't be making any changes (active development of BB4W ceased years ago).  As it is, fixing a bug and making an incompatible change to rationalise the VDU variables is at best 'maintenance' not 'improvement'!

If you are looking for "improvements" then switch to using BBC BASIC for SDL 2.0 which is where all the interesting developments are happening.