POSITRON 9000
A NEW BRITISH MULTI-USER COMPUTER

BENCHTEST
MULTI-USER SYSTEM

Roger Oliver and Chris Sadler
test a new British colour micro.

Photography by Chris Stevens

The 6809 processor is popular among assembler programmers because of its simplicity and power. It hasn't appeared in many microcomputer systems, though, as its announcement postdated major software development on other processors (the Z80 and 6502). But it has a loyal following and some high-level software.

Positron is a Manchester-based company which has designed a flexible system (the 9000) around its favourite chip. For software it chose OS-9, a multitasking operating system from American software house Microware.

Hardware

Picture an Apple-style casing (ie, white plastic with an inclined front section containing the keyboard and a flat top to support the monitor), double the length and breadth to 61 × 58 × 10 cm, and you've got an idea of the main module of the Positron 9000 review system. The keyboard is grouped into four 'pads' – a 61-key qwerty section, an 8-key "graphics encoding pad, a 12-key 'video attributes' pad and a standard numeric keypad. The qwerty keypad is designed for Viewdata rather than ASCII input, which means there are fractions and left and right arrows rather than brackets, braces and the backslash. The non-printing keys (distinguishable by being a lighter shade of grey) include ESC (end-of-file in OS-9), SHIFT LOCK and CAPS LOCK, REPEAT, DEL and a set of cursor control keys. At present only the back arrow is decoded (it functions as a BACKSPACE). The other arrows and a red BREAK key are not yet decoded. The keyboard is robust, requiring very firm keystrokes to operate, but the main criticism is that DEL (which deletes the current line) is directly beneath RETURN — which can be a bit disconcerting for the habitual mistypist.

The video attributes keypad has eight colour keys which are used to select the current colour (in alpha or graphics mode) and four which select display attributes - flashing/steady, normal double height characters, background and graphics status. When in graphics mode, blocks in the Viewdata 2×3 matrix at the current character position can be toggled on or off with the corresponding keys in the 2×3 key matrix on the graphics encoding pad.

At the back of the box there are sockets for a cassette (1200 and 300 baud - remember Kansas City?), four RS232 devices (drivers exist for terminals and printers), an IEEE-488 port, and RGB, composite video and UHF output for the display. The review machine was equipped with a Decca colour monitor providing the more-or-less familiar 40 character by 24 line display. The top of the casing is retained by three screws on either side and, once removed, reveals the keyboard circuitry (supported at an ergonomic angle to the horizontal) beyond which lies the main board and a power supply. The logic supporting the Viewdata functions and 240×240 pixel 'high resolution' graphics is on the keyboard board. Positron is apparently going to produce a 25×80 screen (and presumably an ASCII board). instead of the Prestel format, although it is also possible to buy the 9000 packaged without keyboard and monitor at all (the case, of course, is differently shaped). A wide ribbon cable connects the keyboard to the processor board.

The main board gives the appearance of a clean design with well-labelled areas, and is well made, with all the pricier chips socketed. The standard configuration provides 64k RAM and 36k ROM, although the review system seemed to have 44k's worth including software (8k). These were all in 4k ROMs but the sockets can optionally take 8k ROMs, and with all the sockets filled there is a potential 128k of ROM. The RAM is expandable (on board) up to 256k. The 6809 (Positron provides a 1 MHz version but will supply a 2 MHz chip with the faster memory required) will address only 64k, but this can be overcome by means of a bank of Motorola memory management units. The review machine was fitted with one of these and there were sockets for another seven. Each can cope with up to four concurrent processes, so it's not difficult to work out what the system is theoretically capable of. An extension board (which stacks above the main board, plugging into a socket similar to that used to connect the keyboard) allows both RAM and ROM to be doubled in size and provides another four RS232 sockets. However, OS-9 level 1 can only address 64k so any extension requires a software upgrade as well.

