Acorn's Second Processors and the Tube - what, and why

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
BigEd
Posts: 1548
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Acorn's Second Processors and the Tube - what, and why

Postby BigEd » Tue Dec 12, 2017 7:43 pm

I thought I'd try my hand at explaining what the Second Processors are all about. I may well be duplicating some existing explanation - I'll be happy to accept corrections, clarifications and links. See for example the first few paragraphs of Acorn's Tube Application Note, the various resources on JGH's ADFS.net, and various pages on BeebWiki.

Pretty much every 1980's home computer had a keyboard, and most plugged into a telly or a monitor. A few had the screen built in. Similarly, if there wasn't a cassette recorder built in, there'd be audio in and out for cassette storage, and there'd usually be a speaker or a beeper or sound from the telly. All of those facilities constitute Input and Output, also known as I/O, and are the means by which the user interacts with the machine, and specifically with the software that's running on the machine.

Acorn's BBC Micro was particularly well-equipped with I/O, and as with with many other micros it could also be connected to joysticks, a printer, a disk drive, a network, a speech chip, a serial device such as a modem, and other devices.

Acorn realised two things about all this I/O hanging off a 2MHz 6502: it takes code and RAM to deal with the devices, and it takes CPU time too. While the CPU is putting characters or graphics on the screen, or moving data to or from the floppy, it's not running the application. With 16k of Machine Operating System, 16k of Disk Filing System, 20k of RAM available to the video and up to 3k of RAM in use by the OS and filing system, there can be as little as 6k of RAM left for a Basic program's code and data. (Or as much as 28k, but that's less relevant.)

Another thing Acorn realised is that a 2MHz 6502 isn't always fast enough or even an appropriate CPU for all purposes.

And so the BBC Micro includes a Tube interface, which adds very little cost to the base system, and is just a little-used 40 way IDC socket underneath the keyboard. (The later Master machine also includes an internal Tube interface, and aftermarket inventions allow for a Tube interface to be added to the cost-reduced Electron and even the earlier Atom computer. So all of Acorn's 8-bit offerings are Tube capable.)

Physically, then, the Tube is a 40 way socket. To use it, you add an external box and connect with a 40 way cable.

Logically, at a low level, the Tube is a fairly simple 8-bit peripheral, occupying 8 addresses in the host's memory space, which offer four channels from the host to the Second Processor and four channels from the Second Processor to the host.

But the beauty of the Tube is that it's almost invisible, both to the computer user and to the software. If you have an unexpanded Beeb, you type at the keyboard, look at the screen, and interact with software running within 32k of RAM on a 2MHz 6502. If you have a 6502 Second Processor plugged in, you type at the keyboard, look at the screen, and interact with software running within 64k of RAM on a 3MHz 6502. Suddenly your Basic program has 47k of space to operate in and runs a lot faster.

The reason the Tube is almost invisible is that Acorn's Machine Operating System has a compact and well-defined interface, and all well-behaved software which uses that interface for all I/O purposes can run unmodified either on a base Beeb or on one with a 6502 Second Processor attached. Almost all games are not in that category, but they can run as they were if the Second Processor is removed or disabled. Elite, famously and perhaps uniquely, does come in one or two versions which can use the Second Processor, in which case the game has more features and better graphics.

But there's much more, because the Second Processor doesn't even have to be a 6502. With the Z80 Second Processor, you can run a Z80 version of Basic, or other application programs, or the CP/M operating system and any number of programs which run on that. With an x86 Second Processor, you can run DOS and GEM. With a 6809 Second Processor, you can run the Flex OS. With an ARM Eval System you can run any ARM code you care to write, or the ARM version of BBC Basic. With a 32016 Second Processor you can run PanOS, with various compilers available. (Indeed, Acorn made a Scientific Workstation which was basically a Master integrated with a monitor, a 32016 Second Processor, a SCSI interface and a hard drive.)

These days, there's even more, because there's the FPGA-based Matchbox copro, Sprow's ARM copro, John Kortink's copros, and the most impressive and inexpensive PiTubeDirect copro, which is just a cheap Raspberry Pi and a simple level shifter circuit.

With the Matchbox, you can run all the above flavours and also a PDP-11. With the Pi, you can run all the above in emulation and also a full-speed 1GHz ARM copro.

It's even better than that, as RobC has demonstrated: the Pi's full-speed ARM copro can emulate another micro entirely, such as a ZX81 or a Jupiter ACE.

Edit to add a few more points:

The Tube is unique in being part of the design of the computer from the beginning, including the design of the OS. The idea is there's only one application processor, which is the Beeb itself if that's all there is, or is the Second Processor if there is one. The application sees the same OS facilities in both cases. It's a different kind of challenge to add multiple processors or to add processors to other 80s micros. It's perhaps more likely to add an accelerator of some kind and to keep the application running on the original machine.

Elite, and a couple of other programs, do in fact run the application on the Second Processor and also some acceleration code on the host. For example, application-specific drawing commands or update information can be sent to the host which then computes the display update before drawing it. As the protocol is application-specific it can be more efficient. The host can use more of its CPU resources to offload from the Second Processor.

The Pi as a Second Processor is unusual in having multiple CPU cores available. As yet we haven't seen aggressive use of that. The Pi also has I/O of its own, including video out, solid state storage, and possibly network connectivity. The one case I'm aware of using this is hoglet's Atom display gadget which uses the Pi's video out.

Now that there's a modern wave of affordable Second Processors, it's possible we'll see modern retro games and other software which makes use of them. There are a few hundred Pi and Matchbox installations already, in addition to anyone already running an original Second Processor or Master Turbo.
Last edited by BigEd on Wed Dec 13, 2017 9:36 am, edited 1 time in total.

northernbob
Posts: 49
Joined: Fri Nov 24, 2017 6:49 am

Re: Acorn's Second Processors and the Tube - what, and why

Postby northernbob » Wed Dec 13, 2017 8:27 am

ok ive read that, and will rethink about it next week,

I came across an idea a few months ago, which might apply here....

see attached.

http://www.bbcbasic.co.uk/qb2bbc/index.html

article is from here....

http://www.petesqbsite.com/sections/exp ... index.html

download...

http://www.petesqbsite.com/sections/exp ... /Multi.zip
Attachments
Multi_Processing_Core_for_QB.doc
(40 KiB) Downloaded 9 times

User avatar
BigEd
Posts: 1548
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Acorn's Second Processors and the Tube - what, and why

Postby BigEd » Wed Dec 13, 2017 9:37 am

I've added a few more points to the bottom of the head post.

User avatar
kieranhj
Posts: 537
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Acorn's Second Processors and the Tube - what, and why

Postby kieranhj » Wed Dec 13, 2017 10:51 pm

BigEd wrote:I've added a few more points to the bottom of the head post.

Thanks for the write up BigEd. I have always been fascinated by the Tube architecture - such a unique & forward thinking aspect of Acorn’s design but seemingly forever underused.

As you articulate above, the Tube is a copro not a multi core design. The IO was intended to be essentially text passed back & forth. This means it doesn’t lend itself to real time applications like games particularly well. Elite is the exception that proves the rule, as people keep telling me when I point out the coding challenges...

I desperately want to get stuck into some 6502 copro coding but have to be disciplined and finish my existing big project. At least the 256 byte transfer bug has been fixed in b-em which will help a lot!

As with Elite, I think (3D) maths is the sweet spot for taking advantage of copro power for games rather than any typical fast paced sprite affair. A C&C style RTS or even a turn-based strategy game also come to mind. However, with all of these projects, the real work comes in designing & writing a new 3D vector or sim game in the first place more than figuring out how to get the most out of the copro on the other side of the Tube interface.

At some point I will get round to writing some 3D rendering routines to learn more but trying to do solid triangles, for instance, is always going to be bottlenecked by the speed the host can write to screen memory at 2MHz.

Given that there are many more copros available now, both real and emulated, with MHz to spare maybe there would be mileage in a good higher level language (like C?) implementation to facilitate more rapid development? Graphics are not going to be real time per-se but could build libraries on top of the OS VDU plot routines.

That said, my personal interest would be to see what could be achieved with a vanilla 4Mhz Master Turbo (I’m lucky enough to have one) as existed BITD.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

crj
Posts: 445
Joined: Thu May 02, 2013 4:58 pm

Re: Acorn's Second Processors and the Tube - what, and why

Postby crj » Thu Dec 14, 2017 2:22 am

kieranhj wrote:The IO was intended to be essentially text passed back & forth. This means it doesn’t lend itself to real time applications like games particularly well.

I'm not sure either part of that is really true. By having four FIFOs, the Tube supports a fairly rich set of binary protocols, and filing system operations are at least as significant a use as keyboard input and VDU output. Meanwhile, the IO processor has nothing better to do than listen for commands from the Tube, and the Tube can interrupt the parasite, so latency is minuscule in comparison to screen refresh rates. Also, data can be transferred back and forth at 100Kbytes/sec.

The actual issue is finding a meaningful division of labour between the two CPUs. Most games are graphics-intensive, and plotting code has to reside in the IO processor, along with any sprite data. That leaves little for the second processor to do.

However, if a game were designed from the outset to run on a second processor it could take advantage of this by having (relatively) huge worlds and (relatively) sophisticated AI for opponents.

After all, dividing the workload between CPU and GPU is common practice for modern game designers!

Alas, only a small proportion of Beebs ever had a second processor, and those that did tended not to be in the hands of keen gamers. So Elite is the only game which ever properly took advantage of the opportunity (and even then, my understanding is that the Tube version was coded so as to present players with an unexpected challenge at the first championship, more than as a commercial venture).

User avatar
1024MAK
Posts: 6885
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: Acorn's Second Processors and the Tube - what, and why

Postby 1024MAK » Thu Dec 14, 2017 4:11 am

Nice write up Ed. Although I do need to pick up on a few points.

The Tube hardware in the Beeb is not that special. There are plenty of other computers from the 1980s and 1990s that have equivalent signals available on an expansion port. And if someone wanted to, the Beeb's 1MHz bus could do a similar thing.

What sets the Beeb apart, however, is the separation of the language from the machines OS, and the comprehensive features of the OS (including the support for the Tube).
The second thing that makes the difference, is Acorns concept and actual released products. Which of course contain the Tube ULA.

Other manufacturers went down various different routes. Timex developed the Timex FDD 3000 for example.
Memotech developed the FDX system. Commodore developed the Commodore 128. I'm sure there are other examples of systems with either another CPU, or greatly expanded I/O (where the original CPU was already powerful enough).

I suspect Acorn may have developed the idea about using different processors with the Beeb after developing the 6809 CPU cards for the various Acorn System 2/3/4/5 computers (link).

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

crj
Posts: 445
Joined: Thu May 02, 2013 4:58 pm

Re: Acorn's Second Processors and the Tube - what, and why

Postby crj » Thu Dec 14, 2017 4:20 am

1024MAK wrote:The Tube hardware in the Beeb is not that special. [...]The second thing that makes the difference, is Acorns concept and actual released products. Which of course contain the Tube ULA.


That wasn't emphasised much at the time, but is a big part of the cleverness of the Tube architecture.

In the BBC Micro itself, the only hardware supporting the Tube was some tracks on the circuit board, one output from a 74138 decoder and a 40-way connector. Literally nothing else. The Tube ULA lived in the second processor, so users didn't have to pay for it until they needed it. (As a bonus, they didn't have to perfect the Tube ULA at the same time as all the other stuff they had to think about to get the BBC Micro out the door.)

User avatar
BigEd
Posts: 1548
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: Acorn's Second Processors and the Tube - what, and why

Postby BigEd » Thu Dec 14, 2017 8:51 am

I do recommend following RobC's lead if you'd like to use a high level language to implement something which uses today's extra-fast second processors.

I should have mentioned also, that there were a number of dual-Z80 designs back in the day where one of them handles the floppy drive, and Commodore's floppies also had a 6502 (originally, two 6502s) to handle the floppy drive and to present a filesystem-level facility to the host.

Rich T-W had a nice idea, for a fractal program on the Beeb, to use a second processor, if present, as a maths accelerator. This is the inverse of the usual approach, and means the program executed on the Second Processor needs to load code onto the host and inject it into a vector to run it. (This is, as it happens, known technology.)

User avatar
fordp
Posts: 925
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: Acorn's Second Processors and the Tube - what, and why

Postby fordp » Thu Dec 14, 2017 12:52 pm

1024MAK wrote:Nice write up Ed. Although I do need to pick up on a few points.

The Tube hardware in the Beeb is not that special. There are plenty of other computers from the 1980s and 1990s that have equivalent signals available on an expansion port. And if someone wanted to, the Beeb's 1MHz bus could do a similar thing.

What sets the Beeb apart, however, is the separation of the language from the machines OS, and the comprehensive features of the OS (including the support for the Tube).
The second thing that makes the difference, is Acorns concept and actual released products. Which of course contain the Tube ULA.

Other manufacturers went down various different routes. Timex developed the Timex FDD 3000 for example.
Memotech developed the FDX system. Commodore developed the Commodore 128. I'm sure there are other examples of systems with either another CPU, or greatly expanded I/O (where the original CPU was already powerful enough).

I suspect Acorn may have developed the idea about using different processors with the Beeb after developing the 6809 CPU cards for the various Acorn System 2/3/4/5 computers (link).

Mark

There are you tube videos explaining this better. The machine Acorn was developing (Proton?) was going to have two processors built in with application processor and operating system processor. When they modified the design for the BBC they had to drop the built in second processor to hit the time scales and price points. They also had to add things like Mode 7 and other features the BBC insisted on. This made the BBC but also explains the lack of RAM. The engineers were not willing to drop the second processor idea and hence the tube interface. What is strange in hindsight is why the 1 Mhz bus was not used for the second processor as it would have been easy to hook a tube chip to the 1MHz bus and have a second processor there!
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
Pablos544
Posts: 298
Joined: Tue Jul 15, 2014 4:25 pm
Location: London, UK

Re: Acorn's Second Processors and the Tube - what, and why

Postby Pablos544 » Thu Dec 14, 2017 3:58 pm

Very lovely BigEd :o To people like me this is a real light. Very simple and well understood informational but not boring. Awesome bro =D>

User avatar
kieranhj
Posts: 537
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Acorn's Second Processors and the Tube - what, and why

Postby kieranhj » Fri Dec 15, 2017 5:27 pm

crj wrote:I'm not sure either part of that is really true. By having four FIFOs, the Tube supports a fairly rich set of binary protocols, and filing system operations are at least as significant a use as keyboard input and VDU output.

Yes, that's true they did put in a separate FIFO for all of the expected I/O channels to make it a useable environment.

crj wrote:Meanwhile, the IO processor has nothing better to do than listen for commands from the Tube, and the Tube can interrupt the parasite, so latency is minuscule in comparison to screen refresh rates. Also, data can be transferred back and forth at 100Kbytes/sec.

I guess this is the bit where I find theory and practical application diverge, from my limited experiments to date. Yes, you can transfer 100Kb/s but this maxes out all available cycles on the Host CPU so you're spending all your time LDA'ing from the Tube FIFO and STA'ing somewhere in Host RAM. My only point is that in practice there is a balance that has to be found between Host cycles spent moving data over the Tube and doing something meaningful. We know that shifting large amounts of data around is not the 6502's strongest feature. If we had DMA on the other hand... :D

crj wrote:The actual issue is finding a meaningful division of labour between the two CPUs. Most games are graphics-intensive, and plotting code has to reside in the IO processor, along with any sprite data. That leaves little for the second processor to do.

However, if a game were designed from the outset to run on a second processor it could take advantage of this by having (relatively) huge worlds and (relatively) sophisticated AI for opponents.

Completely agree! I guess my other point was that designing & writing (new) games is difficult enough for most people which is why we've not seen anyone take advantage of modern copros despite their (relative) availability. At least for anything beyond simple demos. It's a big undertaking either way, although I would love to do this as a future project.

crj wrote:After all, dividing the workload between CPU and GPU is common practice for modern game designers!

Indeed. Although I made the point previously that in our case, unfortunately, the balance of power is the wrong way around - we have a (relatively) high powered CPU and a weedy "GPU" (in the form of the original 2MHz Host CPU.) I reckon that even a 200+MHz Pi copro isn't going to be as useful to most gaming scenarios compared with a simple sprite chip (e.g. VIC or NES PPU.)

crj wrote:Alas, only a small proportion of Beebs ever had a second processor, and those that did tended not to be in the hands of keen gamers. So Elite is the only game which ever properly took advantage of the opportunity (and even then, my understanding is that the Tube version was coded so as to present players with an unexpected challenge at the first championship, more than as a commercial venture).

Absolutely. My guess is that Elite was almost accidentally designed in such a way that made it relatively easy to create a 2nd processor version based on the line rendering routines and they would have done this at Acorn's behest to showcase the hardware, rather than it being in any way commercial, as you say.

My final slightly tongue-in-cheek point is that since joining Stardot I've seen at least three new threads of "where is all the 2nd processor software?" So my conclusion is perhaps "it's harder than it looks".
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

crj
Posts: 445
Joined: Thu May 02, 2013 4:58 pm

Re: Acorn's Second Processors and the Tube - what, and why

Postby crj » Fri Dec 15, 2017 6:53 pm

kieranhj wrote:Completely agree! I guess my other point was that designing & writing (new) games is difficult enough for most people which is why we've not seen anyone take advantage of modern copros despite their (relative) availability. At least for anything beyond simple demos. It's a big undertaking either way, although I would love to do this as a future project.


That kind of thing is, of course, an amusing project in itself. But, like the idea of a blitter for the BBC Micro, I'm not sure it serves any wider purpose. If you have a Raspberry Pi and just want to play a fun game of modern design, you're better off running something on the Pi natively, or on a self-contained emulator, rather than using it as a Beeb second processor. If you're wanting to retain retrocomputing authenticity then you can't really use a gigahertz of ARM that's been bolted on the side, since nothing of the kind could ever have existed back in the day.

It would be really interesting to see a few more games for the 6502 second processor, though!

Absolutely. My guess is that Elite was almost accidentally designed in such a way that made it relatively easy to create a 2nd processor version based on the line rendering routines and they would have done this at Acorn's behest to showcase the hardware, rather than it being in any way commercial, as you say.

I don't know what the division of labour is, but I'm assuming the low-level rendering primitives run on the host, while the 3D geometry engine and hidden line removal is on the parasite. The key there is that the volume of data that has to flow between the two components is small compared with the work each component has to do.

If I were trying to achieve the same for a more traditional game, I'd want to put the sprites in the host processor, but the logic for how to render them in the second processor. Each frame, I'd have the parasite work out what needed rendering where, Y-axis sort, notice overlaps, map the memory needed for save-unders, and build a list of what sprite fragments to render where, in what order.

My final slightly tongue-in-cheek point is that since joining Stardot I've seen at least three new threads of "where is all the 2nd processor software?" So my conclusion is perhaps "it's harder than it looks".

Where are all the 2nd-processor games, perhaps. I've used tons of software on the second processor over the years: the school's Level 2 Fileserver before it got an SJ Rsearch one, HiWordWise+ for my first paying gig, HiBasic for assembling 16K ROM images, HiView for word-processing my A-level Computing project, etc.


Return to “hardware”

Who is online

Users browsing this forum: No registered users and 3 guests