BBC Micro computer - https://upload.wikimedia.org/wikipedia/commons/3/32/BBC_Micro_Front_Restored.jpg

One weekend when Herman was ringing us around, saying the BBC are coming on Friday. Can we show them a working prototype? And we hadn't built anything at that point. In fact, we just had paper sketches which had not been really detailed to the accuracy required to build them. At the telephone session, first he rang Roger who said don't be daft, and then he rang me, saying Roger thinks we can do it. So, what if Roger thinks we can.

You've been working for them ad hoc, would you say, or just kind of working for them, but it's sort of moonlighting? Moonlighting. Yeah. A bit of extra work. I was on a PhD grant from the Science Research Council's... no, Science and Engineering Research Council. It was SIRC then. And you know, that didn't allow me to do paid work. So basically the deal was I designed things, gave them the designs, and they gave me more bits to go and design other things with. So it was a sort of in-kind fueling of a hobby. It got a bit out of control in the BBC prototyping week when my part-time involvement was three days and two nights continuous. 

I think the progression towards the BBC Micro had a number of steps in it. The first one, which I had relatively little to do with, was the development of the Acorn Atom. We said the Atom is very nice. It's going well, but we need to think about its successor. That was Acorn's position. It had got the atom in the market when it heard about the BBC's interest in uh developing a series of programs for which they wanted a specific machine and for which they'd been talking to Newbury about their new brain for quite a long time. I'd been involved in sketching out an architecture that was internally known as the proton, and the thinking there was we can see the transition is going to be made from the 8-bit microprocessors in the atom to 16-bit microprocessors. It's a big transition. We're not quite sure the best way to make it. We've got a lot of investment in 8-bit code. How can we exploit that investment whilst getting into the 16-bit market? 

And so what we had sketched on the table was that it was effectively a dual processor system um where the main processor was the new 16-bit as yet unspecified but all the IO work all the real-time work was done by a 6502 in very much the way we've done it on the Atom.  When we heard about the BBC's interests and and and understood what they were looking for, then this machine was sort of pulled off the drawing board, and given the cost point they were aiming at it was clear that you know what we had to do was take the second processor off the standard machine.  We kept it on as a potential upgrade, which turned out to be actually very useful. But the front end of the proton is the thing that through a little bit of rework became the BBC Micro. The BBC had some very competent people in their research department thinking about well in particular of course what they wanted to use this machine to illustrate on the program. 

There's a very important educational element of learning how to program these computers. First of all, it's fun and people enjoy it. So the machine had to do a set of things that uh would feature in the program but they also were quite particular about the programming language and BBC basic emerged as a compromise between you know Roger's experience of building basics for earlier machines and the BBC's requirement for a language which was really rather nicer and cleaner than a standard basic. In terms of hardware, the BBC Micro was quite recognizable as the Proton. There were some features added that the BBC wanted that weren't in the original Proton spec. So, for instance, the Teletext mode was not there in the Proton. Things such as speech generation. As an optional upgrade to your BBC Micro, you could plug in a couple of linear predictive coding speech chips that would give you a reasonably faithful reproduction of Kenneth Kendall, I think, was was the the voice that was captured for for that particular piece of hardware. I must thank computer files. And the BBC um also had some fairly interesting ideas about peripherals. So they came into this discussion thinking what they wanted was a Z80 running CPM and what we offered them was a 6502 running a proprietary operating system but we also offered them the option of adding the Z80 as a second processor running CPM so we could kind of deliver on their requirement at considerable extra cost. 

A lot of the good features for the BBC Micro were a result of a very constructive dialogue between the BBC and Acorn. It was a creative tension. I mean, it wasn't always easy. We didn't like everything they they wanted, but they they were they were willing to negotiate. Um as were we. Uh so nobody went into this being unreasonable about it. They were on the hardware side, for example, one of the things that they were quite firm about early on was that they didn't want it the machine to have a switch mode power supply. Switch mode power supplies operate at radio frequencies. They thought the radio spectrum was their territory. They didn't like equipment that created interference in in their spectrum. And so the first BBC Micros that we sold had linear power supplies. This turned out to be a very bad idea because of the physical size constraints in the case. Building a linear supply to fit in the available space was essentially impossible. I mean, we had two idle transformers and we made them as efficient as possible, but they still overheated and occasionally caught fire. But it was only after we'd been in production for a few months, we went back to the BBC and said, "Look, we really can't get this supply to work with the reliability we need. You know, let's go and look at a switch supply." And and and we got a a switch supply that fitted in the same form factor designed by Aztec in Hong Kong. 

