22

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.

  • 1
    It doesn't address the question given but if it's any help as to causation, the long-accepted version is that the Acorn hardware team was split on what the machine should be — a future-oriented thing with one of the new generation of processors, or a best-of-the-current thing with the same processor as the previous few years. They ended up with a compromise that they'd ship a 6502 base machine but give it a slot that relegates the 6502 to IO if something more advanced is attached. Eventually they used the slot to develop the ARM so I'd dare say that the compromise paid off. – Tommy May 15 '17 at 16:33
16

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.

  • 2
    I had 2 Tube based second processors I used. One was a 65C102 - basically an enhanced version of the standard 6502 co-processor, and it worked in almost exactly the same way (although it was faster.) The other was an 80186, which ran a version of DOS (CP/M was an option too, I think) and had the GEM GUI interface. Quite remarkable what could be done with it. (I cried when, due to a miscommunication, the whole lot was disposed of and destroyed.) – Rags Jan 31 '18 at 15:56
  • 1
    I was really excited to learn of the PiTubeDirect which enables a RaspberryPi to be connected as a ARM co-processor to the BBC Micro. youtube.com/watch?v=mP7fiaync5E news.ycombinator.com/item?id=16117053 youtube.com/watch?v=RLaeaoHXl4I – therobyouknow Oct 28 '18 at 9:47
15

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.

  • Nice answer. Was there software that could be had that could actually make use of tube-connected hardware? – tofro May 14 '17 at 19:36
  • @tofro plenty; if it's a 6502 second processor then anything that uses the MOS for input and output, plus others — e.g. youtube.com/watch?v=nIuOjEqY8Hk a version of Elite that uses both processors at once. – Tommy May 15 '17 at 2:26
  • @tofro The University of Cambridge had a Tube attached NS32016 based co-processor based system that ran an OS called Panos (which they later used in their stand-alone Acorn Cambridge Workstation). I don't know much about it, and it didn't seem much more sophisticated than MS-DOS, although it did have a built in concept of networking. I've repeatedly heard that there was a Unix for the Tube attached NS32016 co-processors, but I've never been able to confirm that. – KJ Seefried Oct 31 '17 at 3:10
4

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 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.