The four RS232 ports can be configured in two ways. Firstly, by repositioning a pair of chips mounted close to each port, the port can be set up as DTE or DCE. Second, a bank of DIP switches allows each port to be configured for speed (75-4800 baud) and handshaking. On the review machine we had problems getting the ports to work outside the factory settings. DIP switches also exist for configuring the IEEE-488 port and (on the keyboard board) for selecting the video display mode.

The disk drives come in metal cabinets the same width as the main processor box so that they can be stacked on top of it with the monitor perched (actually quite stably) on top of the lot. The review machine had a 5 Mbyte Winchester in one cabinet (the Positron 9250) and a pair of 5¼ in 380 kbyte floppies in another (the 9151). Drives are daisy- chained together on the IEEE-488 bus, each cabinet containing a controller board with its own processor and PROM to manage the actual drives. A single system is set up to take up to two 9151s (D0-D3) and up to four 9250s (D4-D7) where D0-D7 are the device numbers used by OS-9. Positron is also developing the 9300, an adapted disk controller whose PROM performs bus arbitration (instead of disk control) among IEEE devices, enabling a network of up to seven Positrons to share the resources of up to eight disk drives and 16 other devices.

A fully expanded 9000 then would consist of ½ Mbyte of RAM, 256k of ROM, 8 terminal ports, four floppies and 40 Mbyte of Winchester disks. Nobody really expects a single 6809 to be able to cope adequately with all that, but the flexibility of a system should be measured in the extent and number of directions in which expansion is possible. The same remarks probably apply to the fully expanded network.

The board is neatly designed

Double disks can sit on top of console

Software

OS9 is Unix-like. It is a multi-tasking/ multi-user operating system based on a tree-like file structure. System utilities are invoked by issuing a command to the 'shell', a monitor program that, possibly, already has the capability to carry out the requested task, or which, more usually, calls a separate program to accomplish the task. OS9 deviates from the true Unix philosophy in that programs can be locked into memory so that retrieval of often-needed code from floppy disk drives does not degrade system performance.

OS9 fully supports the Unix concept of any process being able to spawn any number of daughter processes (within the limits of availability of main memory); these are then processed concurrently with all the other processes in the system. New processes can be generated within a program, or by communication with the shell.

OS9 supports re-entrant code. When the same program is called by more than one user, only one copy of the code is kept in main memory, and separate data areas are maintained for each use of the program. Each module (program) in main memory has a user count; when it is called the user count is incremented by one, and when the program is no longer required, the user count is decremented by one. When the user count reaches zero, the module is discarded.

In tree-structured file systems it is always necessary to specify the complete route through the tree structure to the individual files; this may be done implicitly or explicitly. If many of the files referenced are from a particular directory file, then it is usual to set that directory as the current directory; thereafter only the file name need be supplied, the rest of the path having been supplied implicitly. OS9 is rather unusual (and un-Unixlike) in that the user is regarded as being 'in' two directories simultaneously; a directory for data files and a directory for programs. These are called the data directory and the execution directory respectively. The supposed advantages of this are not very clear. The picture becomes even more complex when you realise that Basic program files that have been SAVED are regarded as being data files, whereas Basic programs that have been compiled are stored in the execution directory.

Here's a quick rundown of OS9 commands: ATTR operates on the attributes of files; these are directory file/data-program file, file shareable between processes or unshareable (see below), owner readable, owner writeable, owner executable, public readable, public writeable, and public executable. An owner is one with the same user number as the originator of the file.

DCHECK checks the integrity of the file structure on the specified disk. Sectors on the disk that are allocated to a user but recorded as free in the disk allocation bit-map are detected, and vice versa. Also, the pointers linking the various directories and files are checked.

The EX command allows a utility to be called without creating an additional version of the shell; this conserves memory space.

LOGIN together with TSMON is used to implement a multi-user System. For example, the command TSMON/T1 sets up a version of the time-sharing system to monitor terminal 1 for activity. Subsequently, any user of terminal 1 has to interact with the LOGIN program before being admitted to the system. The LOGIN command asks the user for his user name and password and the supplied values are compared with the contents of the password file which details all the permitted users of the system; access is granted only when acceptable values are supplied for username and password. The password file also specifies a user number (0 to 65535, with user 0 as superuser, with special privileges), the CPU time priority, and the paths for the initial data and execution directories and the initial program for execution (usually the shell)'

