Acorn MOS

From Wikipedia, the free encyclopedia

Acorn's Machine Operating System is the computer operating system that powers the Acorn BBC computer range: the BBC Micro (MOS 0.1 to 1.2), the B+ (MOS 2) and the BBC Master Series micro (MOS 3). The article that follows is based on MOS 1.2 for the BBC Micro.

16 kibibytes in size (residing in the upper half of the read-only area of the Beeb's memory map), Acorn MOS is an extensible, single-tasking 8-bit operating system supplied on ROM. It includes support for four-channel sound and graphics, file system abstraction, co-processor support, and digital and analogue I/O including a daisy-chained fast expansion bus.

Contents 1 User interface 2 Extension 3 Text, graphics, printing 4 Sound 5 Other I/O and second processor support 6 MOS 3

[edit] User interface

The MOS is a command-line OS with no real user interface; applications are expected to forward operating system command lines to the OS on its behalf, and the BBC BASIC ROM supplied with the BBC Micro is the default application used for this purpose. In command-line programs, one typically precedes OS commands with an asterisk (to tell the program to forward the command line to the operating system) and they are thus commonly known as "* commands" and are typically shown with the asterisk as part of the name, e.g. *LOAD, *CAT, *TAPE etc.

Unrecognised commands are offered to any "service" (extension) ROMs; filing system ROMs will often check to see if a file on disc matches that name, the same most other command-line interfaces do. The operating system call OSWORD with accumulator = 0 does however offer programs single line input (with ctrl-U for clear line and the cursor copying keys enabled) with basic character filtering and line length limit.

The MOS command line interpreter features a rather unusual idea: abbreviation of commands. To save typing, use a dot to abbreviate the command as you would in English, such as *L. for *LOAD and *SA. for *SAVE. *SAVE should be *S. but in BBC BASIC – which also supports abbreviations – S. is STEP and SAVE can only be SA, so I imagine that to avoid confusion, the OS's SAVE command obeys the same limit. *CAT, the command to catalogue a cassette or disc, can be abbreviated right down to *. for convenience, with no letters in the command at all!

Service ROMs – which add new commands to the OS – generally also support command abbreviation.

[edit] Extension

The lower 16 KiB of the read-only memory map is reserved for the active Sideways paged bank. The Sideways system on the BBC Micro allows for one ROM at a time from sockets on the motherboard (or expansion boards) to be switched into the main memory map. Software can be run from ROM this way (leaving the RAM free of user program code, for more workspace) and the OS can be extended by way of such ROMs. The most popular such ROM is the Acorn Disc Filing System used to provide floppy disc support to the machine. During a reset, every paged ROM is switched in and asked how much public and private workspace it needs. Each ROM is allocated a chunk of private workspace that remains allocated at all times, and a single block of public workspace, equal to the size of the largest request, is made available to the active ROM. During operation, the paged area is rapidly switched between ROMs when file system commands are issued and unrecognised commands are put to the OS.

MOS allocates a 3.6 KB block of memory (0x0 to 0xE00) from the bottom of the memory map for operating system and language ROM workspace. On a cassette-only machine, 0xE00 is the start of user program memory. With OS extension ROMs fitted such as the a filing system ROM, more memory is allocated above this point; DFS ROMs generally use another 2.8 KB to cache the disc catalogue and manage random access buffers. A network filing system ROM (for Econet) allocates another half a kibibyte on top of this. This is a serious problem because MOS does not support relocation of machine code, which must be run from the address at which it was assembled.

The OS also maintains a vector table of all its calls which can be updated to hook any OS calls for user extension.

[edit] Text, graphics, printing

The MOS permits textual output intended for the screen to be directed instead to the printer, or both at once, allowing for very trivial printing support for plain text. Graphics printing is not supported and has to be written separately.

Graphics and in general all screen output is handled in a very unusual way. The ASCII control characters are almost entirely given new significance under MOS: known as the "VDU drivers", they are interpreted as video control characters. VDU 30 (i.e. ASCII 30) moves the cursor to (0, 0), VDU 4 and 5 select whether text should be drawn at the graphics or text cursor, VDU 12 clears the screen and VDU 14 and 15 turn scroll lock on and off. Thus, pressing ctrl-L will clear the screen and ctrl-N will enable scroll lock. VDU 2 and 3 toggle whether screen output is echoed to the printer.

Many more control characters take parameters: one or more characters that follow are used solely for their bit value as a parameter and not as a control code. VDU 19 handles palette remap; the following five bytes represent the palette entry, the desired colour and three reserve bytes. VDU 31 locates the text cursor to the location held in the following two bytes. VDU 17 sets the text colour and 18 the graphics colour. VDU 25 uses the succeeding five bytes to move the graphics cursor and plot solid and dashed lines, dots and filled triangles, the extent of graphics in MOS 0 and 1. The first byte is the command code, followed by the x and y co-ordinates as two byte pairs.

There is a single operating system command to write a character, OSWRCH, which is responsible for all text and graphics. For example, to move the cursor to (10, 15), you could write:

LDA #31: JSR OSWRCH \ move cursor
LDA #10: JSR OSWRCH \ x-coordinate
LDA #15: JSR OSWRCH \ y-coordinate

On the third OS call, the cursor will move. The following code would draw a line from (0, 0) to (0, +100):

LDA #25: JSR OSWRCH \ begin "PLOT" (ASCII 25) command
LDA #4: JSR OSWRCH \ command k=4, or move absolute
LDA #0: JSR OSWRCH: JSR OSWRCH: JSR OSWRCH: JSR OSWRCH
 \ send (0, 0) as low, high byte pairs

LDA #25: JSR OSWRCH \ begin PLOT
LDA #1: JSR OSWRCH  \ k=1 - draw relative
LDA #0: JSR OSWRCH: JSR OSWRCH \ x = 0
LDA #100: JSR OSWRCH \ y = 100 (low byte)
LDA #0: JSR OSWRCH   \ high byte

In BBC BASIC you can perform the above as any of the following:

VDU 25, 4, 0; 0; 25, 4, 100; 0;

PRINT CHR$(25); CHR$(4); CHR$(0); ... etc.

PLOT 4, 0, 0: PLOT 1, 0, 100

MOVE 0, 0: DRAW 0, 100: REM absolute co-ords only!

Graphics in the Acorn MOS use a virtual graphics resolution of 1280x1024, with pixel positions mapped to the nearest equivalent pixel in the current graphics mode. Switching video resolution will not affect the shape, size or position of graphics drawn even with completely different pixel metrics in the new mode, because this is all accounted for by the OS.

There are in fact two other OS calls that handle text output: OSNEWL (write a newline as CR/LF) and OSASCI, which adds a line feed every time it spots a carriage return. These no doubt call on OSWRCH for their own work.

[edit] Sound

Sound support is done with another OS call, OSWORD, which handles a variety of tasks enumerated via a task code placed into the accumulator. All OSWORD calls bear a parameter block used to send and receive multiple data, passed into the X and Y registers. There are four buffered sound channels -- three melodic and one noise -- based on the sound chip found in the BBC Micro. There is only one waveform for melodic channels; the supported note parameters are pitch, duration, and amplitude. The amplitude parameter is normally negative; positive values select an envelope to apply to the note. Other meta parameters include flush (the buffer is cleared and the channel silenced before the note is played) and synchronise count (as soon as the same synch count is received for that many channels, all the synchronised notes are played together).

[edit] Other I/O and second processor support

The OS has calls to handle reading and writing to all I/O (ports and screen memory) and programmers are strongly advised to use these. The reason for this being is that when a second processor is installed, user software is run from the separate memory map on the far side of the Tube® processor bus, and direct access to memory-mapped I/O registers and video memory is impossible. However, for the sake of performance, many apps including probably all assembled games write directly to main memory for I/O, and hence crash or give you a blank screen if a 6502 second processor is attached. One issue involved here is a lack of sprite support in the OS and a need to handle this manually from user code.

The MOS contains two built-in file systems: cassette and ROM - the ROM filesystem is quite similar to the cassette filesystem (try *ROM, *OPT 1 2, *CAT with a suitable ROM installed).

[edit] MOS 3

MOS 3, which shipped with the BBC Master, adds a variety of new features such as a real-time clock and settings in non-volatile RAM, extra graphics commands including rectangles and ellipses, and a proper command line, available for example to reconfigure the machine when the non-volatile RAM is corrupt.