BBC BASIC for Windows v6.13 release candidate

[RichardRussell]

Is there a dedicated section on your site listing the version numbers of the most recent available libraries?

To be honest I doubt that library version numbers, if they even exist, can be relied upon too much. I do try to bump the version number when I update a library, but I can't guarantee that other library authors always do the same. All I can say with reasonable confidence is that the versions linked from the wiki should always be the most recent.

You are more than welcome to work through the list at that page and record the version number of each (sadly I expect you will find that some libraries are no longer available, if the original authors or their websites have 'gone away'). Let me know if you currently don't have edit privileges at the wiki but would like them.

[RichardRussell]

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 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.

[RichardRussell]

The cursor movement flag is currently at ?444 and the line thickness value at @vdu%?248 (in BB4W).

Incidentally if I do go ahead with this change I'll make sure that ?444 and @vdu%!248 become unused locations, so that if any unmodified programs write to them at least no harm will be done.

[Leo]

I vote for fixing the anomalies.
It should not be very difficult to find address references to these in programs. (Maybe a 'checker' program?)

Easy for me to say this of course as I know I have never used these address references in code I've written.

[RichardRussell]

It should not be very difficult to find address references to these in programs.

In my case I used the Search BASIC Programs utility (available from the wiki as an addin for BBC BASIC for Windows and supplied as standard with BBC BASIC for SDL 2.0). Although it's possible that other forms might have been used (e.g. specifying the offset in hexadecimal rather than decimal) searching for ?444 and @vdu%!248 is likely to find most occurrences.

[RichardRussell]

You are probably wondering why I have not yet released an update to BBC BASIC for Windows to fix the recently reported (but not recently discovered) bug, especially when in the old days I used to boast that if a serious bug was found I would release an update within 48 hours! This must count as a serious bug, since it leaves the system in an unstable state that could conceivably affect other applications.

The fact is that I am really struggling to cope with the update process and the resulting stress. It is more than two years since the last release (6.12a) and that has been more than enough time for me to forget the detail of what has to be done, especially with my ever-worsening cognitive decline. I am also conscious that there is a much greater risk of me introducing a regression than there was in the past.

So I'm sorry for the delay. I hope to be able to release v6.13a within the next week or so, but I can't give any guarantees.

[hellomike]

As far as I know, product quality has always been on top of your priority list. Let it be no different this time.
Also I think absolutely no one expressed any concern or complaint over the delay. Correct me when I'm wrong please.

So take your time even if that time is longer as it used to be.

Regards,

Mike

[RichardRussell]

I've uploaded a 'final' release candidate to the same place as before, it will announce itself as version 6.12z. This has the three discussed changes:

• The bug in the WIDTH function has (hopefully) been fixed.
• The 'VDU variables' have been rationalised; ?444 and @vdu%!248 no longer have their earlier functions.
• The 64-bit unary indirection operator ']' has been added, compatible with 64-bit and ARM editions of BBCSDL.

Please throw everything at this version to try to break it! Failing any reports of bugs or regressions, it will become v6.13a in due course.

[svein]

The WIDTH error seems to have been fixed ok, i could not get it to fail, not even a small hiccup.
Writing this because the WIDTH bug really bugged me. (valid expression ?)

For those who didn't know.
In 6.12a, the listed test code gives the following errors:

1. Full or partial printout upon start. Frequency=rare
2. Full or partial printout when repeatedly minimizing and restoring by clicking the icon on the taskbar. Frequency=not so rare.
3. Full or partial printout when making the bbc window larger by dragging any side of it. Frequency=all the time.

Svein

Code: Select all

      FOR A%=1 TO RND(100)
        a$+=CHR$(RND(94)+32)
      NEXT
      W%=WIDTH(a$)
      REPEAT
        IF WIDTH(a$)<>W% THEN PRINT a$
      UNTIL 0

[RichardRussell]

Writing this because the WIDTH bug really bugged me.

When were you first aware of a problem with WIDTH()? The initial report came from Kendall Down in this post; prior to that I had no clue that there was any kind of issue, having used WIDTH() myself extensively in programs since it was introduced. I assume you had no suspicions before that, I hope not anyway. The thought that somebody might have been aware of a bug, but not informed me, keeps me awake at night!