PROCS displays a list of all the processes running on the system. The data given on the processes includes the user number, the process number, the priority level, the state (active, waiting for another process to terminate, or sleeping, suspended by self-request for a specified period or until receipt of a signal from another process). OS9 has a unified input/output system in which data transfers to all I/O devices are performed in almost exactly the same manner, regardless of the specific hardware devices involved. Thus, 'DIR > filedata' lists the contents of the data directory to the file filedata, rather than to the screen. Similarly, the command 'DIR >/P' would direct the output to the printer (parallel interface).

OS9 supports batch or background working. A command file containing the commands that make up the background job can be created with the BUILD command. If that file name is then issued to the shell then the commands will be executed. Background working can be ensured by set. ting the job priority to be low, with the SETPR command.

Multi-user access to individual files can be controlled with the shareable bit, set with the ATTR command (see above). When this bit is unset, simultaneous access by several processes is allowed. Unpredictable results caused by simultaneous access with WRITE rights is prevented with 'lock-out' of other users from the sector last read by a process; setting the shareable bit enables ‘lock-out'.

Unfortunately, the BACKUP facility only works between disks of the same format; therefore, it cannot be used to backup the Winchester onto floppies. There was supposed to be a DSAVE command, which scans the ‘A’ disk and generates a command file to copy all the files of the disk; we could not find DSAVE to test it. Since backup is important, and is done so frequently (isn't it?), and is so tedious and time-consuming, and is done when you are tired at the end of a hard session, then it should be easy to do. What is needed is a facility to scan the complete disk file structure, copy across files until the floppy is full, demand attention when this happens and pause for a response when a new floppy has been loaded, etc, until the backup has been done. There should also be a log of where each file has been stored, for later recovery purposes. Alternatively, a tree copy command would have helped; this would copy all the files and sub-directories that came below a specified directory. This would work okay if you could be sure that the selected sub-tree would fit onto a single floppy; otherwise you would have the problem of breaking up the tree structure.

As a multi-user operating system, OSI has certain defects. For example, the activities of different users are not isolated from each other; it is possible for a process to access memory outside its legitimate address space (using POKE in Basic, for example). Thus, a program with bugs in it (and what program of any size is bug free?), can corrupt another's process. Also, it is possible to redirect input/output between user terminals without the other user's permission; this causes some very interesting effects. More seriously, files on disk backing store cannot be considered to be secure. When the '@' character is appended to the reference to a disk drive, then the whole disk is regarded as being a single file. It is possible to completely circumvent the file security system. A malicious individual could overwrite the complete contents of the disk. We should perhaps also mention that if you set up the password file as suggested in the manual, it has public reading rights!

Basic 09

A language that can be compiled, has optional line numbers, needs a line editor to change the program, has Pascal-like control structures (plus some more) and variable typing and declarations in addition to the usual Basic ones) and has Fortran type integer, real and character descriptors in the PRINT USING statements cannot sensibly be called Basic.

Basic09 is strongly orientated towards the use of procedures. When one invokes Basico9 one needs to supply the name of a procedure (by means of the LOAD command - load a procedure file, or the E command – edit a procedure), or the system chooses the exciting name PROGRAM. Editing takes place within one procedure, until you exit from that procedure. One can load more than one procedure into the Basic workspace, and can save one or all the procedures into a named file (the name of the procedure(s) are distinct from the file name(s), although the default file name is that of the first procedure in the work space).

