BBC BASIC mysteries and speculation

Discuss all aspects of programming here. From 8-bit through to modern architectures.
Post Reply
User avatar
Rich Talbot-Watkins
Posts: 1510
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

BBC BASIC mysteries and speculation

Post by Rich Talbot-Watkins » Thu Jun 13, 2019 8:56 am

(This is split off from this thread)
Richard Russell wrote:
Sun Jun 09, 2019 9:06 am
Later versions of BBC BASIC (I'm not exactly sure when this was introduced) support an even easier method using dedicated statements:

Code: Select all

      OFF : REM Disable text cursor/caret
      ON  : REM Enable text cursor/caret
This certainly works in all 'modern' versions including BBC BASIC for Windows, BBC BASIC for SDL 2.0 and Matrix Brandy BASIC.
I think it's a shame Sophie didn't think to squeeze ON and OFF into the original BBC BASIC to control the cursor; the tokens are already there, and I think the space could've been found in the ROM.

This VDU 23;8202;0;0;0; sequence always looked extremely arcane in BBC BASIC listings.
Last edited by Rich Talbot-Watkins on Thu Jun 13, 2019 12:12 pm, edited 1 time in total.

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

Re: VDU ?

Post by Richard Russell » Thu Jun 13, 2019 9:23 am

Rich Talbot-Watkins wrote:
Thu Jun 13, 2019 8:56 am
I think it's a shame Sophie didn't think to squeeze ON and OFF into the original BBC BASIC to control the cursor; the tokens are already there, and I think the space could've been found in the ROM.
I expect ON could have been implemented, as it's already a statement token, but I'm less sure about OFF (token value &87). The need for both 'left' and 'right' tokens for the pseudo-variables may imply that the early interpreters required statement tokens to be grouped together in a block (although I've never understood why the 'function' and 'statement' blocks couldn't have been overlapping, with the pseudo-variable tokens in both).
This VDU 23;8202;0;0;0; sequence always looked extremely arcane in BBC BASIC listings.
It's a pity that VDU 23,1,0... wasn't substituted once OS 1.0 (and later) became commonplace.

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

Re: VDU ?

Post by Rich Talbot-Watkins » Thu Jun 13, 2019 10:12 am

Richard Russell wrote:
Thu Jun 13, 2019 9:23 am
I expect ON could have been implemented, as it's already a statement token, but I'm less sure about OFF (token value &87). The need for both 'left' and 'right' tokens for the pseudo-variables may imply that the early interpreters required statement tokens to be grouped together in a block (although I've never understood why the 'function' and 'statement' blocks couldn't have been overlapping, with the pseudo-variable tokens in both).
I think OFF would have to be moved to the statement block, but if it had been implemented from the start that way, there wouldn't have been a problem (although I realise that it makes ON ERROR OFF ambiguous - I assume BASIC V just won't let you turn the cursor off in an error handler?).

Looking at the token list, I noticed some curious anomalies - it's mostly more-or-less alphabetical (I say more-or-less, because there are things like GCOL following GOTO), but then there are some keywords which are really in the wrong place:
  • VDU is between ON and PLOT
  • COLOUR is between STOP and TRACE
  • SOUND is the first in the list (before BPUT)
  • OSCLI is the last in the list (after WIDTH)
We know OSCLI was added later, so it just got the last available token. But - pure speculation - is it possible that some of these keywords had different names originally? BEEP instead of SOUND? OSWRCH instead of VDU (he asks, clutching at straws)? Can't think of anything remotely reasonable for COLOUR.
It's a pity that VDU 23,1,0... wasn't substituted once OS 1.0 (and later) became commonplace.
Yes, indeed. Still magic numbers of course, but at least it's not relying on hardware-specific register writing which would've had to be emulated on other platforms. BBC BASIC always had its share of magic numbers (PLOT for example), but having all the display code in the OS instead of BASIC was great design, and I guess it's good that the rest of the ROM was used for high-level constructs like PROC and fast floating-point code, instead of filling it up with keyword aliases for OS display driver operations.

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

Re: VDU ?

Post by Rich Talbot-Watkins » Thu Jun 13, 2019 10:33 am

Rich Talbot-Watkins wrote:
Thu Jun 13, 2019 10:12 am
We know OSCLI was added later, so it just got the last available token. But - pure speculation - is it possible that some of these keywords had different names originally? BEEP instead of SOUND? OSWRCH instead of VDU (he asks, clutching at straws)? Can't think of anything remotely reasonable for COLOUR.
GRAPHICS instead of GCOL
TEXT instead of COLOUR

That would make everything completely alphabetical.

