On the Beeb's inception:
So when the BBC came round looking for a machine, their initial spec was a Z80 running CPM, okay. Now what Acorn offered them was a 6502 running a proprietary operating system. But it said, this is the front end of a two processor machine and, you know, we’re selling the front end as the main machine to keep the costs down but we can add a Z80 running CPM later through our second processor port, which of course we did. The Z80 running CPM did come. But that was Acorn’s strong interest in putting this tube port on for second processors, because that’s how the machine had originally been conceived before the BBC even turned up.
basically I took the Proton ideas and formed a circuit, which was then – Ram [Banerjee] assembled and then with Sophie we debugged and got working. So I’m guessing that I was – you know, I had a lot to do on the first day, just getting the circuit diagram into shape, then probably not much to do for the next couple of days while the wire wrapping was completed. That was sort of by Wednesday, I think, and then Wednesday night, Thursday, Thursday night to Friday morning was probably just continuous – trying to get some life into this thing and wondering why it didn’t work. And the techniques we had for debugging were fairly basic. We’d certainly have access to oscilloscopes of some sort. But I think we did a lot of debugging with things that were called logic analysers – logic pens, not logic analysers. Sorry, that’s a mistake. We didn’t have logic analysers. Logic probes, that’s the right phrase. And these were things that you held like a pen and they had a metal tip which was the contact and two LEDs and if you touched a digital signal, if it was logic low the green light would light up and if it was logic one the red light would light up, or possibly the other way round. I don’t remember. And they also had various ways of detecting pulsing signals. So you could – you know, if you’d got the machine into a sort of stable state where it was stopped, you could then go and read all the logic signals off one at a time.
On the Beeb's circuit design:
The other interesting point of course is that the [Beeb] had some extremely marginal design features, some of which were evident when it went on sale and some of which we’d got away with in a way that still staggers me. They never bit us. One of the ones for which I was primarily responsible was the way I described the memory worked. It had this multiplexed access and this used chips from a National Semiconductor called 81NS95s and they drove the signals onto the memory and selected where those signals came from so that you could switch between processor and display. And we had any number of people come and offer us second sources for those chips. So in other words – it was desirable, if you used a chip, to have more than one place you can buy from, otherwise the supplier has you over a barrel. And all these second sources had identical specs and none of them ever worked and we had no idea why. So that frightened me quite a lot.
On the Beeb's PSU:
for the first machines the BBC insisted that we used linear supplies as opposed to switching supplies. Linear supplies are inevitably lossy. I mean, they get quite hot, they’re inefficient. There’s losses in the supply as well as – in fact, roughly speaking you dissipate as much power in the supply as you do in the board you’re supplying with a linear supply. And there really wasn’t the space in the box to cope with that much dissipation and we had a lot of trouble with the linear supplies, actually on a couple of occasions catching fire, not to beat about the bush. It was a sufficient problem that – and the reason the BBC were very keen on linear supplies was switching supplies switch at radio frequencies and the BBC owned the radio spectrum and didn’t like things interfering in its spectrum. I think that was the policy. Anyway, after a few months struggling with these linear supplies the BBC was persuaded to allow us to try a switch-mode supply and we got Aztech in Hong Kong to – I wasn’t directly involved in this, by the way. This is a neighbouring story, but Aztech designed a switching supply for us and we built the switching supply in and never had any trouble again. And I do remember at one time, I don’t know where it is now, I had possession of the millionth Aztech switch supply, which they gold plated for us, and it’s a great shame I don’t know where it is now.
On the second processor:
And yeah, so the ARM was designed on a BBC Micro, probably with the same processor, you know, a 6502 second processor to add a bit of poke to it. I was responsible for the 6502 second processor, which gave, you know, a useful doubling of memory capacity and performance. And my first real experience of synchronisation failure, but that’s a technical detail we probably don’t have time to go into.
On the Electron ULA:
Yes, the previous big ULA design I’d done, I’d done – well, I didn’t actually do the video processor and serial processor. I was responsible for their content but I wasn’t involved in the design. The next ULA we did was the tube ULA, which was the BBC Micro second processor interface, and I – I basically did most of that physical design with a sort of square yard of translucent paper on a glass office wall, which I drew on by hand and that was how the design was done physically. For the Electron, the glass wall would have been too big, you know, and therefore we devised a tool that run on the BBC Micro that allowed you to design it by hand and extract the design details from there.
So all you’re designing is this one layer of metal. And you’ve decided which transistors you’re going to use for which logic gate and then you’ve got to wire the logic gates together. And of course the decision about which transistors make which logic gate is one you can change, right. So you guess a sensible arrangement, you try to wire it to see if it works. You find that some place gets far too congested, that it’s never going to wire and then you change your initial guess a bit in the light of this experience and iterate until you can actually make all the connections you need for the logic you’re trying to implement. And yeah, it’s rather open ended. And there was one corner of the Electron that was very tight indeed, took a long time to get all the knitting to resolve properly.
On the memory controller for the Archimedes:
At that time [in the development of the Archimedes] people were beginning to adopt fairly complex memory controllers. These were things that did memory address translation through two layers of tables and they produced quite complex hardware. And I thought about this and decided I could find a much – a much simpler way of doing this. If I sort of inverted the problem and used a small content addressable memory to store translations then the logic for the memory control would be much simpler. But this seemed a bit of a radical change. I mean, why wasn’t everybody else doing it? So I remember Hermann suggested I should go and talk to David Wheeler, who was one of the grand old men of the computer laboratory, one of the pioneers of the computer lab. And I remember going to see David Wheeler and describing my radical new idea for building a memory controller for these ARM systems and David Wheeler listened patiently. I said what I was planning to do and I said, ‘Do you think this’ll work?’ And he thought for a bit very quietly and he said, ‘Well,’ he said, ‘it seemed to work in Manchester in 1962 so I don’t see why it shouldn’t still work today.’ And unbeknown to me, I’d effectively just reinvented the very first memory management hardware that was developed for the Manchester Atlas machine, which again was based on associative memories. And that memory controller, with its content addressable memory translation system, with the video controller, the IO controlled and the ARM, formed the basis of the Archimedes product range.
On the invention of ARM:
So in other words, the performance of the computer is largely unrelated to the instruction set architecture. It’s just how fast it can shuffle programmes and data around. And we’d done some quite detailed measurements of this. So Sophie had written basic interpreters to run on the 32016. We’d looked at these, we’d measured the bandwidth, we’d measured the performance and it all seemed to scale quite nicely. Now memory bandwidth was probably the most expensive commodity you paid for when you bought a computer in those days. And it was defined by the memory, not the processor, okay. So if you paid for commodity DRAM, which was the standard big memory in the BBC Micro and pretty much everything else, you got a certain amount of bandwidth. And the thing that frustrated us about the 16032, 68K, 286, was they couldn’t even use the bandwidth the memory had. They couldn’t keep up with the memory. They were wasting performance by not being able to make full use of the memory’s capabilities and that just felt wrong.
On the prospect of creating a new CPU architecture:
And we were toying with this idea that, you know, maybe the commercial microprocessors that we could buy aren’t – you know, we don’t like them, you know, should we design our own. And the great disincentive was that, although Berkeley had built a processor with a graduate class in a year, the people who’d built these things commercially had huge teams and spent vast amounts of money. We’d been out to Israel to visit National Semiconductor’s design centre there and the 16032 team were on Rev H of the 16032. They started at Rev A, B, C, D. So, you know, they’d clearly got it wrong several times. And they were still debugging this thing ‘cause it was so complex and they had huge teams that were way beyond Acorn’s means. And we debated ideas for instruction sets. Hermann encouraged this. But I think the final – if you like, the real turning point was when Sophie and I went on a mission to Phoenix Arizona for a completely different purpose. We – as an interim we were interested in extending the 6502’s address space. The sixteen bit address space had become far too cramped. It was a bit small even for the Beeb but it was now getting silly. And out in Phoenix Arizona a company was designing the 65C816, which was an extension to the 6502 that pushed its addressability up to twenty-four bits. And Sophie and I had gone out to Phoenix expecting to find, you know, large shiny American offices. Instead we discovered that the Western Design Centre that was doing this design work was actually operating out of a bungalow in the suburbs of Phoenix. And we visited this bungalow and talked to these people and they got vac students on Apple 2s designing little bits of physical layout. They’d got some big machines, but basically it wasn’t the shiny office block, it was quite a sort of cottage industry type of design centre. And we very definitely came away from that visit, you know, with the information we needed for the 65C816 and so on, but most importantly with the idea that, well, if they can design a microprocessor maybe we can, right.
Steve has quite a few interviews on record, with a lot of overlap, but this is by far the longest. It's a British Library oral history:
http://sounds.bl.uk/related-content/TRA ... 0000A0.pdf