The Basic editor is entered with the E. (procedure name) command, and thereafter can be used for line or string orientated editing. The former is the usual Basic mode, where numbered lines can be entered in any order, a line is replaced by re-entering it, and lines are deleted by entering the line number alone. However, since line numbers can be omitted (indeed you are encouraged to do so, to make the program more compact and faster in execution), standard text editor commands are also provided. These include, insert lines above the current line, delete one or more lines from the current position, search for a specified string of characters, and replace the specified string by another string (either for the first occurence, or globally throughout the procedure). Lines are parsed, and converted to an internal format immediately on entering, rather than at run-time as is more usual with microcomputer implementations of Basic. An additional benefit of this approach is that reserved words (eg, FOR, NEXT, etc) are printed in upper case, regardless of the case in which they are entered. This aids clarity; unfortunately, it also means that when you use the string search or string change commands, you may have to remember to SHIFT to upper case (very annoying). What is less nice about the editor is that one backtracks a line with the symbol and moves to the top of the procedure with the <* combination; these characters required a SHIFT on the keyboard, and are therefore two-handed operations. One exits from the editor with the Q command; subsequently the interpreter carries out further syntactic checks that could not have been done on a line by line basis (eg, for undeclared arrays).

Once back in SYSTEM mode (as opposed to EDIT mode above), one can issue many of the usual Basic commands: LOAD, SAVE, LIST, RUN, etc. There is room for criticism of the ease of use of some of these commands; For example, in the editor one enters *1*' to list the procedure, but LIST is required in SYSTEM mode to list the last used procedure in the Basic workspace. LIST*, however, causes all the procedures in the workspace to be listed. Where this really matters is with the SAVE command, which saves the last used procedure, and SAVE*, which saves all the procedures in the workspace; in both cases the default file name is that of the first procedure in the workspace. Thus, if you enter SAVE (or, even, SAVE *) instead of SAVE* onto an existing SAVED file, then you lose all the procedures except for the first.

One unusual command is PACK, which compiles the procedure(s) and stores the result in the execution directory (which you may be sharing with many other users, of course!). Also, commands can be issued to the SHELL from SYSTEM mode, by inserting a '$ character in front of the command.

The atomic data types of Basic09 are BYTE, INTEGER, REAL, STRING and BOOLEAN. All can be input, operated upon and output. There is a memory saving advantage to using byte values, but no speed advantage. Obviously, there is both a speed and memory advantage to the use of the integer values rather than real values. There are variables capable of holding values of all these types. The default variable types are REAL or STRING (when the name ends in a '$' character). Other types have to be declared with a Pascal-type construct (eg, DIM a,b,c:INTEGER; n, m: decimal; x,y,z:BOOLEAN – where decimal is a user defined type). User defined types are created with the TYPE statement. Thus, TYPE cust_ record = name, address (3): STRING; balance creates a type consisting of a name string, an address string vector of three elements, and a balance (of type REAL, by default). Therefore, later in the program the declaration DIM trans_record: cust-record can be made.

Both sequential and random access files can be accessed from Basic09. There are statements to CREATE, OPEN, CLOSE and DELETE files; one can specify READ, WRITE, UPDATE (both READ and WRITE access), EXEC (open in the execution directory, rather than the data directory) or DIR (open a directory file can only be used for READ access). Sequential files contain only ASCII data and are accessed with the usual Basic commands of READ <channel and write <channel>; these carry out any necessary conversions to ASCII format (eg, of numeric values). Random access files contain identical representations to those used in main memory. Thus, the conversion overhead is avoided (although the files are no longer human-readable with the LIST command). One can move to any byte position in the file with the SEEK command. Transfer to and from the file is accomplished with the PUT and GET Statements. These can operate on simple variables, arrays, strings, or complex user-defined structures. The last is very useful, and can be contrasted with the input/output of structures to the standard I/O paths, where each item of the structure has to be handled individually.

