Date   

Re: Proposal to rationalise VDU variables

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.


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


Re: Proposal to rationalise VDU variables

 

Same here and thank you for many years of fun!

On 2/22/2020 5:30 AM, Ian Boddy wrote:
I don't have any problems with this proposal.

Cheers
Ian Boddy

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.


Re: Proposal to rationalise VDU variables

Ian Boddy
 

I don't have any problems with this proposal.

Cheers
Ian Boddy

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.


Re: Proposal to rationalise VDU variables

Richard Russell
 

On Sat, Feb 22, 2020 at 09:18 AM, nbadderley wrote:
I’m so pleased you’re able to keep making improvements to BB4W.
I'm not sure "improvements" is the right word.  If it wasn't for the recently-discovered bug I probably wouldn't be making any changes (active development of BB4W ceased years ago).  As it is, fixing a bug and making an incompatible change to rationalise the VDU variables is at best 'maintenance' not 'improvement'!

If you are looking for "improvements" then switch to using BBC BASIC for SDL 2.0 which is where all the interesting developments are happening.


Re: Proposal to rationalise VDU variables

nbadderley
 

Hi Richard
I’m so pleased you’re able to keep making improvements to BB4W. What you’ve proposed won’t affect me at all and, like others, I’d accept your expertise and go along with your recommendation. 
Geoff


On 21 Feb 2020, at 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.


Re: Proposal to rationalise VDU variables

wilsr747
 

I would leave well alone, myself - but I don't any longer do much programming so probably do not count!

Rog


Re: Proposal to rationalise VDU variables

Mark Moulding
 

This wouldn't affect any of my personal existing software, so of course I'd be in favor of the change.  Especially since any significant application will probably be mostly used as a compiled executable, so that existing production software won't be broken, it seems to me to be not much of a burden to update a clearly-documented change of this type for a new release.  (It was OK - on a much larger scale - for Python apparently, from 2.x to 3.x...)
~~

Mark Moulding


Re: Proposal to rationalise VDU variables

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.


Re: Proposal to rationalise VDU variables

J.G.Harston
 

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

[1] http://mdfs.net/Software/Tube/Serial/TubeHost.bas
[2] eg http://mdfs.net/Apps/Emulators/Tube/PDPTube/PDP11Em.bas
--
J.G.Harston - jgh@... - mdfs.net/jgh


Re: Proposal to rationalise VDU variables

Hans van der Hoeven
 

I do agree with Richard that the change he proposes is a logical and good thing to do. Please do it as such.

 

Also thanks again for BB4W. It has brought me a lot of fun.

 

Hans van der Hoeven.

 

Van: bb4w@groups.io Namens Richard Russell
Verzonden: vrijdag 21 februari 2020 18:10
Aan: bb4w@groups.io
Onderwerp: [Special] [bb4w] Proposal ro rationalise VDU variables

 

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.


Re: Proposal to rationalise VDU variables

jgw321
 

I don't program at this depth so my vote is not significant.  I leave it for those affected to have their say, but your effort to keep us all happy is appreciated.

On Fri, 21 Feb 2020 at 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.



--
Without wishing to offend anyone, check all Urban Myths at http://www.snopes.com/
but please don't send them to me, I do not forward chain letters.

JG (this is my name)


Re: Proposal to rationalise VDU variables

Andrew Cool
 

Richard,

 

Consistency is everything.

 

Do it!

 

Regards,

 

Andrew Cool

 

 

Andrew Cool MASA, FRAS

www.skippysky.com.au

www.rivermurraydarkskyreserve.org

www.adelaideobservatory.org

 

 

 

From: bb4w@groups.io <bb4w@groups.io> On Behalf Of Richard Russell
Sent: Saturday, 22 February 2020 3:40 AM
To: bb4w@groups.io
Subject: [Special] [bb4w] Proposal ro rationalise VDU variables

 

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.


Re: Proposal to rationalise VDU variables

Richard Russell
 

On Fri, Feb 21, 2020 at 06:39 PM, alan836975 wrote:
I use the line thickness variable quite a lot,
Can you confirm, at least, that when you do so you use VDU 23,23,t| to set the width and not the ancient @vdu%!248= method?  The manual has said for a very long time that @vdu%!248 should be used only to read the width, not to set it.


Re: Proposal to rationalise VDU variables

 

Hi Richard, nice to hear from you.

I use the line thickness variable quite a lot, but I can accept having to change my code provided the instructions are clear. I don't save the VDU variables so it will make no big differece to me. So, all power to you, please keep up the good work :-)

Alan


Re: Proposal to rationalise VDU variables

R NBW
 

Richard

I think what you intend is sensible. 

In progressing any programming language, you will come to a point where there well be incompatibilities in older programs and they will break.  If this want the case then we would still be using the old Microsoft Basic, complete with lunge numbers, GOTO and GOSUB.

Provided that you make it clear in your documentation what you have done and why, I think it is then the responsibility of the programmer to modify their code.

What use propose is logical and should stand the test of time.

Ray



On 21 Feb 2020, at 5:10 pm, 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.


Re: Proposal to rationalise VDU variables

 

Richard,

 

I am confident you will decide upon the better option.

 

However, I am aware you prefer acknowledgement.

 

Whilst I freely admit my knowledge of such intricacies is non-existent, I personally feel I would prefer no change was made.

 

Regards,

 

Bob.

 

 

From: Richard Russell
Sent: 21 February 2020 17:15
To: bb4w@groups.io
Subject: [Special] [bb4w] Proposal ro rationalise VDU variables

 

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.

 


Proposal to rationalise VDU variables

Richard Russell
 

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.


Re: New files uploaded to bb4w@groups.io

Storer, Darren
 

As soon as I open my big mouth, I soon regret it. I seem to have done David a bit of a disservice, as he has a wonderful new web site, which includes support for BBC Basic SDL :-)

http://www.proggies.uk/

(Sorry David)

Darren


On Mon, 10 Feb 2020 at 00:47, Storer, Darren <darren.storer@...> wrote:
Unfortunately, the excellent bb4wgames site is no longer available but you can take a look at the archives by following this link:

http://tinyurl.com/bb4wgames

...you should find some examples of how to make use of BOX2DGFX, which is designed to be used with BB4W.

Hope this helps

Darren

On Sun, 9 Feb 2020 at 21:24, <mclout@...> wrote:
Will this work for BBC Basic for SDL, and if so can you point to where I can learn how to use libraries like this.  Thank you.


Re: New files uploaded to bb4w@groups.io

Storer, Darren
 

PS. The Box2D documentation can be found by following the link below:



On Mon, 10 Feb 2020 at 00:48, Storer, Darren via Groups.Io <darren.storer=gmail.com@groups.io> wrote:
Unfortunately, the excellent bb4wgames site is no longer available but you can take a look at the archives by following this link:

http://tinyurl.com/bb4wgames

...you should find some examples of how to make use of BOX2DGFX, which is designed to be used with BB4W.

Hope this helps

Darren

On Sun, 9 Feb 2020 at 21:24, <mclout@...> wrote:
Will this work for BBC Basic for SDL, and if so can you point to where I can learn how to use libraries like this.  Thank you.