A couple of years ago, I went to a retro computer meeting near Huddersfield and I went I went into a room with more BBC micros than I'd seen in a single room for a very long time. And I asking the people what they needed to do to keep the micros running. And basically the answer was you have to replace the capacitors in the power supply, but everything else still works. The capacitors in these Aztec switch mode supplies dried out after 30 years. I thought that was a reasonable reliability record. Yes, the design was quite aggressive, it was based on the machine I built at home. So, one of the key principles was that there was a single block of memory and the processor and the display system shared access to this. I'd had this running at home with a 2 MHz memory with one MHz for the processor and one for the display. That was a year before. Now, it was time to double that. So the goal was 4 MHz with 2 MHz for a 2 MHz 6502, which of course was twice the speed of the Apple 2, and 2 MHz of display which allowed us to get the 640 pixels across the display line. But that meant 4 MHz memory and that was quite aggressive indeed. 

We got I think the first ever 16 megabit Hitachi DRAMs that were single rail. So they only needed a 5V power supply instead of having +5 and +12 and these were the first ones that were actually fast enough to do what we wanted. If we could do that then it gave us some very nice performance features. We also pushed the technology in the BBC Micro in using ULAs to integrate systems. Now that was a development from the Proton design that came when we looked at: the size of the machine and how much space we had for chips. One of the things that made me nervous about the BBC Micro is that is that to run this memory at 4 MHz um we had to multiplex some bits of address into the row address of the memory and some into the column. And the chip we used for that was the National Semi-conductor 81 LS95. Okay, the numbers engraved in my brain. This is quite a simple chip. It was a multiplexer with a tri-state output. And many other suppliers came along and said, you know, we've got a chip that's an exact replacement for that. Why don't you buy our chip? And we put these chips in the BBC Micro, and none of them worked. And we never knew why, which of course means that we didn't know why the National Semiconductor One did work, right? And a million and a half BBC Micros later, it was still working. And I still didn't know why. But in volume manufacturer that's the kind of thing you worry about. The other memorable feature of the BBC Micro is that the poor 6502's data bus was seriously overloaded. There were so many peripherals on the machine that if you worked out how much capacitance it was driving, it was way out of spec. And when we built the first PCB prototype, it didn't work. And we discovered and this is not unusual in this electronics. If you put your finger in a certain place on the board, it started working earthing it or something. Well, it's just sort of damping oscillations or something. Who knows what it's doing. Anyway, I didn't have enough fingers to stick one on each of the micros we were going to build but there is a little resistor pack across the data bus with with eight resistors pulling the eight data lines up I think which is the engineer's finger and again we've no idea why it's necessary but a million and a half machines later it was still working so nobody asked any questions when I compare the standards to which we engineer things today um the the control we have over all these aspects um then I'm still astonished that the BBC Micro established this reputation for being reliable because a lot of it was finger in the air engineering and tweaking it until it worked or perhaps Victorian overengineering in a lot of respects possibly.

Oh, it was not overengineered. If you took a BBC Micro up to about 35 degrees, it would die. It was not a good machine for the Australian desert, as we discovered. Whereas when we built the first machine where we'd really got a much better grip on the engineering, we were testing that in a heat chamber and we could run it so hot that we actually had to make a little hole to get the floppy disc outside otherwise it would melt. Okay, the arms the arm system in the first Archimedes would run reliably well above 100° C. So we'd really got the engineering under control at that point and because all the components you're using have a tolerance, they all you know their their spec moves up and down depending on which one you pull out of the bag when. So building machines that that work reliably does require that you have margin and the margins on the be were very very small and I remember a group of people meeting in my house in Cambridge. Somebody called Roger Wilson that I got to know a little bit through the processor group poking around in my machine and finding a bug um in the memory. That was the first time Roger found a bug in my hardware. It was definitely not the last time.