Basic09 is very well served for control statements. These are IF <condition> THEN <linenumber>, IF <condition> THEN <blockofstatements> ENDIF, IF <condition> THEN <blockofstatements> ELSE <blockofstatements> ENDIF, two FOR/NEXT (selected by the interpreter/compiler on the basis of the loop variable type – REAL or INTEGER, the latter is faster), WHILE <condition> DO <blockofstatements> ENDWHILE, and a REPEAT <blockof statements> UNTIL <condition>. Unlike Microsoft-type Basics, <blockofstatements> can be of any length, and the statements are not confined to one line. If that were not enough, there is a LOOP <blockofstatements> ENDLOOP construct which sets up an 'indefinite' loop. Exiting from this loop is accomplished with an EXITIF <condition> THEN <blockofstatements> ENDEXIT construct. When the condition is satisfied, then the block of statements is executed, before control is transferred to the statement below the ENDLOOP statement. Several of these constructs can be included within one loop. This provides a very nice answer to the situation when one wishes to exit from a loop for one of a variety of reasons and to carry out various tasks depending on the particular condition. Basic09 also provides the more usual GOTO, GOSÚB/RETURN, ON... GOTO, ON... GOSUB and ON ERROR GOTO constructs.

Basic09 procedures are completely self-contained as regards variables and line numbers. Values may be passed by reference (by default) or by value. The former is the more common, and means that the address of the memory location is passed to the called procedure; this allows the location to be modified before returning to the calling procedure. In call-by-value, only the value is passed to the called procedure, and hence the value is protected against modification. The method by which call-by-value is selected is rather clumsy; an expression is supplied to provide the required value. If the value is to be extracted from a single variable then an expression must be forced, by adding 0 to the variable, for example. Unusually, if a procedure is to accept values from a calling procedure then the variables in the called procedure are not declared with a DIM statement, but with the PARAM statement; the syntax is identical to the DIM statement. Whereas the DIM statement causes memory space to be set aside. PARAM does not.

Other minor details of Basic09 are: PEEK and POKE are allowed; commands to the shell can be issued with the SHELL command, followed by the actual command in string quotes (eg, SHELL 'copy file1 file2'); TRON and TROFF set the trace flag; one can set whether the storage locations specified in the DIM Statements run from 0 to N-1 or 1 to N with the BASEO and BASE1 statements respectively (the latter is the default); the usual READ/ DATA internal data system is supported

PRINT USING is very unusual, being based on Fortran-type descriptors. Thus 14 specifies that the integer should be presented to four digits, R8.2 specifies that the real number must be presented with a field width of eight (including provision for the sign and for the decimal point) and with two decimal places; E10.2 specifies that a number should be presented in standard form, with a total width of 10 places (including the six positions for sign, decimal point and exponent), and two decimal places. Descriptors also exist for outputting numbers in hexadecimal form, for strings and for boolean values. If during program execution any of the following conditions arise then Basic09 enters DEBUG mode:

1. an error occurs that is not intercepted by an ON ERROR GOTO statement;
2. a PAUSE statement is executed; or
3. a keyboard interrupt (CONTROL-C) occurs.

In DEBUG mode you can:

1. send commands to the shell;
2. set up break-points;
3. CONTinue program execution;
4. list a DIRectory;
5. Quit DEBUG mode;
6. assign values to program variables;
7. LIST the suspended procedure;
8. PRINT values of procedure variables;
9. set the trig function mode to RADian or DEGree; and
10. call the “nesting order of all active procedures.

Access to the high resolution' graphics (240x240) of the system is via a procedure LINE. Little documentation was available on how one could exploit the graphics system, although no doubt something could be worked out using LINE and POKE statements. Nevertheless, in comparison with the very much cheaper BBC and Sinclair Spectrum systems, the graphics facilities can only be described as thin. Access to the 'system console', ie, the main keyboard as opposed to additional user VDUs, would be necessary to display graphics: this could pose security problems when used by school pupils, students, etc, in an educational establishment.

One could take one of two opposing views to Basic09. One could say it's a dog's breakfast of features from Basic, Pascal and Fortran; or one could say that it is a sensible attempt to combine the best of the other three languages, although, inevitably, some will dispute whether it does achieve that. A possible criticism of Basic09 is that it is peculiar (ie, unusual), which nullifies one of the supposed advantages of high level languages – their consistency across many computer systems (hollow laugh in the case of Basic). If one regards Basic as what it was originally intended to be, ie, a beginner's language, then Basic09 is easily defended. It introduces programming constructs such as sophisticated control loops, user-defined structures (cf Pascal and Algol 68), procedures (and pass by reference and value), and so on, in a much easier format than, say, Pascal or Algol 68. If Basic is to be regarded as a standard programming language, with some degree of standardisation, then Basic09 offends more against the minimal Basic standards than do most implementations. Nevertheless, in its own right it is a powerful and easy to use language.

