Why was BBC BASIC so fast?

bbc/electron apps, languages, utils, educational progs, demos + more
Coeus
Posts: 1945
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: Why was BBC BASIC so fast?

Post by Coeus »

Lardo Boffin wrote:
Tue Oct 27, 2020 9:37 am
I ran the speed test on my Tatung Einstein TC01 using Z80 BBC BASIC:
Here are some figures from B-Em which I believe has the Z80 timing accurate.
realclock.png
realclock.png (3.77 KiB) Viewed 1161 times
That has a clock speed of 6Mhz so if everything else were the same it would be 1.5x as fast as the Einstein. Scaling up the Einstein figures gives

Code: Select all

Really real REPEAT loop 2.16Mhz
Integer REPEAT loop     1.845Mhz
Really real FOR loop    1.335Mhz
Integer FOR loop        0.93Mhz
Trig/Log test           5.10Mhz
String manipulation     1.90Mhz
Procedure call          2.145Mhz
GOSUB call              1.455Mhz
Combined Average        2.145Mhz
That's pretty close so suggests there problem isn't much if any memory access contention on the Einstein, very different from the Sinclair machines.
User avatar
jgharston
Posts: 4257
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Why was BBC BASIC so fast?

Post by jgharston »

Coeus wrote:
Tue Oct 27, 2020 11:41 am
jgharston wrote:
Mon Oct 26, 2020 10:52 pm
Fixed.
I can't see any difference and the files on that page, both ZIP and BIN, seem to be the same as before.
I bet the link is broken. I'll fix it when I get home and can FTP to it. The ZIP should contain the BIN and ASM both dated 26-Oct-2020.

I've probably called it something like EhBasic222p4v1 or something.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_
User avatar
Lardo Boffin
Posts: 2290
Joined: Thu Aug 06, 2015 7:47 am
Contact:

Re: Why was BBC BASIC so fast?

Post by Lardo Boffin »

Coeus wrote:
Tue Oct 27, 2020 2:35 pm
Lardo Boffin wrote:
Tue Oct 27, 2020 9:37 am
I ran the speed test on my Tatung Einstein TC01 using Z80 BBC BASIC:
That's pretty close so suggests there problem isn't much if any memory access contention on the Einstein, very different from the Sinclair machines.
The Tatung has 16K of dedicated video RAM outside of the 64K main RAM so presumably that helps.

Multiplied by 1.5 the figures are impressively close! Does the co-proc version gain a small advantage due to only doing language processing and no house keeping / handling interrupts etc.?
Last edited by Lardo Boffin on Tue Oct 27, 2020 7:15 pm, edited 1 time in total.
Adventure Language on GitHub
Atom, issue 5
Elk
A number of econetted (is that a word?) Beebs
BBC Master, Datacentre + HDD, pi co-proc, econet, NULA
User avatar
jgharston
Posts: 4257
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Why was BBC BASIC so fast?

Post by jgharston »

jgharston wrote:
Tue Oct 27, 2020 2:59 pm
Coeus wrote:
Tue Oct 27, 2020 11:41 am
jgharston wrote:
Mon Oct 26, 2020 10:52 pm
Fixed.
I can't see any difference and the files on that page, both ZIP and BIN, seem to be the same as before.
I bet the link is broken. I'll fix it when I get home and can FTP to it. The ZIP should contain the BIN and ASM both dated 26-Oct-2020.
I've probably called it something like EhBasic222p4v1 or something.
Do'h! My FTP client was still resolving to the old server. Really fixed now. :)

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_
User avatar
1024MAK
Posts: 10482
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Why was BBC BASIC so fast?

Post by 1024MAK »

Lardo Boffin wrote:
Tue Oct 27, 2020 6:06 pm
Coeus wrote:
Tue Oct 27, 2020 2:35 pm
Lardo Boffin wrote:
Tue Oct 27, 2020 9:37 am
I ran the speed test on my Tatung Einstein TC01 using Z80 BBC BASIC:
That's pretty close so suggests there problem isn't much if any memory access contention on the Einstein, very different from the Sinclair machines.
The Tatung has 16K of dedicated video RAM outside of the 64K main RAM so presumably that helps.
That’s because it uses the Texas Instruments TMS9129 Video Display Controller (VDC). These map to a small range of I/O addresses in the microprocessors I/O space and have their own video RAM (which is not connected to the microprocessor). Various other machines have a similar arrangement.

