Tube (BBC Micro)

In the BBC Microcomputer System, the Tube is the expansion interface and architecture which allows the BBC Micro to communicate with a second processor, or coprocessor.

Under the Tube architecture, the coprocessor runs the application software for the user, whilst the Micro (acting as a host) provides all I/O functions, such as screen display, keyboard and storage devices management. A coprocessor unit can be coldplugged into any BBC Micro with a disk interface (whose ROM contained the necessary host software) and used immediately.

The 40-pin IDC "Tube" connector is a simple slave connection to the host processor's main bus, with 8 data lines, 7 address lines, and an interrupt input. The Tube protocols are implemented by hardware in the attached device.

Inside the coprocessor unit a proprietary chip (the Tube ULA, manufactured initially by Ferranti) interfaces and logically isolates the host and coprocessor buses. This allows the Tube to work with a completely different bus architecture in the coprocessor unit. The other active components needed are a microprocessor, some RAM, a small ROM containing processor specific client code, glue logic such as an address decoder and a power supply.

The two processors communicate through four pairs of FIFO buffers in the Tube ULA. Console input/output, error messages, data transfers and system calls each have their own pair of buffers, one for each direction. The queue capacity varies between 1 and 24 bytes, depending on the dedicated buffer function. Each buffer has a control register and status register to monitor its state and configure the raising of interrupts.

The protocol for the use of these buffers was rigorously specified by Acorn Computers^[1] and amounted to interprocess communication by message passing. Most interaction is asynchronous but fast block transfers are synchronous and consist of the host blindly running a simple fetch-store loop, which defines the transfer rate. The coprocessor is synchronised by passing a dummy byte and then regulated by the relevant buffer semaphore.

The general-purpose nature of the Tube connector in principle allows it to be used for any type of high-speed peripheral, although Acorn only uses it for Tube coprocessors. The BBC Micro/Master range provides 5 address lines for the address range &60–&7F but the Tube protocol uses the lowest 3 bits. Only these 3 address lines are connected to internal Tube sockets, as found in the BBC Master or Universal Second Processor Unit.

Numerous coprocessors were developed for the Tube. Most commonly seen was the 6502 Second Processor, featuring a MOS Technology 6502 processor, which allowed unmodified BBC Micro programs to run faster and with more memory, as long as they use the API for all I/O.^[1][2] The Z80 Second Processor featured a Zilog Z80 processor running CP/M, and the 32016 Second Processor featured a National Semiconductor 32016 processor running Panos.

These coprocessors formed the basis of the Acorn Business Computer series, the higher end machines being repackaged BBC Micros with a coprocessor attached via the Tube. The Master Series supports two Tube connections, allowing for a coprocessor fitted inside the case and another connected externally, but only one can be used in any powered session. An internal 6502 processor can be fitted, or an Intel 80186 based system for DOS compatibility (although in practice this is limited).^[3]

The Tube was also used during the initial development of the ARM processor. An evaluation board was developed that again uses the BBC Micro as a host system for I/O operations.

Before shipping Tube add-ons, Acorn had strongly discouraged BBC Micro programmers from directly accessing system memory and hardware, favouring official API calls.^[4] This was to ensure applications can be seamlessly moved to the Tube 6502 coprocessor, since direct access from there is impossible. When a program calls one of the MOS entry points, a replacement subroutine in the coprocessor's ROM passes a corresponding message to the host which carries out the operation and passes back the result. In this way an application can run identically on the host or the coprocessor. Other CPU models use a custom API, which is typically an orthogonal translation of the 6502 API into a native format.