OS-9 Pascal

Microware Systems' Pascal compiler generates p-code objects which can be interpreted by a 'normal' interpreter (PascalN) or a 'swapping' interpreter (PascalS) for large programs. Alternatively, PascalT is a native-code translator which accepts p-code files as input and produces 6809 assembly language source code. The compiler is invoked by means of a fairly complex command line:

Pascal (source p/n)list p/n)) stats p/n exec. options: parameters

(where p/n stands for 'pathname'). Of these, only the source pathname is mandatory (unless you want to type the code straight off the keyboard directly into the compiler). Two standard output files are produced by the compiler, PCODEF (the actual codefile) and PROCTAB, the compiler's workfile which is left in the data directory after the compiler exits (rather untidy). The ‘parameters' field in the command-line can be used to redirect these files to other pathnames – essential if two or more users are to share the same data directory. In addition there are parameters to specify the format and extent of source and symbol-table listings, inhibit run-time range-checking and suppress the insertion of (diagnostic) source line-numbers into the p-code.

Optional range-checking covers array bounds, memory references via pointers, and boolean and subrange type assignments. Exec-options define stack, heap and swapping buffer sizes together with string justification (leading or trailing blanks), MOD function algorithm, runtime error response and heap control options. Pseudo-comments covering most of the parameter and exec options may alternatively be embedded in the Pascal source. The list and stats path names default to the terminal convenient for the most interactive program development.

The compiler allocates one byte of storage for each character and boolean, two bytes for each integer and five bytes for reals (ie, about nine significant (decimal) digits * E=38). String constants may extend to 100 bytes and procedures may contain a maximum of 32 kbytes of p-code each while a program may have up to 254 procedures declared within it. The compiler will accept hexadecimal constants, prefixed with a '$' sign. The keyword OTHERWISE has been added to the CASE construct as a catch-all clause. The compiler accepts subrange specifiers (eg, 'a'. :'Z') both within CASE definitions and SET membership assignments.

Both p-code interpreters are invoked by a command line of the following form: PASCALx <input p/n >output p/n >> syserr pcodename exec.options:params 'x' is either 'N' or 'S' depending on interpreter. Input and Output are the standard Pascal I/O files while Syserr is a standard OS-9 device which has been added to the Pascal standard devices. The pathname 'pcodename' is the only mandatory entry, being the actual codefile. Considering its position in the command line, in relation to the source file in a compiler's command line, one can see that the Pascal environment is not especially 'orthogonal. Params. is a user-defined string which is passed directly to the program once execution begins (so that a user-written program can behave similarly to an OS-9 utility, accepting a 'command line'). This is a nice feature but not as powerful as it might be under version 1 of OS-9 since the command line operators ('<', >, '&', etc) are not allowed.

The swapping interpreter implements a full fixed-page virtual code swapping algorithm whereby a minimum of eight 256-byte pages are maintained in memory and only the code for locked or active procedures need exist in memory at any time. Strings are stored in separate pages so that additional pages (over the eight) need to be allocated for procedures which reference strings and remain active. Obviously, the more pages allocated the more efficiently the program will run, and the manual emphasises that an experimental approach must be adopted in optimising performance.

PascalT is a Pascal program which translates p-code into 6809 assembler language. Up to 36 reduction rules are employed to optimise for speed and space, although, on average, each byte of p-code generates just under two-and-a-half bytes of native code, so care needs to be exercised when translating large programs, especially on a floppy-based system. PascalT runs under the PascalS interpreter and prompts for input and output filenames. Not all procedures in a program need to be translated into a single output module with a separate file of (external definition) references for subsequent use by the link/load utility PascalE. It is possible to embed the original source line numbers in the assembly file. If the partial translation is done, the relevant procedures must be removed from the Pascal source-file and replaced with external references. The modified Pascal source-file is then re-compiled before being linked with the assembled native-code module. Native-code modules may not be swapped (which probably explains why PascalT must run under PascalS).

