There's been a lot of discussion recently about the Raspberry Pi. Admittedly, more near me than elsewhere, as it's designed two floors up from me in Cambridge, but still quite a lot in the mainstream press. The Raspberry Pi comes in two models, A and B, reminiscent of an earlier machine, which was the inspiration of the project.
The BBC Model B was a computer that anyone who went to school in the UK in the '80s will remember (perhaps fondly, perhaps not). It undoubtedly had a large impact on computing in the UK, but was largely a UK-only phenomenon. In this article, I'll take a look at what made the machine interesting and why it mattered.
The whole story starts with a government project. At the start of the microcomputer revolution, the British government displayed a rare amount of insight and realized that these "computer" things that everyone was talking about might actually be important and that a workforce full of people who understood them would be beneficial in the future. Unfortunately, there was a problem: Most schools had neither computers nor teachers that understood them.
The lack of teachers is still a problem, but back then there were few people with a reasonable amount of computing experience in the world, so the potential pool was significantly smaller. The lack of computers is seemingly easy to fix: just buy some. This is the typical approach to computing in schools: Just throw money and hardware at the problem (the money typically taken away from other parts of the budget) and then express shock that it didn't provide any noticeable benefits.
Again, the government displayed an uncommon amount of common sense (at this point, it had used up its quota of good decisions for the decade) and imposed a set of strict conditions on the kind of computer that schools could buy. If it bought computers that met these requirements, then the government would pay half of the cost from a pot of money that was distinct from the school's normal budget.
Some of these requirements were fairly mundane hardware-related things (e.g., a minimum amount of RAM, 32KB, I believe), but the most important was that they must include a programming environment that supported structured programming.
A Not-So-Basic BASIC
When you turn on a BBC Micro, you get a prompt, into which you can type BASIC code. The first thing that most schoolchildren learned to do on these machines was something like this:
10 PRINT "Hello!" 20 GOTO 10 RUN
This would infinite loop printing hello. Or, in the most common variants, something less polite. This is typical of flow control in most dialects of BASIC and mirrors how assembly languages handle flow control. The line numbers are roughly analogous to addresses and GOTO to an unconditional jump. BBC BASIC was one of the earliest widely distributed versions to also provide a GOSUB statement. This jumped to a specified line number (or label), just like GOTO, but it also pushed the current line number onto a call stack. The subroutine could then return to the place where it was called.
This addition made it possible to write quite complex programs in BBC BASIC without it becoming spaghetti code. It wasn't the only interesting feature of BBC BASIC, though. It also had an integrated assembler. This could assemble a string provided from BASIC code, so it was possible to write compilers in BBC BASIC that would generate native code.
Graphics and Sound
The BBC had a reasonable range of drawing modes as well as text, but it also contained a teletext display mode. Teletext adoption varied throughout the world, but in the UK it was very popular as a source of news and other information. With the teletext chip, you could create displays that looked just like the teletext displays that the various TV channels broadcast. My school did this for a little while, providing a noticeboard on a big TV that children and teachers could put announcements on.
The sound support was also quite impressive for the time, with the sound chip able to produce polyphonic beeps and containing a white noise generator. I remember programming the noise generator to approximate the sound of waves breaking. On a modern machine, of course, this sort of thing can be done entirely in software. Even generating waveforms at 48kHz is a trivial load on a modern CPU. Back then, however, being able to make tinny electronic music (which was very much the fashion—for the time, anyway) seemed very exciting.
One of the most impressive things about the BBC was the range of (memory mapped) I/O functionality. For example, it had a 16-pin user port, with 8 input and 8 output pins. You could read and write these from BASIC with the PEEK and POKE commands, getting back a byte with one bit indicating the state of each of the pins. There was also an analog input port, with an analog-to-digital converter so that you could read analog values. A number of games used this port, but it was also useful for various kinds of sensors.
A lot of technology classrooms kept BBCs around for a long time after they stopped being state of the art for exactly this reason. They were easy to connect up to home electronics projects. This is something that modern PCs lacked.
Even RS-232 was comparatively difficult to use, and USB was much harder. Things like the Aurdino range bring some of this back, and the Raspberry Pi has a set of general purpose I/O (GPIO) pins, although it lacks the analog input.
Some of the teaching equipment made use of this as well. A lot of people in the UK remember learning basic geometry with the aid of Logo and a turtle. Logo is a Scheme-inspired language with a set of built-in operations for driving a turtle—a device that understands turn commands, can move forward and backward, and draws with a pen. In software, you had a turtle represented by a sprite on the screen, but a lot of schools also had physical ones that connected to the BBC via a long ribbon cable and could draw shapes on large pieces of paper.
I look forward to a Raspberry Pi version of Logo that dispenses with the ribbon cable and embeds the computer directly in the turtle.
The BBC Micro solved the hardware part of the problem, but that still left the teaching problem. This is where the BBC in the name came from. The British Broadcasting Corporation did not make the computers, Acorn did. It did, however, produce and broadcast a series of programs describing how to use and program them. It also reserved some teletext pages for transmitting BBC BASIC programs. You could buy a teletext decoder for the BBC and convert broadcast teletext pages to text that it could then save to disk or tape. Schools could "download" the example code as they recorded the example lessons.
This is the part that was really missing from the initial launch of the Raspberry Pi. The hardware, by itself, is the easy part of the problem. The teaching resources are the hard part. It takes a lot of effort to assemble a detailed set of teaching material for schools. This is where the BBC part of the partnership worked very well the first time around.
Fortunately, today the computing landscape is not like the '80s. Back then, very few universities offered computer science, and most of the ones that did regarded it as math or engineering with a few minor tweaks. There was no Internet, and teaching computing to children was a fairly novel idea. Now, there are a lot of existing resources and a lot of work is underway to ensure that they work well on the Pi.
The one that I am most interested in is the effort to make the Squeak VM for Smalltalk run well on the system. While I approve in general of more people learning Smalltalk, the real point of this is to allow eToys and Scratch to work on the system. These are both rich development environments aimed at teaching good object-oriented (and parallel) programming to young children. As with anything else in Smalltalk, they support introspection at all levels, so it's trivial to inspect a running program, see the values of all objects, modify them on the fly, and continue without an explicit recompilation-restart cycle.
This works on the Pi currently, but it's quite slow. Squeak, unfortunately, inherits a lot of the design of the original Smalltalk-80 system. This, in turn, adopts a lot of implicit design decisions from the Xerox Alto. In particular, the display is treated as a frame buffer (although, unlike the Alto, the pixels can have more colors than just black or white), and all the high-level operations are built on top of a bit blt operation, which was microcoded on the Alto and is a short sequence of assembly on modern systems. Unfortunately, this is a very inefficient way of driving a modern display, which has hardware specifically designed for things like compositing. There's work underway to improve this, but it's not ready yet.
There's also a team that's added support for the GPIO pins to Squeak. This is probably the most exciting part for me, although it's a very small change from a technical perspective. Programming in BASIC or Logo on the BBC Micro was fun, but the real excitement for me as a child came from plugging the computer into other devices—turtles, robot arms, even simple things like 7-segment LED displays—and driving them from the computer. In an age where everything has a CPU orders of magnitude more powerful than the BBC, and often considerably more powerful than the Pi, being able to control other machines is still exciting.
The BBC had no Internet to support it, but it was the focus of a lot of books, including a number about hardware design. The platform was a de-facto standard for most of the '80s in British schools, making it very easy for third parties to create things that plugged into it or books about it and expect to be able to sell them to a lot of schools.
The PC platform that gradually replaced it in the '90s was never quite so uniform and had the disadvantage of also being used heavily in industry, meaning that there was a strong temptation to target teaching material toward a more general audience, rather than toward schools.
A One-Off Event?
The BBC Micro had a huge impact on the computing landscape in the UK. Unfortunately, the subsequent Acorn machines, in spite of being technically impressive (32-bit RISC systems with a multitasking GUI competing with 16-bit x86 machines running DOS) never had the same following. They never achieved the same combination of easily expandable, capable, hardware with a surrounding ecosystem for teaching and government backing.
The current government seems to have decided that programming is the new Latin, and so must be taught in schools. There's even a chance that they might come up with a reasonable plan to make this possible that extends beyond the traditional approach of throwing relatively small amounts of money at the problem and then blaming the teachers when it doesn't work. I certainly hope to see something similar for the people coming through the schools in the next decade. The influx of Windows into schools produced a generation of students who had experience with business machines, but never experienced the more generally useful lessons that a good computing curriculum should provide.