(Here's the token list in case anyone wants to look.)
Last edited by Rich Talbot-Watkins on Thu Jun 13, 2019 10:38 am, edited 2 times in total.

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

Re: VDU ?

Post by lurkio » Thu Jun 13, 2019 10:40 am

Rich Talbot-Watkins wrote:
Thu Jun 13, 2019 10:33 am
Rich Talbot-Watkins wrote:
Thu Jun 13, 2019 10:12 am
... is it possible that some of these keywords had different names originally? BEEP instead of SOUND? OSWRCH instead of VDU (he asks, clutching at straws)? Can't think of anything remotely reasonable for COLOUR.
GRAPHICS instead of GCOL
TEXT instead of COLOUR

That would make everything completely alphabetical.
Ah. That makes more sense than the word for COLOUR that I thought of and was going to embarrass myself with. (Oh, what the heck — it was TINT).

:oops:

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

Re: VDU ?

Post by lurkio » Thu Jun 13, 2019 10:43 am

BeebMan2018 wrote:
Sat Jun 08, 2019 10:46 pm
Hey guys,

VDU23;8202;0;0;0; ...
Have we scared you off yet..?!

:wink:

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

Re: VDU ?

Post by Rich Talbot-Watkins » Thu Jun 13, 2019 10:46 am

lurkio wrote:
Thu Jun 13, 2019 10:40 am
Ah. That makes more sense than the word for COLOUR that I thought of and was going to embarrass myself with. (Oh, what the heck — it was TINT).
Yeah, I already thought of TINT and dismissed it. The only reason BASIC V had TINT was to work around the fact that Acorn had decided to use COLOUR >= 128 as 'background', instead of introducing separate keywords (or an additional parameter) for specifying foreground and background colours. With 256 colours now available, they needed some way to be able to specify all of them without breaking older stuff, but I bet they hated it.

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

Re: VDU ?

Post by lurkio » Thu Jun 13, 2019 10:53 am

Rich Talbot-Watkins wrote:
Thu Jun 13, 2019 10:46 am
lurkio wrote:
Thu Jun 13, 2019 10:40 am
Ah. That makes more sense than the word for COLOUR that I thought of and was going to embarrass myself with. (Oh, what the heck — it was TINT).
Yeah, I already thought of TINT and dismissed it. The only reason BASIC V had TINT
Ah. I didn't know that it did! So my suggestion was even more embarrassing than I thought.

I’ll get me coat.

#-o

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

Re: VDU ?

Post by Richard Russell » Thu Jun 13, 2019 11:00 am

Rich Talbot-Watkins wrote:
Thu Jun 13, 2019 10:46 am
but I bet they hated it.
I hated it so much I didn't implement it in BBC BASIC for Windows or BBC BASIC for SDL 2.0 (to be fair I didn't need to, since I use a palette even in 'non-paletted' modes, something which proved controversial when I tried to justify it here, but which I still think is better than Acorn's approach). Instead I use TINT as a function (analogous with POINT) which returns an RGB value, rather than a palette index, at the specified coordinates.
Last edited by Richard Russell on Thu Jun 13, 2019 12:45 pm, edited 1 time in total.

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

Re: VDU ?

Post by Richard Russell » Thu Jun 13, 2019 11:10 am

Rich Talbot-Watkins wrote:
Thu Jun 13, 2019 10:12 am
I assume BASIC V just won't let you turn the cursor off in an error handler?
I expect this would work (it does in BB4W and BBCSDL):

Code: Select all

      ON ERROR : OFF
But - pure speculation - is it possible that some of these keywords had different names originally?
I'm certain you're right. I don't have a specific memory of that from the time, but it's such a plausible explanation.
I guess it's good that the rest of the ROM was used for high-level constructs like PROC and fast floating-point code, instead of filling it up with keyword aliases for OS display driver operations.
Indeed, it would have been wasteful to include the aliases like CIRCLE, ELLIPSE, ORIGIN, RECTANGLE etc. which appeared once space wasn't such a consideration.

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

Re: VDU ?

Post by Richard Russell » Thu Jun 13, 2019 11:36 am

I hope this isn't taking this thread too far off-topic, but whilst we're discussing tokens there are two big mysteries that I have never been able to get an explanation for in more than 30 years:
  1. As referred to earlier, what is the reason for the pseudo-variables (PTR, PAGE, TIME, LOMEM, HIMEM) each having a pair of tokens, one for their use as a 'function' ('right') and one as a 'statement' ('left')? In none of my BBC BASIC interpreters has this been of any benefit, and the complication in the parsing/tokenising routine, to determine which to use, is considerable. It's true that my early interpreters required the function tokens to be in a contiguous block, and the statement tokens similarly, but that could easily have been achieved without giving the pseudo-variables a pair of tokens simply by making the blocks overlap.
  2. When extra tokens were required, for the new keywords added in BASIC V, why were two-byte tokens introduced when there were 30 unused single-byte tokens still available (&01 to &1F, excluding &0D which was already in use)? To this day BB4W and BBCSDL have not needed to use two-byte tokens, and there are still several single-byte tokens as yet unused. On any CPU supporting signed 8-bit arithmetic with an overflow flag (and I believe that includes the 6502) testing a byte to see if it is in the range &80 to &1F (-128 to +31) is no more complicated than testing for the range &80 to &FF (-128 to -1), so those extra tokens are available with zero run-time overhead!
Sophie must know the answer to both of these (if she can remember) but I've never had the opportunity to ask her, or at least I've never thought to.

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

Re: BBC BASIC mysteries and speculation

Post by Rich Talbot-Watkins » Thu Jun 13, 2019 12:51 pm

Richard Russell wrote:
Thu Jun 13, 2019 11:36 am
As referred to earlier, what is the reason for the pseudo-variables (PTR, PAGE, TIME, LOMEM, HIMEM) each having a pair of tokens, one for their use as a 'function' ('right') and one as a 'statement' ('left')?
I can only assume that it simplified the execution implementation to have two different tokens for the pseudovariables (read or write), and hence two different execution addresses; but, as you say, they could have had two tables of execution addresses for tokens - one for statements and one for expression elements - and overlapped the index range.
Richard Russell wrote:
Thu Jun 13, 2019 11:36 am
When extra tokens were required, for the new keywords added in BASIC V, why were two-byte tokens introduced when there were 30 unused single-byte tokens still available (&01 to &1F, excluding &0D which was already in use)?
I've wondered the same thing about the extra tokens, particularly since Sophie already used &7F for OTHERWISE.

I've got a few to add of my own:
  • Why are immediate mode only commands a 'thing'? Why is it any kind of big deal to write LIST or NEW or SAVE in a program? Seems a weird distinction to make, particularly when other BASICs are usually able to LIST or even NEW themselves!
  • Why did Acorn/BBC think that COUNT was a worthwhile keyword, being both non-standard and of very limited use in my opinion? Likewise WIDTH. I don't think I ever used either of them!
  • The special line number encoding (token &8D) was used I guess so that RENUMBER didn't alter line lengths. But BBC BASIC clearly knows how to replace a line with one of a different length into the middle of a program, so was it really that necessary? Also, going the other way, could this encoding have been used as an optimisation for any integer literal within the allowed range in a program, to improve performance? Maybe only falling back on it for 3 digit numbers or greater.
Richard Russell wrote:
Thu Jun 13, 2019 11:10 am
Rich Talbot-Watkins wrote:
Thu Jun 13, 2019 10:12 am
But - pure speculation - is it possible that some of these keywords had different names originally?
I'm certain you're right. I don't have a specific memory of that from the time, but it's such a plausible explanation.
Heh, I was hoping you might remember something along those lines and be able to confirm :) It does seem quite plausible though, particularly with the TEXT and GRAPHICS thing. The terms "text colour" and "graphics colour" crop up all over the place in the documentation, so I'm guessing that this was their first implementation.

