"Outline specification for the BBC MICROCOMPUTER system"

[BigEd]

As preserved and republished by Richard Russell, pasted here for convenience and discussion, from John Coll for the BBC, in late 1980:

Outline specification for the BBC MICROCOMPUTER system

This specification does not set out to be definitive
but it represents a desirable set of characteristics
which we should like to aim at for a BBC system.
Certain of these characteristics are in our view
essential and these can be clarified at a later date.

SOFTWARE
We fully realise that all microcomputers have different
dialects. The BBC is investigating the possibility of
supporting a version of BASIC which is not implemented
yet on any single machine but which would be as
compatible as possible with existing practice and
could be made available within the public domain to
any manufacturer willing to implement it. The specification
in draft form is available on request. Meanwhile, you will
see that the most desirable 'fallback' is specified below.

<page break>

BASIC: The general syntax of all commands should be identical to Microsoft BASIC
5.0 (repeat 5.0). If there is any conflict between what is said below
and the relevant Microsoft implementation then the latter should be used.
Graphics and I/O are outlined later.
The following commands and statements should be implemented in
floating point arithmetic to 6 figure accuracy over a range of at
least +-10^38

Code: Select all

          DIM                             OPEN
          OPTION BASE (0 or 1)            CLOSE
          DEF FN                          INPUT
          IF ... THEN ... ELSE            PRINT
          GOTO                            ?
          GOSUB                           LINPUT
          RETURN                          GET
          ON ... GOTO                     PUT
          ON ... GOSUB                    RND
          ON BREAK GOTO                   READ
          ON ERROR GOTO                   DATA
          CONT                            RESTORE
          RESUME                          CLOAD
          FOR ... TO ... STEP             CSAVE
          NEXT                            CVERIFY <<Annotation: REWIND>>
          RUN                             CMERGE
          RANDOMIZE                       LIST
          NEW                             LPRINT
          DELETE                          LLIST
          PEEK                            PLOT
          POKE                            MPLOT
          USR                             LINE
          STOP                            MLINE
          RENUMBER                        POINT
          TRACE                           MPOINT
          WHILE ... ENDWHILE              ORIGIN
          INP, OUT                        MORIGIN

SIN, COS, TAN, ATN, INT, ABS, SGN, LOG, EXP, POS, TAB, FRE, SQR

+ - * / ^ ( )
+ (string concatenation operator)
< <= <> => =
AND OR NOT

ASC, CHR$, LEN, LEFT$, MID$, INSTR, STR$, VAL

Variables names should be as long as the user wishes with the first
two characters being significant. Examples of legal variables would be
X, X1, KM, LENGTH, A3$, NAME$ and illegal names would include 3A (must
start with letter), TO$ (reserved keyword), PER POUND (no spaces).

2 John A. Coll

<<page break>>

