Proposal to rationalise VDU variables


Richard Russell wrote:
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.
Would there be a way to test that they had been moved? Eg something like
if @vdu%!248=nonsensevalue then use new variables else use old variables.

I read quite a few VDU variables via @vdu%!offset in TubeHost[1] and my
Tube emulators[2] to translate OSBYTE 160 calls to read the hosts'
appropriate VDU setting. Anything that writes to them writes to them
via the VDU stream.

(In the Acorn VDU drivers, it's always been an annoyance that there a
a small handful of settings that can't be set through the VDU stream.
*FX163,repeatpattern I'm looking at you.)

[2] eg
J.G.Harston - jgh@... -

Richard Russell

On Fri, Feb 21, 2020 at 08:42 PM, J.G.Harston wrote:
Would there be a way to test that they had been moved?
The only use I've had for reading the values is in order to save them and restore them later.    Because I always save and restore @vdu{} in those circumstances, I don't actually need to know if they've moved (it will work correctly whether moved or not).

In BB4W I can guarantee that @vdu%!248 will return zero (an illegitimate value for the line thickness) after the change, but the same isn't true of BBCSDL.