Topics

BBC BASIC for Windows v6.13 release candidate

Richard Russell
 

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:

1. The bug in the WIDTH function has (hopefully) been fixed.
2. The 'VDU variables' have been rationalised; ?444 and @vdu%!248 no longer have their earlier functions.
3. 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.

 

Richard, if I compile something with 6.12z, will it still use the existing bbcrun6.exe on my machine or does bbcwin6.exe actually do the compile?  Sorry if that's a silly question.

Thanks -- K

On Wed, Mar 11, 2020 at 10:17 AM Richard Russell <news@...> wrote:
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:

1. The bug in the WIDTH function has (hopefully) been fixed.
2. The 'VDU variables' have been rationalised; ?444 and @vdu%!248 no longer have their earlier functions.
3. 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.

Richard Russell
 

On Wed, Mar 11, 2020 at 11:01 PM, Kendall Castor-Perry wrote:
f I compile something with 6.12z, will it still use the existing bbcrun6.exe on my machine
Yes.  There's no value in 'testing' compiling for that reason.  I could also make available a bbcwrun release candidate but the interpreter is identical to that in the IDE.

Richard Russell
 

On Wed, Mar 11, 2020 at 05:17 PM, Richard Russell wrote:
Please throw everything at this version to try to break it!
Whilst you're at it I would suggest that you search all your BBC BASIC programs (the Search BASIC Programs utility makes this easy) for any occurrences of ?444, @vdu%?248, @vdu%!248, @vdu%?252 and @vdu%!252 since the presence of any of those might indicate a potential incompatibility with the new version. 

Having said that, references to ?444 which are solely in order to save and later restore it will probably be harmless because saving and restoring the @vdu{} structure will now automatically include this VDU variable.

Richard Russell
 

On Wed, Mar 11, 2020 at 05:17 PM, Richard Russell wrote:
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.
Last call for reports of any problems.  I'm tentatively planning to release the new version on Monday (16th March); with so many uncertainties about pretty much everything at the moment, I'd like to make it available whilst I still can!

J.G.Harston
 

Richard Russell wrote:
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.
I've gone through my 'BasicTests' directory and everything runs ok. I've
also specifically tested programs that access the @vdu% variables,
PDPTube, TubeHost and stuff, and they all work ok as well.

--
J.G.Harston - jgh@... - mdfs.net/jgh

Richard Russell
 

On Sun, Mar 15, 2020 at 02:32 PM, J.G.Harston wrote:
I've gone through my 'BasicTests' directory and everything runs ok.
Thank you, that boosts my confidence.  The changes are relatively minor and the risk of a regression therefore relatively low, but that's what I thought last time and we wouldn't be here now if I had been right.  :-(

I've also specifically tested programs that access the @vdu% variables

An incompatibility arising from the change to the ?444 variable (was cursor movement control) is unlikely because, from the start, the proper way to set it was using VDU 23,16... and needing to read it most unlikely. But for a period of time (I can't remember how long) writing to @vdu%!248 was the only way of setting the line thickness, before VDU 23,23... was introduced, so there's a greater likelihood of a few programs still being around that use that method. They will start drawing 1-pixel-thick lines until amended.