Topics

Proposal to rationalise VDU variables

heckle@btinternet.com
 

Dear Richard,
   Having written a shorthand program that types the output using the BBC Basic graphics capability and its ease like no other programmable language, I would welcome any change that enables me to copy and paste the output to a word processor, if this will be the result of the change.
   While I'm here I'd like to take the opportunity to say that I was surprised on a recent visit to Bletchley Park and the (National?) Computer Museum that, even though there is a huge display of BBC computers (only displaying games!), there is no mention of the still active use of BBC Basic and your efforts in maintaining it's use for very many years; and its continued usefulness in  Raspberry Pi programming.
   Thank you for all your efforts.
Regards,
Derek Heckle

  --------------

On 21/02/2020 17:10, Richard Russell 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 Weir
 

Richard:

I am all for the change. I suspect most programs that break will be who don't update BB4W in any case. (I may be wrong and am prepared to be told so!)

Regards,

Richard Weir.

Richard Russell
 

On Sat, Feb 22, 2020 at 03:26 PM, heckle@... wrote:
I would welcome any change that enables me to copy and paste the output to a word processor,
I'm not really sure what you mean.  You can copy any 'textual' content in BB4W's output window to the clipboard using the Ctrl+Tab hotkey, although it only works reliably when using a monospaced font.

> even though there is a huge display of BBC computers (only displaying games!), there is no mention of the still active use of BBC Basic

It's the same at the Centre for Computing History in Cambridge.  I think the mainstream view is that it's unhelpful to promote 'modern' BBC BASIC when Python has such a stranglehold on the educational sector.