Expanding BBC BASIC on Acorn 8 bit machines

discussion of beeb/electron applications, languages, utils and educational s/w
Post Reply
User avatar
daveejhitchins
Posts: 4462
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Expanding BBC BASIC on Acorn 8 bit machines

Post by daveejhitchins » Wed Jun 27, 2018 7:48 am

I've been following this thread with interest and got to thinking about the difference between BASIC, as on every 8 bit Acorn machine, and Richard Russell's version. OK, that version runs under Windows. However, my thoughts were: could we use a PLDed ROM to double the allocated space for BASIC? Then we could have a version that contains all the new 'bells-and-whistles' of Richard's version . . . Backwards compatible, of course . . .

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ARA III, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
Elminster
Posts: 3137
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by Elminster » Wed Jun 27, 2018 8:42 am

To be honest I think a lot of what I wanted was actually in BASIC V, which was the Adv BASIC on Beeb, which required 32k in stead of 16k.

There were a couple of threads about it somewhere, I think you were on them (from memory), will try to find them.

User avatar
Elminster
Posts: 3137
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by Elminster » Wed Jun 27, 2018 9:18 am

Here are the threads I remember from discussing these sorts of things before, might be worth a quick peruse, rather than me duplicate:

Extended Basic ROM

Break/continue in BASIC loops?

6502 Advanced BASIC V questions

Basic programming tools

Edit: Removed one of the links, it wasnt what I thought it was. Corrected typos.
Last edited by Elminster on Wed Jun 27, 2018 12:00 pm, edited 2 times in total.

User avatar
BigEd
Posts: 2140
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by BigEd » Wed Jun 27, 2018 11:58 am

Good links - thanks!

User avatar
Richard Russell
Posts: 529
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by Richard Russell » Wed Jun 27, 2018 10:00 pm

Elminster wrote:
Wed Jun 27, 2018 8:42 am
To be honest I think a lot of what I wanted was actually in BASIC V
The main thing I couldn't live with in BASIC V is strings limited to 255 characters, and it's interesting that Brandy (which in most respects matches the BASIC V spec closely) increased this to 65535 characters - or should I say bytes in these days of multi-byte character sets. Of course in current versions of BBC BASIC for Windows and BBC BASIC for SDL 2.0 strings are limited in length only by the available virtual memory, and I routinely load a whole file into a string variable even if it's megabytes long (for example making it possible to search the entire file with INSTR).

User avatar
daveejhitchins
Posts: 4462
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by daveejhitchins » Thu Jun 28, 2018 7:07 am

Elminster wrote:
Wed Jun 27, 2018 9:18 am
Here are the threads I remember from discussing these sorts of things before, might be worth a quick peruse, rather than me duplicate:
Good reads, however, I was thinking more of a replacement BASIC ROM (32k or more with PLD switching) that would contain an integrated, expanded and backwards compatible BASIC!

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ARA III, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
Elminster
Posts: 3137
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by Elminster » Thu Jun 28, 2018 8:53 am

I thought these previous discussion of features we (well usually I) would like and tools that would be useful (or I use) might give you a starting point.

So yes a 32k Basic (or more) with all those features, would be great. And if you could squeeze in the various tools as well you would have the ulimate ROM but you are probably tlaking near 64k by then.

User avatar
marcusjambler
Posts: 450
Joined: Mon May 22, 2017 11:20 am
Location: Bradford
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by marcusjambler » Thu Jun 28, 2018 9:01 am