If an entire program is translated it can be invoked by: program <input >output >> syserr exec.options : parameters where all terms are as previously described for the interpreters including the parameter string 'parameters'. For true optimisation it is necessary for the user to provide PascalT with information about local and extended stack and heap space - this is prompted for during execution.

Positron memory map

Apart from the CASE statement extensions mentioned earlier, OS-9 Pascal differs from standard Pascal in that the underscore character is recognised in identifiers; strings are implemented; procedures and functions may not be passed by name; files may not be passed by value (and may be omitted in the PROGRAM statement); DISPOSE, PACK and UNPACK are not implemented and PACKED is ignored (although variable space is allocated on byte boundaries). Character arrays can be indexed (in their rightmost dimension) by the form 'p FOR q' where p and q are integers such that p is the index of the first element to be referenced and p+q is the element of the last element referenced. Thus:

String [1 FOR 5] ;= 'ERROR'.,

OS-9 distinguishes between terminal-like' (SCF) and 'disk-like' (RBF) devices and this distinction is carried over into the OS-9 Pascal I/O. RBF files follow the proper language specification while SCF files get around the usual Pascal 'interactive problem by only loading the buffers when they are needed (lazy I/O). This means the EOLN and EOF functions behave slightly differently for the two types of file. The boolean function INTERACTIVE(filename), which returns a value of TRUE whenever 'filename' refers to an SCF-type file, must be employed to provide the customary interactive I/O. A number of 'standard' procedures and functions are provided for file-handling and interacting with OS-9. These include the ability to access the file of error-messages and to suppress non-fatal OS-9 I/O errors. Other procedures and functions allow, among other things, for the trapping of certain arithmetic errors (overflow, range, divide by zero); bit manipulation within integers and forking to the SHELL. There are three run-time support packages, SUPPORT (9k), which contains all routines, SUPPORT1 (7k), which lacks the transcendental functions and SUPPORT2 (5k) which lacks support for any reals and some of the file-handling procedures.

Other software

Several other software items which, for one reason or another, we were not able to review in much detail include a full implementation of CIS Cobol; a C compiler; an interactive assembler and debugger; a word-processing package, Stylograph; and RMS, a record management system. According to Positron, negotiations are underway to obtain a rather fruity suite of commercial packages which will run on the system via the CIS Cobol implementation.

Stylograph features normal cursor-controlled screen editing with additional block operations and text-formatting functions like filling, centering, headers, footers, etc. The system is designed to interface to individual terminals and printers by means of separate drivers which seem fairly straightforward to construct. It is possible to direct output to disk files and to pass commands to OS-9 from within Stylograph. Positron claim that a new version will incorporate a ‘mail-merge’ facility.

RMS is a suite of programs which enable the user to create a record format specification (up to 1022 bytes long), to create and maintain a file of (up to 65,536) records according to the record specification and to output a selection of the records according to a predefined print-format. A system of secondary records may be associated with each primary record, one (common) field being designated the KEY field (storage is by hash coding). Fields may be alphanumeric, numeric or in 'money' or 'data' format. Validation can be according to length, range or membership of an explicit list. Output can be driven by a file of symbolic commands created by a text editor. It would probably be preferable if the commands were a bit more wordy as a complicated output 'program' would be quite difficult to debug. Index files (which merely contain a list of KEY values in some significant order) can be used to access the file selectively — but these must be assembled ‘by hand' with a text editor and ordered with a SORT/ MERGE package (not supplied). Overall, it seems convenient and flexible to use although not particularly powerful or comprehensive.

Potential