Mark
Coeus
Posts: 1945
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: Why was BBC BASIC so fast?

Post by Coeus »

Lardo Boffin wrote:
Tue Oct 27, 2020 9:37 am
I ran the speed test on my Tatung Einstein TC01 using Z80 BBC BASIC:
Multiplied by 1.5 the figures are impressively close! Does the co-proc version gain a small advantage due to only doing language processing and no house keeping / handling interrupts etc.?
I don't think there will be any interrupt activity on the second processor during that test. Interrupts can be used as part of the tube transfers but, once loaded, that test runs entirely from RAM and sending characters over the tube to be printed does not use interrupts on the client (2nd proc).

We also need to be careful about parallelism when measuring performance. On the I/O processor, when one calls OSWRCH to write a character to the screen, the calling program then has to wait for the screen write to happen before OSWRCH returns. On the 2nd processor, OSWRCH just stuffs the character into a FIFO in the tube ULA and then the I/O processor will receive it, and print it, while the 2nd processor gets on with the next thing. Obviouly the FIFO has limited depth so sometimes OSWRCH will have to wait because the FIFO is full, but that's going to be less than 100% of the time.

For this benchmark, though, I don't think it makes any difference as the timed loops themselves don't generate output - the printing happens beween tests.

So back to the overhead of interrupts the BBC MOS uses interrupts extensively. Many of them only happen in response to things like typing keys, characters arriving from RS423/tape or being printed on the printer, but there is a regular timer interrupt, a VSYNC interrupt and end of ADC conversion that just happen every so often regardless unless dsabled.

But the real question for the comparison is what level of interrupt activity there is on the Einstein.
User avatar
Lardo Boffin
Posts: 2290
Joined: Thu Aug 06, 2015 7:47 am
Contact:

Re: Why was BBC BASIC so fast?

Post by Lardo Boffin »

Coeus wrote:
Wed Oct 28, 2020 2:06 pm
Lardo Boffin wrote:
Tue Oct 27, 2020 9:37 am
I ran the speed test on my Tatung Einstein TC01 using Z80 BBC BASIC:
Multiplied by 1.5 the figures are impressively close! Does the co-proc version gain a small advantage due to only doing language processing and no house keeping / handling interrupts etc.?
But the real question for the comparison is what level of interrupt activity there is on the Einstein.
This was what I was wondering. I assumed the interrupts would be minimal on the co-proc but would be ‘normal’ (whatever that is for the TC01) on the tatung hence the co-proc being slightly faster.
Adventure Language on GitHub
Atom, issue 5
Elk
A number of econetted (is that a word?) Beebs
BBC Master, Datacentre + HDD, pi co-proc, econet, NULA
Coeus
Posts: 1945
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: Why was BBC BASIC so fast?

Post by Coeus »

jgharston wrote:
Tue Oct 27, 2020 7:14 pm
Do'h! My FTP client was still resolving to the old server. Really fixed now. :)
So EhBASIC has the same issue with jumping out of FOR loops as BBC BASIC. Running the reference implementation:

Code: Select all

 1  GOTO 10
 5 COUNT = COUNT + 1
 6  GOTO 50
 10  DIM PRIMES(99)
 20 PRIMES(0) = 2
 25  PRINT PRIMES(0)
 30 COUNT = 3
 40  FOR FOUND = 1 TO 99
 50  FOR INDEX = 0 TO (FOUND - 1)
 60 V = COUNT / PRIMES(INDEX)
 65  IF ( V =  INT(V)) THEN  GOTO 5
 70  NEXT INDEX
 80  PRINT COUNT
 90 PRIMES(FOUND) = COUNT
 100 COUNT = COUNT + 1
 110  NEXT FOUND
 120  END