Not sure about BEEP, but it was used by other BASICs around the time.

Richard Russell wrote:
Thu Jun 13, 2019 11:10 am
Indeed, it would have been wasteful to include the aliases like CIRCLE, ELLIPSE, ORIGIN, RECTANGLE etc. which appeared once space wasn't such a consideration.
Yeah, although in a fantasy parallel universe, it would've been great to have BBC BASIC as a 32k ROM, with a full screen text editor, keyword table and immediate mode type stuff in one bank, and all the runtime stuff in the other (along with more keywords, and some BASIC V facilities like WHILE, CASE, etc). I guess even 16k just for the BASIC interpreter was seen as a luxury back then (when other systems were having to fit BASIC + OS into that space).
Last edited by Rich Talbot-Watkins on Thu Jun 13, 2019 12:53 pm, edited 1 time in total.

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

Re: BBC BASIC mysteries and speculation

Post by Richard Russell » Thu Jun 13, 2019 1:33 pm

Rich Talbot-Watkins wrote:
Thu Jun 13, 2019 12:51 pm
they could have had two tables of execution addresses for tokens - one for statements and one for expression elements - and overlapped the index range.
So is there a single dispatch table (for both functions and statements) in 6502 BASIC? That would 'explain' it, but it never occurred to me to do that in my interpreters (they have two tables) and I can only see disadvantages in doing so. Sophie's judgement can usually be relied on (although I know of exceptions!) so perhaps there's something I'm missing.
I've wondered the same thing about the extra tokens, particularly since Sophie already used &7F for OTHERWISE.
Once you've committed to using &7F you have to use an unsigned comparison (for the range 127 to 255) rather than the signed comparison needed for -128 to +31. So that seems a particularly strange choice because it gains one token at the expense of 30!
Why are immediate mode only commands a 'thing'? Why is it any kind of big deal to write LIST or NEW or SAVE in a program?
Those commands may not be consistent with continuing program execution afterwards (maybe they use, and thus corrupt, some critical memory area) so they would probably need to exit to immediate mode - that's obviously true of NEW. Perhaps there was concern about providing a way to exit to immediate mode without going via the cleanup provided by END. But that's not a very convincing explanation.
Why did Acorn/BBC think that COUNT was a worthwhile keyword, being both non-standard and of very limited use in my opinion?
COUNT is used internally by the PRINT statement, it determines what TAB(n) does. I can see an argument for making it available in case you want to write a replacement for PRINT with a similar capability.
Likewise WIDTH. I don't think I ever used either of them!
I have made use of WIDTH when outputting to a printer or a file, when you haven't got the automatic text 'wrapping' at the edge of the text viewport.
The special line number encoding (token &8D) was used I guess so that RENUMBER didn't alter line lengths.
I don't think it is so much to do with line lengths, but to make it easier for RENUMBER to scan the program for the &8D token than to parse every line for a (ON) GOTO, (ON) GOSUB or RESTORE followed by a numeric constant (or list thereof).
could this encoding have been used as an optimisation for any integer literal within the allowed range in a program, to improve performance?
Some BASICs (QBASIC for example) do encode numeric constants to improve performance. I've often wondered why BBC BASIC doesn't, but if it did I think it would need to use a separate 'token' from that used to flag line numbers (again so RENUMBER can simply scan for the destinations it may need to change). As an aside, BB4W and BBCSDL have a mechanism for replacing variables, arrays and PROC/FN references by a binary encoding (to avoid the name lookup process) but not constants.

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

