Tube (BBC Micro)

In computing, the Tube was the expansion interface and architecture of the BBC Microcomputer System which allowed the BBC Micro to communicate with a second processor, or coprocessor.

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

Implementation

The 40-pin IDC "Tube" connector was 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 were implemented by hardware in the attached device.

Interior of 6502 Second Processor

Inside the coprocessor unit a proprietary chip (the Tube ULA, manufactured initially by Ferranti) interfaced and logically isolated the host and coprocessor buses. This allowed the Tube to work with a completely different bus architecture in the coprocessor unit. The only other active components needed were 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 communicated through four pairs of FIFO buffers in the Tube ULA. Console input/output, error messages, data transfers and system calls each had their own pair of buffers, one for each direction. The queue capacity varied between 1 and 24 bytes, depending on the dedicated buffer function. Each buffer had 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 amounts to interprocess communication by message passing. Most interaction was asynchronous but fast block transfers were synchronous and consisted of the host blindly running a simple fetch-store loop, which defined the transfer rate. The coprocessor was synchronised by passing a dummy byte and then regulated by the relevant buffer semaphore.

The general-purpose nature of the Tube connector in principle allowed it to be used for any type of high-speed peripheral, although Acorn only used it for Tube coprocessors. The BBC Micro/Master range provided 5 address lines for the address range &60–&7F but the Tube protocol only used 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.

Application

Numerous coprocessors were developed for the Tube. Most commonly seen was a MOS Technology 6502 processor which allowed unmodified BBC Micro programs to run faster and with more memory, as long as they used the API for all I/O.^[1] There was also a Zilog Z80 processor to run CP/M and a National Semiconductor 32016 processor running Panos (and unofficially a UNIX variant).

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 supported two Tube connections, allowing for a coprocessor fitted inside the case and another connected externally, but only one could be used in any powered session. An internal 6502 processor could be fitted, or an Intel 80186 based system for DOS compatibility (although in practice this was limited).^[2]

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

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

References