I keep reading of the BBC micro's tube interface that was apparently designed as a co-processor interface to the 6502.
I would be interested in what were actual applications of this interface and what hardware could be had supporting it. In case someone has information on how common those hardware expansions really were, I would be grateful as well.
The Tube interface was intended to enable the addition of what was known as a Second Processor. Although this was something of a misnomer as the additional processor became the main CPU of the system and the base BBC Micro became an I/O controller.
When running, the second processor's memory was addressed from &00000000 upwards, and the I/O processor's memory was identified by being addressed as &FFFF0000 upwards.
As other answers have said, the Tube was a fast FIFO buffer enabling communication between the two processors. The data was passed via the I/O processor's memory location &FFFFFEE5. The 6502 second processor was far and away the most commonly used. It would run the same code as the main processor, effectively providing much more memory to the running program as all the I/O buffers remained in the I/O processor.
From the I/O processor you had the following OSBYTE (or *FX) calls in the OS.
157 Write a single byte
234 Test for presence of second processor
Other OS calls affected the Tube
124 Clear escape state
125 Set escape state
142 Reset language ROM - copies language to second processor if present
247/8/9 Set Break intercept code
Within the second processor, you had OSWORD() calls:
5 Read I/O processor memory
6 Write I/O processor memory
These were used to transfer blocks of memory, not just single bytes.
If writing a language ROM for the BBC, it was assumed that the 6502 second processor would run the language if fitted. You had to encode the second processor relocation address in the ROM header. The language ROM's initialization routine would be called at startup with two extra entries, &FF and &FE which informed the ROM that it was running in the second processor.
Similarly, Filing Systems had to be Tube-aware.
Was there any software? Yes.
Some specific applications, like the BBC's Domesday Project, required the second 6502 processor. Torch Computers manufactured a 68000 second processor that came with Torch Unix. This was used in industry as a means of getting a cheap Unix box.
For home users, second processors were quite rare. The additional costs being not really worth the effort for a hobbyist. In education, they were more common, but not widely used. Their main use was in higher education, where the extra memory and wider variety of languages was of more use. They were seen in universities.
The more powerful second processors - 16032, 68000 etc. were quite short lived in industrial use. Technology overtook them quite quickly and cheaper, more accessible systems became available after only a couple of years of the Tube's existence.
Devices connected to the Tube weren't terribly common because they added further expense to an already rather expensive computer in the first place. The 6502 second processor was £200 and the Z80 was £300, which is about £600 and £900 respectively in 2017 money.
Hardware-wise, it consisted of a short bidirectional FIFO used for passing messages between the two processors. The higher-level software protocol arranged message-passing, which at a minimum would proxy OS calls from the second processor to be executed on the BBC Micro.
There is a lot of information about the Tube protocol at http://mdfs.net/Software/Tube/ which appears sufficient to implement your own second processor, as well as containing software and source code to get you started.
An obvious modern implementation of a second processor would be via a FPGA softcore, and this exists in the form of the Matchbox CoPro that claims support for the 65C102, Z80, 80286, 6809, 68000, PDP-11, ARM2 and 32016. Its GitHub page contains VHDL designs for the hardware.
Assorted additions to the existing answers:
The Robocom BitStik CAD system required a 6502 second processor, as a basic BBC micro didn't have enough RAM: it had originally been written in assembler for the 48KB Apple ][. It was fairly sophisticated for CAD on an 8-bit system, but being written in assembler meant it quickly became obsolete. There was also an enhanced version of the original BBC Micro Elite that required a 6502 second processor, and could be played with the BitStik 3-axis joystick. That joystick plugged into the ordinary BBC joystick port, using three of its four A-D channels for the three axes. The Apple ][ version of the Bitstik was mechanically the same, but had different electronics and connectors to fit the Apple ][ joystick port.
Panos was pretty simple. It was basically intended for running compilers and scientific programs on the NS32016, but the Acorn-influenced world gave up on 32016 in favour of ARMs, which were faster, cheaper and simpler.