Re: VDU ?

Post by jgharston » Thu Jun 13, 2019 4:38 pm

Rich Talbot-Watkins wrote:
Thu Jun 13, 2019 10:33 am
Rich Talbot-Watkins wrote:
Thu Jun 13, 2019 10:12 am
We know OSCLI was added later, so it just got the last available token. But - pure speculation - is it possible that some of these keywords had different names originally? BEEP instead of SOUND? OSWRCH instead of VDU (he asks, clutching at straws)? Can't think of anything remotely reasonable for COLOUR.
GRAPHICS instead of GCOL
TEXT instead of COLOUR
Indeed, see: http://chrisacorns.computinghistory.org ... utline.txt

And while this specific list would have require sight of the future at the time, overlapping command tokens with function tokens is such an obvious "thing", and I'd always been puzzled/annoyed that binary LOAD/SAVE weren't allowed, requiring either OSCLI or calling OSFILE (ie, SAVE "name",start,end and LOAD "file",start).

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: 1510
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca
Contact:

Re: VDU ?

Post by Rich Talbot-Watkins » Thu Jun 13, 2019 5:46 pm

jgharston wrote:
Thu Jun 13, 2019 4:38 pm
Indeed, see: http://chrisacorns.computinghistory.org ... utline.txt
Ah, that's interesting, thank you! (I'm sure I've seen this document before, but I hadn't remembered/noticed stuff like BEEP being on the list.)

No explicit sign that TEXT and GRAPHICS were to be used as colour specifiers, although GRAPHICS is a keyword instead of MODE. But it has to be that doesn't it?

I prefer the use of ON ERROR END to turn off the error handling.
And while this specific list would have require sight of the future at the time, overlapping command tokens with function tokens is such an obvious "thing", and I'd always been puzzled/annoyed that binary LOAD/SAVE weren't allowed, requiring either OSCLI or calling OSFILE (ie, SAVE "name",start,end and LOAD "file",start).
Yes, that's a better use of the token space, and some nice extensions too! I'd've been inclined to overload ERROR as a function, to replace ERR and free up another token! (You could even have LINE instead of ERL too!)

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

Re: VDU ?

Post by Richard Russell » Thu Jun 13, 2019 6:48 pm