I get "Out of memory error in line 60". It also has a quirk that the ( of INT( must have no separating space or this is interpreted as an array access rather than a function call. So modifying it to deal with the FOR loop problem:

Code: Select all

 1  GOTO 10
 5 INDEX=FOUND - 1
 6 NEXT INDEX
 7 COUNT = COUNT + 1
 8  GOTO 50
 10  DIM PRIMES(99)
 20 PRIMES(0) = 2
 25  PRINT PRIMES(0)
 30 COUNT = 3
 40  FOR FOUND = 1 TO 99
 50  FOR INDEX = 0 TO (FOUND - 1)
 60 V = COUNT / PRIMES(INDEX)
 65  IF ( V =  INT(V)) THEN  GOTO 5
 70  NEXT INDEX
 80  PRINT COUNT
 90 PRIMES(FOUND) = COUNT
 100 COUNT = COUNT + 1
 110  NEXT FOUND
 120  END
and it's really slow. It took 3m15s running on the 6502 2nd processor (because that's what it is supplied assembled for). I can't run the exact same code in BBC BASIC because COUNT is a reserved word but changing that to COUNU (same length so no advantage) gives a timing of 27s so over 7x the speed. Running the BBC optimised version (below) completes in 10.7s on the same 2nd processor.

Code: Select all

   10DIMP%(100)
   20C%=2
   30FORF%=1TO100
   40PRINTC%
   50P%(F%)=C%
   60C%=C%+1
   70FORI%=1TOF%
   80IFC%MODP%(I%)=0THEN120
   90NEXTI%
  100NEXTF%
  110END
  120I%=F%
  130NEXTI%
  140GOTO60
User avatar
jgharston
Posts: 4257
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Why was BBC BASIC so fast?

Post by jgharston »

Coeus wrote:
Wed Oct 28, 2020 2:06 pm
We also need to be careful about parallelism when measuring performance.
...
For this benchmark, though, I don't think it makes any difference as the timed loops themselves don't generate output - the printing happens beween tests.
If you read the documentation and the REMs, ClockSp is specifically coded to just solely explicitly test the speed of the /interpreter/ *NOT* the I/O system.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_
User avatar
jgharston
Posts: 4257
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Why was BBC BASIC so fast?

Post by jgharston »

Coeus wrote:
Wed Oct 28, 2020 4:32 pm
So EhBASIC has the same issue with jumping out of FOR loops as BBC BASIC. Running the reference implementation:
No, what you mean is the author of the code has the same problem in his brain causing him to write broken FOR/NEXT loops
It also has a quirk that the ( of INT( must have no separating space or this is interpreted as an array access rather than a function call. So modifying it to deal with the FOR loop problem:
I think that's one of the Patch5 bugfixes.

With so few people working in the office at work, we've got the service desk queue down to single figures (it's usually in the mid-100s!!!), I'm tempted to take some coding to work instead of twiddling my fingers and clicking REFRESH on the incident dashboard every 30 minutes. :)

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_
User avatar
jgharston
Posts: 4257
Joined: Thu Sep 24, 2009 12:22 pm
Location: Whitby/Sheffield
Contact:

Re: Why was BBC BASIC so fast?

Post by jgharston »

jgharston wrote:
Wed Oct 28, 2020 5:36 pm
Coeus wrote:
Wed Oct 28, 2020 4:32 pm
So EhBASIC has the same issue with jumping out of FOR loops as BBC BASIC. Running the reference implementation:
No, what you mean is the author of the code has the same problem in his brain causing him to write broken FOR/NEXT loops
It also has a quirk that the ( of INT( must have no separating space or this is interpreted as an array access rather than a function call. So modifying it to deal with the FOR loop problem:
I think that's one of the Patch5 bugfixes.

With so few people working in the office at work, we've got the service desk queue down to single figures (it's usually in the mid-100s!!!), I'm tempted to take some coding to work instead of twiddling my fingers and clicking REFRESH on the incident dashboard every 30 minutes. :)
Edit:
1 GOTO 10
5 ...
8 GOTO 50
...
GOTO 5

what concussed sort of code is this?

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.32
(C) Copyright J.G.Harston 1989,2005-2020
>_
User avatar
BigEd
Posts: 3744
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

Re: Why was BBC BASIC so fast?

Post by BigEd »

A wild guess: in Fortran you get FOR loops and GOTO and you can go wild. As in simple Basics - but not the Basics we have in mind.

I do like prime number programs, and yet though they don't strongly lend themselves to structured programming.
Coeus
Posts: 1945
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: Why was BBC BASIC so fast?

Post by Coeus »

jgharston wrote:
Wed Oct 28, 2020 5:39 pm
Edit:
1 GOTO 10
5 ...
8 GOTO 50
...
GOTO 5
I had assumed It's written for a BASIC in which the only way for the program to finish is to get to the last statement, so there can be nothing after that. And don't many assembler programs start with a jump to some initialisation code?

My BBC optimised version also has a little "diversion" like this one but I have put it at the end rather than the beginning. Or maybe the author put this little diversion at the start of the program so finding the line number would be faster.

Of course, in the BBC Basic version one could also write it with a multi-statement line as:

Code: Select all

   10DIMP%(100)
   20C%=2
   30FORF%=1TO100
   40PRINTC%
   50P%(F%)=C%
   60C%=C%+1
   70FORI%=1TOF%
   80IFC%MODP%(I%)=0THENI%=F%:NEXTI%:GOTO60
   90NEXTI%
  100NEXTF%
  110END
There isn't really an elegant solution without a statement that means specifically "break out of this loop", i.e. the C break statement.
Coeus
Posts: 1945
Joined: Mon Jul 25, 2016 12:05 pm
Contact:

Re: Why was BBC BASIC so fast?

Post by Coeus »

BigEd wrote:
Wed Oct 28, 2020 5:59 pm
A wild guess: in Fortran you get FOR loops and GOTO and you can go wild. As in simple Basics - but not the Basics we have in mind.
So why in simple BASICs?

In compiled languages, loops are generally lexically scoped. The compiler does the housekeeping and the generated code can just to the test and do to the address determined by the compiler so there is no leakage inherent from the loop control, though obviously you can introduce your own leakage depending on what you put in the loop.

I suppose a very simplistic BASIC interpreter could offer the same if NEXT searched the program for a FOR with the same variable name and thus did not need to put anything on a stack. That could possibly be speeded up instead by keeping an index of loop control variables and the address of the corresponding FOR.
User avatar
BigEd
Posts: 3744
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

Re: Why was BBC BASIC so fast?

Post by BigEd »

Umm, yes, it's a good point, how do I expect an interpreter to be so forgiving about non-nested FOR/NEXT... I suppose instead of a stack it could keep a list, and if it doesn't find a record then that's a NEXT without FOR, which it could either be forgiving about or throw an error. It needn't ever tidy up the list, or expect things to be nested.
User avatar
1024MAK
Posts: 10482
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Why was BBC BASIC so fast?

Post by 1024MAK »

In some BASIC versions, you can’t have multi-statement lines, hence an IF THEN will GOTO somewhere else to do whatever is needed. It’s going to the second line of the program for maximum speed (assuming the search for the correct line number starts from the beginning of the program).

Also in some BASIC versions, you can GOTO a FOR statement as many times as you like, or indeed have more than one FOR statement using the same variable before the execution gets to a matching NEXT statement. The last FOR statement encountered for that variable resets the values used by the FOR variable, and this FOR statement is the one that the NEXT will loop back to.

Mark
User avatar
lurkio
Posts: 3145
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Why was BBC BASIC so fast?

Post by lurkio »

1024MAK wrote:
Wed Oct 28, 2020 7:27 pm
Also in some BASIC versions, you can GOTO a FOR statement as many times as you like, or indeed have more than one FOR statement using the same variable before the execution gets to a matching NEXT statement. The last FOR statement encountered for that variable resets the values used by the FOR variable, and this FOR statement is the one that the NEXT will loop back to.
Do you happen to know if that's what any of the TRS-80 BASICs did?

:?:
jimmy
Posts: 115
Joined: Tue May 06, 2008 7:37 pm
Contact:

Re: Why was BBC BASIC so fast?

Post by jimmy »

Can anybody confirm that BBC BASIC Z80 v3.x is slower than v2.x?
I've just tried with the v3.10 BBC BASIC source code (from CPMish Git area - thank you RTR for allowing this!) and the timings are different (for the worse):
Red border screenshot shows v3.10 on a ZX Spectrum 128
slowBBCbasic30_201_128.png
Blue border screenshot shows v2.20 (JGH's version) on a ZX Spectrum 128
slowBBCbasic22_201_128.png
I'm happy for it to be my (rough) conversion at fault - and I've tried to confirm using the generic CP/M BBC BASIC 3.00 version, but this doesn't support TIME so the benchmarks won't work. All I've done so far is to take all the source code fragments and put them into one file (with some label renaming) and add a simple I/O handler. There are some opportunities for optimisation, but even they can't close this performance gap.
User avatar
1024MAK
Posts: 10482
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Why was BBC BASIC so fast?

Post by 1024MAK »

Are they running from the same memory? Or from different memory areas?

I ask because some RAM is contended on the ZX Spectrum, so how fast the code runs depends on which part of memory is being used.

Mark
jimmy
Posts: 115
Joined: Tue May 06, 2008 7:37 pm
Contact:

Re: Why was BBC BASIC so fast?

Post by jimmy »

I''ve tried to avoid contended memory wherever possible, so PAGE for BASIC starts at &8000, the BASIC Z80 code is in ROM space &0000-&3FFF, and the BASIC sysvars are at &F000. The only values in contended memory are to do with I/O routines - as I have to provide input and output routines since I've paged out the ZX ROM. The benchmarks are slightly flattering for the Spectrum as the 128 model is used so the CPU speed is slightly increased to 3.54MHz.
Richard has kindly got in touch with me to suggest a few reasons why v3 is slower than v2. Unfortunately the v2 source is not available, but I think a dissasembly using the v3 source routines as a guide should be possible.
I was surprised to find out that the ZX Spectrum 'wastes' more than 1% of CPU time scanning the keyboard 50 times a second. By changing the standard IM1 routine to abort a keyscan if no keys are pressed, I got an instant speed-up for BBC BASIC increasing the combined average speed by 0.01MHz.
I've come up with a few other ideas for improving the speed. I've already taken the quick win of page-aligning the Dispatch table, allowing the jump code to be shortened and simplified.
136_DispatchTable_Page_Aligned.png
User avatar
scruss
Posts: 325
Joined: Sun Jul 01, 2018 4:12 pm
Location: Toronto
Contact:

Re: Why was BBC BASIC so fast?

Post by scruss »

Hmm, BBC BASIC for Amstrad CPC (v2) turns in some dismal but not unexpected numbers:
clocksp on emulated Amstrad CPC, Z80 BBC BASIC v2
clocksp on emulated Amstrad CPC, Z80 BBC BASIC v2
clocksp-v2.png (4.74 KiB) Viewed 649 times
The CPC's clock ran at an effective 3.3 MHz, so I might expect slightly slower numbers than the ZX Spectrum.

Despite the slowness, the Amstrad completed the test in 56 s, while a BBC might do it in around 49 s. I'm not sure why I feel this, but I think I'd prefer a benchmark that runs the same amount of code on each machine rather than a variable amount depending on a calibration run and tweaked constants.
User avatar
BigEd
Posts: 3744
Joined: Sun Jan 24, 2010 10:24 am
Location: West Country
Contact:

Re: Why was BBC BASIC so fast?

Post by BigEd »

Indeed, ClockSp does autocalibrate - which is quite handy when the range of machines goes from pretty slow to very fast indeed.
User avatar
Richard Russell
Posts: 1908
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Why was BBC BASIC so fast?

Post by Richard Russell »

scruss wrote:
Sat Nov 14, 2020 8:48 pm
BBC BASIC for Amstrad CPC (v2) turns in some dismal but not unexpected numbers
You are running the old version of ClockSp in which the 'real' measurements are nothing of the sort (they are actually integer loops), making Z80 BBC BASIC appear much faster than it actually is. For a meaningful comparison you need to run the modified version of the program which reports "Really real REPEAT loop" and "Really real FOR loop".
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
User avatar
scruss
Posts: 325
Joined: Sun Jul 01, 2018 4:12 pm
Location: Toronto
Contact:

Re: Why was BBC BASIC so fast?

Post by scruss »

Richard Russell wrote:
Sat Nov 14, 2020 10:09 pm
You are running the old version of ClockSp in which the 'real' measurements are nothing of the sort …
· I'm running the same version as jimmy.
· It's also the same version on JGH's site and in the beebjit emulator
· The really real version isn't anywhere I can find.
User avatar
Richard Russell
Posts: 1908
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

Re: Why was BBC BASIC so fast?

Post by Richard Russell »

scruss wrote:
Sun Nov 15, 2020 1:41 am
The really real version isn't anywhere I can find.
It's in this very thread! Here's a direct link to the post containing the listing; Coeus used it in his post listing the 'reference' Z80 Second Processor results from B-Em.

The original version is only suitable for testing emulators running the 6502 (or ARM) BASIC interpreter, it gives misleading results when run with any of my interpreters (Z80, 8086, IA-32 or the cross-platform editions written in C) because they detect that the so-called 'real' loops are actually using integers.
I am suffering from 'cognitive decline' and depression. If you have a comment about the style or tone of this message please report it to the moderators by clicking the exclamation mark icon, rather than complaining on the public forum.
Kweepa
Posts: 31
Joined: Mon Dec 16, 2013 11:45 pm
Contact:

Re: Why was BBC BASIC so fast?

Post by Kweepa »

Has anyone analysed the differences between BBC, Master, and Master Compact BASIC?
I'm amazed at the improvements in the speed of the math routines over the versions.
User avatar
1024MAK
Posts: 10482
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Why was BBC BASIC so fast?

Post by 1024MAK »

lurkio wrote:
Wed Oct 28, 2020 8:17 pm
1024MAK wrote:
Wed Oct 28, 2020 7:27 pm
Also in some BASIC versions, you can GOTO a FOR statement as many times as you like, or indeed have more than one FOR statement using the same variable before the execution gets to a matching NEXT statement. The last FOR statement encountered for that variable resets the values used by the FOR variable, and this FOR statement is the one that the NEXT will loop back to.
Do you happen to know if that's what any of the TRS-80 BASICs did?

:?:
The only TRS-80 that I have is a TRS-80 Model 100
See photos...
TRS-80 Model 100
TRS-80 Model 100
Hello StarDot forum
Hello StarDot forum
Program listing
Program listing
Program output
Program output
Mark
User avatar
lurkio
Posts: 3145
Joined: Wed Apr 10, 2013 12:30 am
Location: Doomawangara
Contact:

Re: Why was BBC BASIC so fast?

Post by lurkio »

1024MAK wrote:
Sun Nov 15, 2020 7:20 pm
lurkio wrote:
Wed Oct 28, 2020 8:17 pm
Do you happen to know if that's what any of the TRS-80 BASICs did?
...
Image
Thanks for that! Of course, I could be a smartarse and point out that that doesn't prove anything because even a Beeb will display ten iterations of the loop, and your photo only shows seven! But I presume you're trying to say that the Model 100 keeps going indefinitely. Nice demo.

:idea:
Last edited by lurkio on Sun Nov 15, 2020 7:48 pm, edited 1 time in total.
User avatar
BeebMaster
Posts: 3862
Joined: Sun Aug 02, 2009 5:59 pm
Location: Lost in the BeebVault!
Contact:

Re: Why was BBC BASIC so fast?

Post by BeebMaster »

Can some BASICs not do nested loops at all then? I think I would find that very limiting.
Image
User avatar
1024MAK
Posts: 10482
Joined: Mon Apr 18, 2011 5:46 pm
Location: Looking forward to summer in Somerset, UK...
Contact:

Re: Why was BBC BASIC so fast?

Post by 1024MAK »

Another ‘unconventional’ FOR - NEXT program:
Program listing
Program listing
Program output
Program output
Mark
Post Reply

Return to “8-bit acorn software: other”