Topics

Proposal to rationalise VDU variables

 

Richard,

Go ahead.
whatever you decide it will not affect me. I've never used this in my programs.

regards,
Eddy



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.

Richard Russell
 

On Sat, Feb 22, 2020 at 05:15 PM, Edja wrote:
I've never used this in my programs.
Do you mean you've never drawn lines or circles etc. with a thickness of more than one pixel?  That would surprise me!  Or do you mean you've never needed to read back the current thickness value?  The latter is what I would expect and is why I don't fear major incompatibilities arising.

My one worry is that there might be people who learned to use the @vdu%!248= method to set the line thickness, when it was the only way, and still do despite VDU 23,23... being the documented and supported method for some years now.

 

Richard,

>Or do you mean you've never needed to read back the current thickness value? <

Yes.

Also, years ago, and only to familiarize myself with BB4W, I've drawn lines, circles, ellipses ... These programs have been removed from my hard drive once they served their purpose. So if I need to draw again, I will do it with the then available instructions.

regards,
Eddy

On Saturday, February 22, 2020, 6:43:43 PM GMT+1, Richard Russell <news@...> wrote:


On Sat, Feb 22, 2020 at 05:15 PM, Edja wrote:
I've never used this in my programs.
Do you mean you've never drawn lines or circles etc. with a thickness of more than one pixel?  That would surprise me!  Or do you mean you've never needed to read back the current thickness value?  The latter is what I would expect and is why I don't fear major incompatibilities arising.

My one worry is that there might be people who learned to use the @vdu%!248= method to set the line thickness, when it was the only way, and still do despite VDU 23,23... being the documented and supported method for some years now.