jgharston wrote:
Thu Jun 13, 2019 4:38 pm
overlapping command tokens with function tokens is such an obvious "thing"
So isn't it difficult to conclude that Sophie somehow missed it? Is there something we're all missing?

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

Re: VDU ?

Post by Rich Talbot-Watkins » Thu Jun 13, 2019 8:30 pm

Richard Russell wrote:
Thu Jun 13, 2019 6:48 pm
So isn't it difficult to conclude that Sophie somehow missed it? Is there something we're all missing?
Well, I guess we all have our off days :)

I think either:
  1. Sophie didn't think of having two dispatch tables, or
  2. She wanted to save two bytes (ASL A:TAX) in the expression execution code by jumping to a common routine in the statement execution code to dispatch both types of keywords (ASL A:TAX:JMP (dispatchtable,X))
Having the pseudo-variables duplicated in the keyword table takes up much more space though, and I don't see any reason why tokenisation or LIST would work any differently if each had just a single token, so I honestly think it was a mistake. Removing those duplicated entries would make room for ON and OFF as well!

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

Re: VDU ?

Post by Richard Russell » Thu Jun 13, 2019 9:31 pm

Rich Talbot-Watkins wrote:
Thu Jun 13, 2019 8:30 pm
I honestly think it was a mistake.
I find that a very depressing thought, especially as it continues to have an impact on my products today. :cry:

Please don't tell me you also think Sophie failed to notice that there were 30 unused single-byte tokens! :roll:

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

Re: BBC BASIC mysteries and speculation

Post by Richard Russell » Thu Jun 13, 2019 10:12 pm

Another 'obvious' optimisation, but one which I don't think has ever made it into any of Sophie's interpreters, is to take advantage of the 'variable chains' being linked-lists. The thing about a linked list is that it is very easy and fast to re-order the items in the list, in particular moving an item to the head of the list is just a case of changing a couple of links (well, three in fact).

BBC BASIC for Windows and BBC BASIC for SDL 2.0 leverage this as follows. Whenever a variable (or array, or structure, or FN/PROC) is looked up in its appropriate list, the matching entry (if any) is immediately moved to the head of the list. What this means is that when that same variable etc. is next looked up it will be found (potentially) much more quickly. This is of particular value when the variable etc. is accessed within a loop, because the first time around the loop it will be moved to the head of its list and in subsequent iterations it will be found quickly.

Overall the benefit of this optimisation is to make BBC BASIC more scalable to really large programs with thousands or tens of thousands of variables. Without it, the larger the number of variables and the later in the program that a variable is declared the slower it will be accessed, always. I believe BASIC V has some kind of cache mechanism to mitigate this, but I don't think it works the same way.

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

Re: BBC BASIC mysteries and speculation

Post by Richard Russell » Thu Jun 13, 2019 11:06 pm

Richard Russell wrote:
Thu Jun 13, 2019 10:12 pm
one which I don't think has ever made it into any of Sophie's interpreters
I am informed that I am hopelessly out of date and that this feature has indeed been added to ARM BASIC, and works even better in conjunction with 'Synergistic Cache Technology' (whatever that is).

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

Re: BBC BASIC mysteries and speculation

Post by BigEd » Fri Jun 14, 2019 4:27 am

This bump-variable-to-list-head is a very interesting (but simple idea) - how much 6502 code would it be, I wonder, and is there any way to shoehorn it into a Basic 4 revision? (If we still had hyperbolic tangent, we could drop that and save some space... but we don't. So that was a bit of a hyperbolic tangent...)

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

Re: BBC BASIC mysteries and speculation

Post by Richard Russell » Fri Jun 14, 2019 8:44 am

BigEd wrote:
Fri Jun 14, 2019 4:27 am
This bump-variable-to-list-head is a very interesting (but simple idea) - how much 6502 code would it be, I wonder
It's not very much code in the x86 version, but I wonder whether, given the limited memory available in the BBC Micro, there would on average be enough variables for the saving in lookup time to exceed the overhead in manipulating the links. It wouldn't be a good tradeoff if programs with a large number of variables benefitted but more typical programs ran slower.

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

Re: BBC BASIC mysteries and speculation

Post by BigEd » Fri Jun 14, 2019 8:57 am

Very true... always tempting to speculate about optimisation, but as we know, best to measure first.

Chuckie
Posts: 6
Joined: Thu Jun 20, 2019 12:21 pm
Contact:

Re: BBC BASIC mysteries and speculation

Post by Chuckie » Wed Jun 26, 2019 2:04 pm

Rich Talbot-Watkins »
Hey rich any chance open posting your full snoopy code as open souce for academic purpose?
or sending it to me direct
Thanks?

Post Reply