Just to add my 2p...
It would be great to have a version of basic that runs on the Native ARM core on the PI [-o<

User avatar
BigEd
Posts: 2140
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by BigEd » Thu Jun 28, 2018 9:06 am

(There is BAS135, but yes if we could have an enhanced or even a modern BBC Basic that would be great.)

User avatar
hoglet
Posts: 7611
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by hoglet » Thu Jun 28, 2018 9:08 am

Hi Marcus,
marcusjambler wrote:
Thu Jun 28, 2018 9:01 am
Just to add my 2p...
It would be great to have a version of basic that runs on the Native ARM core on the PI [-o<
I've been using ARM Basic V version 1.35.

DIsk images here:
viewtopic.php?p=160829#p160829

Dave

User avatar
Elminster
Posts: 3137
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by Elminster » Thu Jun 28, 2018 9:12 am

So a summary of my wants from threads above (and comments below) was/is:

1. if/else if/else
2. break/continue from loops
3. J.G.H basic tools build into the ROM
4. ABE nice to have but can always be in a seperate ROM
5. Usable in Electron/BBC/Master

Edit (and others voted for):

Richard R:
1. 65535 strings (or some increase from 255)

Lurkio:
1. Local error handling in proc/fund
2. Labels

Rich Talbot-Watkins:
1. Some sort of tokenisation

Other Obvious adds:
1. While loop
2. Case Statement
Last edited by Elminster on Thu Jun 28, 2018 2:49 pm, edited 5 times in total.

User avatar
lurkio
Posts: 1782
Joined: Tue Apr 09, 2013 11:30 pm
Location: Doomawangara
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by lurkio » Thu Jun 28, 2018 9:54 am

Elminster wrote:
Thu Jun 28, 2018 9:12 am
So a summary of my wants from threads above was ...
Can I vote for local error-handling in PROCs/FNs too please? (JGH implemented this in another thread not long ago.)

Also, GOTO <label> instead of (or as well as) GOTO <line-number>.

:?:

User avatar
jgharston
Posts: 3248
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by jgharston » Thu Jun 28, 2018 9:54 am

Elminster wrote:
Thu Jun 28, 2018 9:12 am
Richard R:
1. 65535 strings (or some increase from 255)
64K strings on an 8-bit processor is very difficult as you need somewhere to put a 64K string accumulator....

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
Elminster
Posts: 3137
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by Elminster » Thu Jun 28, 2018 10:50 am

I think the vote was for more than 255, 64k was just what it was changed to on other architectures.

User avatar
Elminster
Posts: 3137
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by Elminster » Thu Jun 28, 2018 10:53 am

lurkio wrote:
Thu Jun 28, 2018 9:54 am
Elminster wrote:
Thu Jun 28, 2018 9:12 am
So a summary of my wants from threads above was ...
Can I vote for local error-handling in PROCs/FNs too please? (JGH implemented this in another thread not long ago.)

Also, GOTO <label> instead of (or as well as) GOTO <line-number>.

:?:
Ah yes, I actually using that be btelnet. Forgotten about that one.

Goto shuddered. I think what you really want is just labels in general.

User avatar
Richard Russell
Posts: 529
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by Richard Russell » Thu Jun 28, 2018 11:43 am

jgharston wrote:
Thu Jun 28, 2018 9:54 am
64K strings on an 8-bit processor is very difficult as you need somewhere to put a 64K string accumulator....
So how exactly do you think BBC BASIC for Windows and BBC BASIC for SDL 2.0 support 32-bit-length strings? Do you imagine they each have a 4 Gbytes 'string accumulator'? (For the avoidance of doubt, they dont!) :roll:

User avatar
jgharston
Posts: 3248
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by jgharston » Thu Jun 28, 2018 12:16 pm

Richard Russell wrote:
Thu Jun 28, 2018 11:43 am
jgharston wrote:
Thu Jun 28, 2018 9:54 am
64K strings on an 8-bit processor is very difficult as you need somewhere to put a 64K string accumulator....
So how exactly do you think BBC BASIC for Windows and BBC BASIC for SDL 2.0 support 32-bit-length strings? Do you imagine they each have a 4 Gbytes 'string accumulator'? (For the avoidance of doubt, they dont!) :roll:
From memory at the top of the heap? But the issue is you still need to put it somewhere. 6502, Z80, 32016 and ARM BBC BASIC puts it at a fixed address, the simplest method of having a a variable-sized accumulator by putting it at the end of the heap (and relinquishing it after you've used it). Spectrum Basic has 16-bit string lengths and it accumulates strings at the top of the heap, which is impacted badly by Spectrum Basic's over-use of memory-shuffling for almost everything. It would need a lot of changes to 6502 BASIC to change from &600,X type addressing to (zp),Y type addressing, plus creating a new string variable type with two-byte allocation and length fields. I looked at it a couple of years ago and it would require quite a bit of work, I decided that for my own use if I needed blocks of text that were more than 255 byte long I'd deal with them as blocks of text not as strings, and manipulate them through a library.

There are Long String libraries for ARM BASIC (such as this which allow you to manipluate objects that are programatically long strings.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
Rich Talbot-Watkins
Posts: 1370
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by Rich Talbot-Watkins » Thu Jun 28, 2018 12:48 pm

I've occasionally contemplated whether you could improve the performance of 6502 BBC BASIC by tokenising numeric literals. With an extra 16k of ROM there'd almost certainly be room to do that along with other features. I'd imagine replacing the ASCII representation of the number with a token byte, followed by a variable number of bytes as the straight binary representation. You'd probably want to support:
  • 1 byte integer literal (decimal)
  • 1 byte integer literal (hex)
  • 2 byte integer literal (decimal)
  • 2 byte integer literal (hex)
  • 4 byte integer literal (decimal)
  • 4 byte integer literal (hex)
  • 5 byte floating point literal
Hex and decimal versions so that LIST gave you what you entered. You could also just not tokenise single digit integers so as not to waste space.

I know line number encoding works similarly, although it bends over backwards to keep the encoded number in ASCII range, but I don't think there's any particularly good reason for that, or at least no limitation that can't be worked around.

Does anyone with any familiarity of how the BASIC interpreter works know if that would give any worthwhile speed advantage? Sinclair BASIC does something similar, although that's horrendously slow! This is just a "what if?" - I know it would totally break compatibility.

User avatar
Richard Russell
Posts: 529
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by Richard Russell » Thu Jun 28, 2018 12:55 pm

jgharston wrote:
Thu Jun 28, 2018 12:16 pm
But the issue is you still need to put it somewhere.
I'm suggesting that the maximum length of a string should be determined by available memory, not by the size of a fixed-length statically-allocated 'string accumulator' (which is itself wasteful of memory).
plus creating a new string variable type with two-byte allocation and length fields.
Actually you don't need to increase the size of the string descriptor at all, you can replace the existing 'one byte current length, one byte maximum length' with 'two bytes current length (maximum length implied by current length)'. This is exactly what I did in BBC BASIC for Windows.
I looked at it a couple of years ago and it would require quite a bit of work
I wouldn't suggest it is trivial, but having gone through that exact exercise in the early days of BB4W nor is it particularly difficult.

Richard.

User avatar
Richard Russell
Posts: 529
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by Richard Russell » Thu Jun 28, 2018 1:23 pm

Rich Talbot-Watkins wrote:
Thu Jun 28, 2018 12:48 pm
I know line number encoding works similarly, although it bends over backwards to keep the encoded number in ASCII range, but I don't think there's any particularly good reason for that, or at least no limitation that can't be worked around.
The reason is so that 'forward searches' (such as to find the ELSE in an IF clause) can be performed very efficiently, because you know you won't encounter the token for ELSE (in this case) in any other context. If you allow arbitrary binary constants to appear in a program, any such search needs to avoid a 'false match' on one of the bytes of such a constant, which means it will be slower.
Does anyone with any familiarity of how the BASIC interpreter works know if that would give any worthwhile speed advantage?
I looked into this, but decided against it - partly for the above reason and partly because I wanted to encourage the use of 'symbolic' constants (i.e. variables whose value never changes) rather than 'literal' constants. Using symbolic constants makes it easier and safer to make changes to a program, without having to laboriously find and edit individual constants.

What I ended up with is an approach very similar to what you describe, except that I use the embedded binary values for 'variable pointers' rather than 'numeric constants' (this substitution is done, optionally, by the cruncher). Thus the speed benefit applies potentially to all variables (both numeric and string) and even to PROC and FN calls. And because the binary pointers are allocated by the cruncher it can avoid using any values that might contain false matches for searchable tokens.

Richard.

User avatar
Rich Talbot-Watkins
Posts: 1370
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by Rich Talbot-Watkins » Thu Jun 28, 2018 2:14 pm

Richard Russell wrote:
Thu Jun 28, 2018 1:23 pm
The reason is so that 'forward searches' (such as to find the ELSE in an IF clause) can be performed very efficiently, because you know you won't encounter the token for ELSE (in this case) in any other context. If you allow arbitrary binary constants to appear in a program, any such search needs to avoid a 'false match' on one of the bytes of such a constant, which means it will be slower.
Ah yes, ELSE is the problem. Otherwise, going to the end of a line is easy (because of the line length byte). Does BASIC also get fooled by the ELSE token appearing in string literals?
Richard Russell wrote:
Thu Jun 28, 2018 1:23 pm
I looked into this, but decided against it - partly for the above reason and partly because I wanted to encourage the use of 'symbolic' constants (i.e. variables whose value never changes) rather than 'literal' constants. Using symbolic constants makes it easier and safer to make changes to a program, without having to laboriously find and edit individual constants.

What I ended up with is an approach very similar to what you describe, except that I use the embedded binary values for 'variable pointers' rather than 'numeric constants' (this substitution is done, optionally, by the cruncher). Thus the speed benefit applies potentially to all variables (both numeric and string) and even to PROC and FN calls. And because the binary pointers are allocated by the cruncher it can avoid using any values that might contain false matches for searchable tokens.
Yes, I also had a similar idea with tokenising symbol names, putting the mapping from token to name in a dummy block beyond the end of the BASIC program. Seemed like it'd be harder to implement though, but definitely with a higher runtime advantage!

User avatar
Richard Russell
Posts: 529
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Expanding BBC BASIC on Acorn 8 bit machines

Post by Richard Russell » Thu Jun 28, 2018 3:00 pm

Rich Talbot-Watkins wrote:
Thu Jun 28, 2018 2:14 pm
Otherwise, going to the end of a line is easy (because of the line length byte).
Do Sophie's BASICs 'remember' the line length byte then? In mine I don't (indeed I don't even see it if I've arrived on the line via a GOTO or PROC call etc.) so to find the end of a line, e.g. when processing a REM, I search for the terminating CR.
Does BASIC also get fooled by the ELSE token appearing in string literals?
Mine don't (at the cost of a search overhead) - in the context of an extended character set like UTF-8 it would be unacceptable - but I don't know about Sophie's. Should be easy enough to test.

Richard.

Post Reply