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.
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.
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
Code: Select all
OPTION BASE (0 or 1) CLOSE
DEF FN INPUT
IF ... THEN ... ELSE PRINT
ON ... GOTO PUT
ON ... GOSUB RND
ON BREAK GOTO READ
ON ERROR GOTO DATA
FOR ... TO ... STEP CSAVE
NEXT CVERIFY <<Annotation: REWIND>>
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
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
(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
(e) Move the effective origin (ORIGIN=X,Y)
(f) Do all the above in medium resolution graphics with similar commands
MLINE X,Y,C and
(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
(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
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
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
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
(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.
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
5 John A. Coll