Odds and ends: Powers of negative integer numbers [Y=(X)^Z] should evaluate
correctly - at least for Z<15.
Multidimensional string and numeric arrays.
Strings with totally dynamic memory useage.
It should be possible to say IF A$<B$ THEN ...
*Useful option MID$(A$,4,3)="cat".
Timed single character input.
I/O should be channel oriented using the word ASSIGN to assign a
logical channel to a physical device (e.g. ASSIGN OUTPUT TO PRINTER or
ASSIGN #4 TO DISK0, "MYPROG")

Graphics: the software should include commands to at least

(a) Plot an alpha-numeric character or string at any place on the screen
(PLOT X,Y,A$)
(b) Plot a low resolution graphics point to build Teletext graphic
characters in a range of colours or shades of grey (minimum: black and
white) (PLOT X,Y,C probably C=-1 to complement point, C=0 to plot
black point .... C=7 to plot white point)
(c) Find out what is at the point X,Y ( C=POINT(X,Y) or A$=POINT(X,Y))
(d) Draw a line from the last specified point to the new co-ordinates (LINE
X,Y,C)
(e) Move the effective origin (ORIGIN=X,Y)
(f) Do all the above in medium resolution graphics with similar commands
MPLOT X,Y,C
MLINE X,Y,C and
C=MPOINT (X,Y)
MORIGIN=X,Y
(f) Illegal values of X,Y or C should be ignored.

Video display: Either
(a) an integral single line display of 40 characters (each built from at
least 5 by 7 dots) and a modulated UHF output of the full screen (see
below) or
(b) an integral display of the full screen plus a modulated UHF output of
the full screen or
(c) a modulated UHF output of the full screen

A composite video output should be included.

The 'full screen' should consist of at least 24 lines of 40 characters
(*preferably an option of 80 characters from the outset) of upper and lower
case alpha-numerics and (colour) Teletext graphics. These should be capable
of being freely mixed with (colour) medium resolution graphics of at least
200 horizontal points. The medium resolution graphics should be eraseable
separately from the other displays.

The computer should either produce UHF colour signals at the time of
purchase or be easily expaned to produce UHF colour signals. It must be
designed with colour Teletext and colour graphics in mind.

3 John A. Coll

<<page break>>

The screen handler should respond to specific control characters to
(a) Home top left and clear to end of page (whole screen)
(b) GOTOXY - cursor addressing
(c) clear to end of line
(d) clear to end of page
(e) Non destructively move the cursor up/ down/ left/ right
(f) Move to start of line (carriage return)
(g) Delete previous character
(h) Scroll when on bottom line of display
(i) Clear medium resolution graphics display

Keyboard: capable of generating all 128 ASCII codes. Positive action keys (not
touch sensitive). ISO standard layout plus
(a) Up/down/left/right cursor control
(b)*A row of keys, above the numbers, which generate software definable
codes - this could be done with a software look-up table to map the
original codes to new values.

Loudspeaker: inside box and accessible from BASIC

Printer connection: electrically to RS449 (or RS232C) with the connector to ISO
2110. Only Send Data, Receive Data, Request to Send and Clear to Send need
be implemented.

Paddles: some connector to which two simple potentiometers may be connected the
setting of which can be determined by a simple BASIC statement or a few
lines of assembler program.

Teletext: adapter should be available for off-air downloading of software

Expansion port: fully electrically buffered expansion connector (e.g. no
unprotected MOS!).

Memory: sufficient within the box to support floating point BASIC and medium
resolution graphics. This probably means 16K ROM plus 32K RAM - certainly
at least 16K RAM should be supplied at the outset.

Memory map: above all this should be designed for expansion and standardisation.
Probably should be RAM from 0000 up with ROM from FFFF down (including
8080/Z80 systems). At the very top there should be a simple monitor with
any ROM high level languages immediately below. The screen should not be
allocated to fixed RAM locations below C000 and could be dynamically
allocated from available RAM. Scratchpad RAM for the stack and monitor, and
RAM for the DOS should, preferably, be well clear of low memory RAM (6502
problems here) used for user programs.

System monitor: should contain routines to
(a) output character to screen
(b) test keyboard for character waiting
(c) get character from keyboard

4 John A. Coll

<<page break>>

(d) send character to printer
(e) load and save binary files from cassette

all the above should vector via RAM locations to default ROM device drivers

(f) examine and change memory locations.

Device handlers: Cassette, paddles and printer should also be driven via RAM
vectored device drivers.

Cassette interface: producing CUTS frequencies, but doing all the byte recovery
in software. The software should be insensitive to reversed phase play back
from a cassette recorder, work at 1200 bps, accept and produce the BBC
format tape (as well as your own format if you wish). Named files,
catalogue, idiot proof.

The manufacturer should be able to demonstrate a production model disk operating
system which should, at least:

Enable a user to plug the thing in and, without pressing a single button,
end up running a BASIC program - or any other program that the machine
had been configured to run.
Give a 'DIRectory' or 'CATalogue' of files on disk showing filenames, file
length, creation date, whether or not the file is delete-protected
Save a specified area of memory as a named binary file
Load and automatically execute binary files
Save onto disk ASCII text or data from BASIC etc.
Load text from disk
LIST a text file to screen or printer
EXECute an text file as if it were a 'command line' - including refernces
to any disk drive or any peripheral
Delete and rename specified files or groups of files
Permit random access to data in multiple files
Have a well organised JUMP list at a known location to all routines likely
to be needed by assembly language programmers.
The Disk Operating System should appear as a byte oriented input/output
stream similar to the keyboard/VDU and data should not need to be
blocked before being passed to the DOS
At least 10 disk channels should be capable of 'simultaneous' access (i.e.
OPEN concurrently)
Faulty disk sectors should be automatically avoided
Accidental swapping of disks should not either (a) crash the disk file
structure or (b) abort everthing
The vast majority of the DOS high level commands (such as CAT, DIR, COPY,
LIST, DELETE, RENAME, PROTECT, SAVE) should not form part of the
permanently memory resident DOS. They should be Utility or Transient
programs called into memory when required. All those listed above
should not reside in the same memory space as BASIC or as the EDITOR
or WORD-PROCESSOR. They should all be able to be called from BASIC
etc. The manufacturer should be able to SHOW an extensive range of
such transients and should not say 'Oh that would be very easy to
write'!

5 John A. Coll

[BigEd]

Do let me know (perhaps by PM) of any transcription errors. Many thanks to Richard for preserving this material.

I find it notable that this 'spec' was not treated as such, although certainly the Beeb comes close, and is of course a splendid system.

There is already some discussion at the original thread - perhaps the mods could wrestle it all into one place, or perhaps I'm wrong to start a new one.

Moderator note: The thread referred to is "Some interesting Steve Furber observations". Mark
Edited by 1024MAK on Sat 08th Oct 2016 10:52

[Deleted User 9295]

pasted here for convenience and discussion, from John Coll of the BBC

I should point out that John Coll was never "of the BBC", but an independent advisor; as the linked Wikipedia article states, he taught at Oundle School and was involved with MUSE (Microcomputer Users in Secondary Education). John died in 2014.

I find it notable that this 'spec' was not treated as such, although certainly the Beeb comes close

"This specification does not set out to be definitive but it represents a desirable set of characteristics".

Richard.

[BigEd]

Good points both - perhaps I can edit to 'with the BBC'? Either that, or 'for'

[Deleted User 9295]

Good points both - perhaps I can edit to 'with the BBC'? Either that, or 'for'

"for the BBC" would be more precise.

The BBC would have been rightly criticised (even more than it was!) if it had attempted to organise this massive project entirely with in-house resources, especially given the lack of appropriate expertise. In practice it probably veered too much in the opposite direction, because engineering departments within the BBC (including my own) were involved rather later in the process than might have been desirable. The NewBrain debacle forced a major rethink, and it was at that point that BBC Engineering got into the loop.

Richard.

[BigEd]

OK, done. It would be interesting to try to glue this document together with other accounts, especially any accounts which deal with Sinclair's claim that the process was not entirely free and open, and in some way favoured Acorn. Not that we can ever find any definitive truth.

[Deleted User 9295]

OK, done. It would be interesting to try to glue this document together with other accounts, especially any accounts which deal with Sinclair's claim that the process was not entirely free and open, and in some way favoured Acorn. Not that we can ever find any definitive truth.

I have a large amount of correspondence between Sinclair and the BBC; the issue exercised both parties to a large extent in the 1981-82 timeframe! But it's too sensitive to release, via this portal anyway.

Here's another document with considerable historical significance: the agenda for the meeting at which Acorn were eventually selected to supply the BBC Micro. I should explain that the presence of Commodore on the list, in addition to the other short-listed candidates (Acorn, Newbury and Tangerine) was the result of a late bid from them that we felt duty-bound to consider, even though as a non-British company they would not have been invited to tender anyway.

There are some interesting 'notes in the margin' which I obviously wrote myself at the meeting, including the comments "Special BBC version of Proton" and "Prototype of teletext in fortnight?".

Richard.

[algenon_iii]

^ Commodore Never knew that, what machine did they submit an improved VIC20 or PET or something that would become the C64?

[Deleted User 9295]

Commodore: Never knew that, what machine did they submit an improved VIC20 or PET or something that would become the C64?

No idea, sorry. I was present at the meeting, but I have no recollection of it after nearly 36 years! Putting the Commodore bid on the agenda was a courtesy, they never had any chance.

Richard.

[Deleted User 9295]

Having published the BBC's specification, here is Acorn's response. Many people (including Chris Curry in his interview here) seem to believe Acorn initially proposed the Proton, but as can be seen that's not the case. Evidently by the time the decision was made to choose Acorn the Proton had indeed been offered; possibly because it supported 80 characters-per-line modes and a Second Processor capable - in principle - of running CP/M.

It was arguably a misjudgement on the part of Acorn to try to defend the quirky Atom Super BASIC, such as the use of a semicolon as the statement separator and oddities like PRINT not generating a newline by default (however 'logical' their justifications might have been). The BBC would never have accepted such a non-standard syntax, given that it wanted to feature in its TV programmes simple 'generic' BASIC code which would run on the majority of home computers of the day.

Richard.

[hoglet]

Hi Richard,

It was arguably a misjudgement on the part of Acorn to try to defend the quirky Atom Super-BASIC

Was Atom Super-BASIC not actually an early version of what became BBC Basic?

i.e. a complete re-write?

Or is it just another name for the Basic that shipped on ROM with every Acorn Atom?

Dave

[Deleted User 9295]

Was Atom Super-BASIC not actually an early version of what became BBC Basic?
Or is it just another name for the Basic that shipped on ROM with every Acorn Atom?

I know no more than what can be deduced from that Acorn document, i.e. that Super BASIC was an "enlarged version of ATOM BASIC very similar in power to Microsoft, and with some extensions". So it definitely wasn't what was "shipped with every Atom", but you'd have to ask Sophie to what extent BBC BASIC was developed from it, or from scratch.

It's not even clear to me whether Super BASIC was ever an available product or just something that Sophie was working on at the time the BBC proposal was prepared. So it could be that it morphed into BBC BASIC before even being completed.

Richard.

[Commie_User]

I'm intrigued, too, at pondering the machine Commodore could have offered, had foreign offers been included. I daresay no early C64, as I know from history stories that the CBM's SID and huge RAM were just not on the table a year earlier. Nor, too, I think, the VIC graphics chip.

And had there been a BBC CBM, the company - shooting their bolt early with a likely super VIC 20 - could have seen nothing to really push the company forward, globally, until the Amiga.. if investment capital would still have existed.

[hoglet]

It's not even clear to me whether Super BASIC was ever an available product or just something that Sophie was working on at the time the BBC proposal was prepared. So it could be that it morphed into BBC BASIC before even being completed.

My understanding was that prior to the BBC, Acorn had developed a new version of Basic, and this was available on the Acorn System platform.

If you look at my attempt at an Acorn System 3/5 FPGA:
viewtopic.php?f=3&t=11606&p=146129&hili ... ga#p145578
you can see this running something called "Acorn New Basic".

I suspect this is yet another name for Acorn Super BASIC, which went on to become BBC Basic.

Dave

[Deleted User 9295]

I suspect this is yet another name for Acorn Super BASIC, which went on to become BBC Basic.

It's all rather moot really. To what extent BBC BASIC was 'adapted' from an earlier version and how much of it was written 'from scratch' isn't terribly relevant in the grand scheme of things. It's the claim, sometimes heard, that BBC BASIC was no more than an Acorn dialect of BASIC to which the BBC attached its name that I (predictably) object to!

Richard.

[1024MAK]

I've not looked into this as far as the code is concerned, but I would have thought that the BBC BASIC that shipped with the BBC Micro would have been written more or less from scratch but incorporating some code from Acorn's existing BASIC languages.

I say this, because of the differences between Atom BASIC and BBC BASIC. And because Sinclair (well, the people / company that Sinclair used) did a similar thing with the BASIC for the ZX80 > the ZX81 > the ZX Spectrum. Most of the code is rewritten, but with some bits descended from the earlier machines. There is even a bit of a redundant ZX81 routine in the Spectrum ROM that is never called by any of the other code in the ROM.

The Acorn super BASIC that is talked about in the Acorn document sounds like an extended version of Atom BASIC. But without more information, we can only guess...

Mark

[paulb]

I'm intrigued, too, at pondering the machine Commodore could have offered, had foreign offers been included. I daresay no early C64, as I know from history stories that the CBM's SID and huge RAM were just not on the table a year earlier. Nor, too, I think, the VIC graphics chip.

I guess that there are historical tales about the development of the C64 that would give an indication of the timing and tempo of that development. From what I've just read about the VIC-20, it seems that Commodore were adapting to Apple's strategy (this is mentioned in that Victor 9000 video featuring Chuck Peddle) and needed to deliver a computer that plugged into a television and separate cassette player, but this happened in a hurried fashion during 1980, it would seem. The C64 seemed to benefit from work done at MOS Technologies during 1981 which was then pushed through during 1982 at Commodore.

And had there been a BBC CBM, the company - shooting their bolt early with a likely super VIC 20 - could have seen nothing to really push the company forward, globally, until the Amiga.. if investment capital would still have existed.

The PET was already used in certain parts of UK education, and the general all-in-one concept was arguably well-suited to the task. But with regard to what needed adding to it, I guess that Commodore just wasn't ready at the time or maybe knew what was in the pipeline but could only promise things, not necessarily deliver them. For once, the "can do" attitude seemed to come from the UK side of the competition. Maybe this alerted Tramiel and others at Commodore that something needed doing fairly urgently to rectify the situation and to not miss out on similar opportunities in the future.

Also interesting is Research Machines' absence from the meeting participants. Did they (or Sinclair) ever formally participate in the process?

[BigEd]

New Basic has pretty much the same keywords as what later shipped as BBC Basic. I notice, comparing it to the Super Basic described in the memo, it lacks WHILE..DO - I suspect REPEAT..UNTIL is easier to implement, which makes me think this Super Basic a paper spec not yet fully implemented. Also the hyperbolic tangent is gone - I bet we've all missed that!

Keywords in New Basic from 1981:
AND ABS ACS ADVAL ASC ASN ATN AUTO BGET BPUT COLOUR CALL
CHAIN CHR CLEAR CLOSE CLG CLS COS COUNT
DATA DEG DEF DELETE DIV DIM DRAW ENDPROC
END ENVELOPE ELSE EVAL ERL ERROR EOF EOR ERR EXP EXT FOR FALSE FN GOTO GET GET
GOSUB GCOL HIMEM CINPUT IF INKEY INKEY INT INSTR LIST LINE LOAD LOMEM CLOCAL LEFT
LEN LET LOG LN MID MODE MOD MOVE NEXT NEW NOT OLD ON OFF OR OPENIN OPENOUT
PRINT PAGE CPTR CPI PLOT POINT PROC POS RETURN REPEAT REPORT READ REM
RUN RAD RESTORE RIGHT RND RENUMBER STEP SAVE SGN SIN SQR SPC STR STRING SOUND
STOP TAN THEN TO TAB TRACE TIME CTRUE UNTIL USR VDU VAL VPOS WIDTH PAGE PTR TIME
LOMEM HIMEM
[a few stray characters in there...]

From the memo:

Code: Select all

  Keyword              Type                                          Synta
        =       <statement>                                         =<expr
      ABS        <function>                                     ANB<factor
      AND     <conjunction>                           <rel exp>AND<rel exp
      ASC        <function>                                 ASC<string fac
     AUTO         <command>                     AUTO<optional line numbers
     BGET        <function>                                    BGET<factor
     BPUT       <statement>                             BPUT<factor>,<expr
     CHR$ <string function>                                    CHR$<factor
    CHAIN       <statement>                               CHAIN<string fac
    COUNT        <function>                                           COUN
     CORP       <statement>                                            COR
     DATA   <start of line>                                DATA<data items
      DEF       <statement>                      DEF {PROC|FN}<word> <line
   DELETE         <command>                     DELETE<line no.>,<line no.
      DIM       <statement>           DIM{<array name>({<expr>,}^<expr>),}
       DO       <statement>                                   DO<statement
      END       <statement>                                             EN
     ELSE       <statement>                                          ; ElS
      EXT        <function>                                     EXT<factor
     EVAL        <function>                                EVAL<string fac
      FOR       <statement>                   FOR<variable>=<expr>TO<expr>
                                     FOR<variable>=<expr>TO<expr>STEP<expr
      FIN        <function>                                 FIN<string fac
       FN        <function>                            FN<word>({<expr>,}^)
     FOUT        <function>                                FOUT<string fac>
     GET$ <string function>                                    GET$<factor>
      GET        <function>                                     GET<factor>
      GET       <statement>                            GET<assignable item>
     GOTO       <statement>                               GOTO<goto entity>
    GOSUB       <statement>                              GOSUB<goto entity>
    HIMEM       <statement>                                     HIMEM<expr>
       IF       <statement>     IF<testable>{<line>|THEN{<line no.>|<line>}
    INPUT       <statement>        INPUT{<print string><assignable item),}^
     LOAD         <command>                                LOAD<string fac>
    LOCAL       <statement>                      LOCAL{<assignable item>,}^
    LOMEM       <statement>                                     LOMEM<expr>
     LIST         <command>                     LIST<optional line numbers>
      LEN        <function>                                 LEN<string fac>
   LEFT$( <string function>                     LEFT$(<string expr),<expr>) 
      LET       <statement>                                 LET<assignment> 
     LINK       <statement>                                    LINK<factor> 
    MID$( <string function>                     MID$(<string expr),<expr>)| 
                                          MID$(<string expr>,<expr>,<expr>) 
      NEW         <command>                                             NEW
     NEXT       <statement>                     NEXT{{<variable>|<null>},}^ 
      NOT        <function>                                     NOT<factor>
  NOTRACE       <statement>                                         NOTRACE 
   NUMBER         <command>                  NUMBER <optional line numbers>
      OLD         <command>                                             OLD
ONERRGOTG       <statement>                          ONERRGOTO<goto entity>
       ON       <statement> ON <expr> {GOTO|GOSUB} {<goto entity>,}^ {ELSE}
       OR     <conjunction>                            <rel exp)OR<rel exp>
     PAGE        <function>                                            PAGE
               <assignment>                                     PAGE=<expr>
      PTR        <function>                                     PTR<factor>
               <assignment>                              PTR<factor>=<expr> 
    PRINT       <statement>            PRINT{{&|<print string>}^{<item>,}}^
     PROC       <statement>                                      PROC<word> 
     PUT$       <statement>                      PUT$<factor>,<string expr>
      PUT       <statement>                              PUT<factor>,<expr> 
     READ       <statement>                       READ{<assignable item>,}^
      REM       <statement>                                       REM<line> 
   RETURN       <statement>                                          RETURN
      RUN       <statement>                                             RUN
  RESTORE       <statement>                    RESTORE|RESTORE<goto entity>
   RIGHT$ <string function>                    RIGHT$(<string expr>,<expr>)
      RND        <function>                                             RND 
     SAVE         <command>                                SAVE<string fac>
      SPC  <print function>                                     SPC<factor> 
     STEP                                                           see FOR
     SHUT       <statement>                                    SHUT<factor> 
     STR$ <string function>                                    STRS<factor>
     THEN                                                            see IF 
     TIME        <function>                                            TIME 
                <statement>                                     TIME=<expr> 
      TOP        <function>                                             TOP 
       TO                                                           see FOR
      TAB  <print function>                                     TAB<factor> 
    TRACE       <statement>                               TRACE|TRACE<expr>
   UNLESS       <statement> UNLESS<testable>{<line>|THEN{<line no.>|<line>}
    UNTIL       <statement>                                 UNTIL<testable>
      USR        <function>                                     USR<factor>
      VAL        <function>                                 VAL<string fac>
    WHILE       <statement>                                 WHILE<testable>
    WIDTH       <statement>                                    WIDTH <expr>

[jgharston]

The ording of the keyword tokens:
D0: PAGE
D1: TIME
D2: LOMEM
D3: HIMEM
D4: SOUND <----
D5: BPUT
D6: CALL
D7: CHAIN
supports speculation that an earlier version had BEEP for the sound command. I'm sure I've seen a document that lists the sound command as BEEP pitch,duration. Also:
FA: STOP
FB: COLOUR
FC: TRACE
FD: UNTIL
FE: WIDTH
FF: unused in BASIC I
supports speculation that &FF would have been WHILE and was dropped as there wasn't enough space to squeeze in the code.

[Deleted User 9295]

supports speculation that &FF would have been WHILE

I don't think it does. WHILE comes before WIDTH alphabetically, so if you are arguing that tokens &FE and &FF were originally allocated to these keywords they would surely have been the other way around?

Interestingly, when Sophie later proposed to implement WHILE...ENDWHILE in BASIC V it was non-nestable: "If the condition is initially FALSE, then the textually next ENDWHILE will be searched for" (my emphasis). Not only that, but the proposed CASE...ENDCASE and block-structured IF...ENDIF were also non-nestable. One of the major contributions I can claim to have made to BBC BASIC, in my role at the BBC, was to insist that if these constructs were to be added it was essential that they be nestable.

Mind you I suspect that Sophie must have, at some level, realised what a serious limitation her proposal had, and probably only needed the nudge from the BBC to work out quite quickly how nesting could be made to work.

Richard.

[Deleted User 9295]

WHILE comes before WIDTH alphabetically, so if you are arguing that tokens &FE and &FF were originally allocated to these keywords they would surely have been the other way around?

Isn't it more likely that &FF was 'unused' simply because it was 'unneeded'? It's not as though there was a shortage of possible token values; codes &01 to &0C and &0E to &1F are in principle available as keyword tokens and any CPU with a signed 8-bit comparison capability, which I assume the 6502 must have, can test the range of 'token' values from &80 (-128) to &1F (+31) in one instruction.

These are the 'positive' tokens I use (I've never understood why Sophie introduced 2-byte tokens with all these single-byte values available):
&01: CIRCLE
&02: ELLIPSE
&03: FILL
&04: MOUSE
&05: ORIGIN
&06: QUIT
&07: RECTANGLE
&08: SWAP
&09: SYS
&0A: TINT
&0B: WAIT
&0C: INSTALL
&0E: PRIVATE
&0F: BY
&10: EXIT

In BB4W 'tokens' &18 to &1F are used by my 'fastvars' mechanism, in which variables are replaced by one of these values followed by a 16-bit index:

&18: fast FN/PROC
&19: fast byte
&1A: fast dword
&1B: fast double
&1C: fast variant
&1D: fast structure
&1E: fast qword
&1F: fast string

Richard.

[jgharston]

I'm not sure what benefit was gained from having two sets of tokens for reading pseudo-vars and writing pseudo-vars. It adds to the tokeniser having to change the bytes it emits, and could have been implemented by having one set of tokens at the end of the 'function' tokens overlapping with the start of the 'command' tokens. Something like

...CF functions
D0: PAGE
D1: TIME
D2: LOMEM
D3: HIMEM
D4... commands

The command dispatcher would do CMP #&D0:BCS ok the function dispatcher would do CMP #&D4:BCC ok. I think in ARM BASIC if the interpreter encounters the "wrong" token in the wrong context it just executes it correctly for the context. That is, the command dispatcher has entries for the pseduo-var function tokens and the function dispatcher has entries for the pseudo-var command tokens. Hindsight allows this sort of speculation.

[BigEd]

If we are delving into the innards of Basic tokenisation, can either of you (or anyone) enlighten me on why just a few functions - but not all - have their opening parenthesis included in the token?

[Deleted User 9295]

I'm not sure what benefit was gained from having two sets of tokens for reading pseudo-vars and writing pseudo-vars.

The only benefit I can think of is that it makes it possible to have a single dispatcher, rather than one for statements/commands and another for functions. But the structure of a conventional interpreter leads naturally to having two different dispatchers, and all my versions of BBC BASIC do, so I share your puzzlement.

Whatever the original reason, presumably it ceased to have any meaning once other keywords acquired both 'left' and 'right' functionality in BASIC 5 (including DIM, END, EXT#, LEFT$, MID$, MODE, REPORT, RIGHT$ and WIDTH) without at the same time acquiring two different tokens.

Richard.

[Deleted User 9295]

If we are delving into the innards of Basic tokenisation, can either of you (or anyone) enlighten me on why just a few functions - but not all - have their opening parenthesis included in the token?

As far as I'm aware it's simply a strategy to save program memory and a little bit of execution time. If a function always has multiple parameters (making the parentheses compulsory) then the opening parenthesis is included, whereas if a function only takes a single parameter (or an optional parameter) then the parenthesis isn't included and can usually be omitted.

Richard.

[BigEd]

Ah, so there's the consistent reason I was missing - thanks!

[Commie_User]

Maybe this alerted Tramiel and others at Commodore that something needed doing fairly urgently to rectify the situation and to not miss out on similar opportunities in the future.

Also interesting is Research Machines' absence from the meeting participants. Did they (or Sinclair) ever formally participate in the process?

It doesn't seem anybody knows what to Google to grab that nugget. Either I don't or nobody's written it. Someone with that special name in their black book may need to do some asking around. Closest we get are things like this:

Several computers were considered, most notably the Sinclair-affiliated Grundy NewBrain, as well as Acorn’s own Proton. “The project only gained real momentum with the impending visit of the BBC people to see a Proton prototype – which didn’t exist at the time,” recalls Wilson. “We had a week to build it.”

Despite the tight time frame, the prototype was up and running within a week, and impressed the BBC representatives sufficiently to ensure Acorn obtained the high-profile link up. “I guess we got the contract partly because what we were building anyway was close to what they wanted, and partly because they saw that our engineering was good enough to make it happen,” says Wilson. What had been known as the Proton, hit the shelves in November 1981 as the BBC Microcomputer System, just like Systems 1-5 and the Atom, another computer based around the 8-bit 6502 processor found in Wilson’s cow feeder.

http://www.retrogamer.net/profiles/hardware/bbc-micro/


I get the opinion that no real history exists on the Sinclair side because the company made little approach. If any, as implied in the Micro Men film.



Though I can ask how interesting the BBC could have been had a real gaming machine been developed into one.

[BigEd]

Also interesting is Research Machines' absence from the meeting participants. Did they (or Sinclair) ever formally participate in the process?

According to this article in The Register, RM declined to be involved :

Fischer realised that a machine based on the BBC’s hardware and software specifications and intended to be sold at the price the Corporation wanted could not be produced reliably within the launch timescale the broadcaster was set upon. RM chose not to pursue the BBC contract as it stood. It told the BBC it could produce the machine the Corporation wanted, but it would take twice as long to bring to market and cost twice as much.

Fischer was unsurprised, then, when Acorn’s BBC Micro was launched late, took far longer than planned to reach everyone who’d ordered one, and ended up costing more than forecast.

[paulb]

Also interesting is Research Machines' absence from the meeting participants. Did they (or Sinclair) ever formally participate in the process?

According to this article in The Register, RM declined to be involved :

Fischer realised that a machine based on the BBC’s hardware and software specifications and intended to be sold at the price the Corporation wanted could not be produced reliably within the launch timescale the broadcaster was set upon. RM chose not to pursue the BBC contract as it stood. It told the BBC it could produce the machine the Corporation wanted, but it would take twice as long to bring to market and cost twice as much.

Fischer was unsurprised, then, when Acorn’s BBC Micro was launched late, took far longer than planned to reach everyone who’d ordered one, and ended up costing more than forecast.

That last bit sounds a lot like sour grapes (maybe from the author of the piece rather than any of the participants): the Beeb wasn't twice the announced price in the end, nor is taking "far longer than planned" to fulfil all orders the same as taking twice as long to bring to market (and then, presumably, taking "far longer than planned" to fulfil all orders as well).

An interesting tangent from that article is the High Level Hardware Orion, however.

[BigEd]

An interesting tangent from that article is the High Level Hardware Orion, however.

Indeed! As it happens, I had a couple of tabs open already on the Orion.