The Positron 9000 is a difficult system to place in the marketplace. It's too different (and a bit too expensive) to compete with any of the standard, single-user CP/M systems with their huge repertoire of software; it certainly isn't a hobbyist machine; yet it offers a multitasking operating system (not necessarily even with disks!), a substantial expansion pathway and the potential for multiple users. At the same time there is the Viewdata terminal capability which doesn't really seem to fit in with the rest of the system.

In fact, the machine has been offered for some time to schools but while Basic09 is a very reasonable language with which to learn programming (as is Pascal), we felt that the multi-user aspects of OS-9 (level 1) were not sufficiently robust to provide a stable programming environment for a number of (beginning) users. Keyboard operations are noticeably affected when more than one user is active (hard to expect beginners to take this into account); and we found that the system rejected processes when memory filled up (instead of, perhaps, queuing them), requiring human intervention (hence a supervisor). Perhaps level 2 of the operating system copes better with these problems.

On the other hand, the 6809 is a processor well-known to and much admired by a number of digital designers and any professional who takes the trouble to learn the intricacies of OS-9 (and that includes Unix programmers) should be able to construct themselves a fairly comfortable development environment. The system has a vast capacity for ROM and provides a cheap route to multi-tasking which should mean that, with careful programming, a fairly robust, turnkey delivery system could be built. We would guess that such a system, with its well-designed boards and expansion capabilities, should appeal to industrial OEMs, especially those expecting to exploit GPIB devices, provided they don't need to push that single little processor too hard. Additionally, a nationwide maintenance service is provided for Positron by Fisons Scientific.

Documentation

The documentation was of a quality which computer professionals have grown to expect – that is, most of the information was there if one was prepared to persevere. We estimated that about five passes through the manuals would be necessary to resolve all unknown references! They were good in places, obscure in others and occasionally out of date elsewhere. As with much technical documentation, a fairly creative approach should be adopted to its interpretation, although a first-time user would have a bit of trouble dealing with some of the terms which were introduced without much explanation (eg, recursion).

The manuals covered the following major topics : OS-9, Basic09, Pascal, CIS Cobol, the interactive assembler and debugger, the text editor, Stylographic and system programming.

Basic Benchmarks

All timings in seconds. For an explanation and listing of the Benchmark programs, see page 6.

Pascal Benchmarks

These figures were obtained with the interpreter PascalN. We would have liked to have obtained figures for the native-code (PascalT) version but ran out of time.

Multi-user Benchmarks

We had a certain amount of trouble with the multi-user Benchmarks owing to the restriction of four concurrent processes per memory management unit. Regular PCW readers will remember these tests, introduced in February 1981. They include a processor test (actually Basic BM7 above) and two disk access tests which write and read 100 128-byte records to and from the disk, in the first case opening and closing the file after each read/write; in the second using only a single open and close for all writes and reads. These are designed to look at filing system overheads and record locking schemes. Finally the I/O test lists the printable ASCII subset 100 times. The disk tests utilised the Winchester disk.

In the event, it was not possible to observe any degradation in performance although equally we were disappointed not to be able to run more than two tasks simultaneously on the review system (with an additional terminal attached). The timings appear below:

Attempts to get more processes running resulted in a memory full error which is a pity since we wouldn't have minded waiting if the tasks could have been queued.

Conclusions

The Positron 9000 is a flexible, well-built multi-user system that runs a Unix-influenced operating system, OS-9. It has an unconventional but powerful Basic compiler, a Pascal compiler and CIS Cobol. There is a word-processing package and the promise of a record management system, a suite of accounting software and a C compiler. It can take up to 512 kbytes of RAM and 256 kbytes of ROM, has up to 8 RS232 ports, an IEEE-488 bus, floppy and hard disks, and a network.

However, we believe it is based on a faulty design philosophy: in the days of cheap processors, a lot of hardware and software has been made dependent on a single, slow 8-bit processor. The basic system is more expensive than its competitors because it has so much built-in potential for expansion, yet for many applications requiring the extra resources the processor is likely to run out of power. Nevertheless, applications which may not be processor bound and which can exploit the low-cost multitasking software, perhaps in the field of process and industrial control, could find the Positron has few real competitors.

Technical data

Prices