Some interesting Steve Furber observations

on-topic Acorn-related news and discussions not covered by the other forums
User avatar
BigEd
Posts: 1397
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Some interesting Steve Furber observations

Postby BigEd » Sat Oct 01, 2016 1:22 pm

I've been reading through a (very long) transcript, and to save you a few hours reading, have some (long) snippets to share. Here's Steve Furber:

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

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

Re: Some interesting Steve Furber observations

Postby 1024MAK » Sat Oct 01, 2016 2:52 pm

Thanks Ed :D

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

VincentVega
Posts: 212
Joined: Thu Sep 11, 2008 9:19 pm

Re: Some interesting Steve Furber observations

Postby VincentVega » Sat Oct 01, 2016 2:59 pm

Fascinating stuff, thanks for posting.

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

Re: Some interesting Steve Furber observations

Postby BigEd » Sat Oct 01, 2016 5:59 pm

A second (and final!) instalment as I come to the end of the transcript...

Steve Furber on the ARM3:
So we did continue with chip developments. We developed ARM3, which was effectively putting ARM2 onto – I think it was a one or one and a half micron process, which left enough space to put a cache around it. So that was the first ARM processor that had a cache memory, so it stores frequently used things locally on chip. And that was hugely advantageous for the Archimedes because the – although in principle the cache allowed us to push the clock up to twenty megahertz and go two and a half times as fast, in practice the Archimedes processor was sharing memory bandwidth with the graphics. The cache reduced its bandwidth requirements, so in practice Archimedes machines with ARM3 went about four or five times as fast as the ARM2 based machines. So we got a huge win out of ARM3.


On the limited market for Archimedes:
Even the education market was beginning to move to PC compatibles by the late ‘80s. So the Archimedes was a reasonably successful product for Acorn but it certainly didn’t take the world by storm. Its market was predominantly UK. And it sold I guess in the region of 50,000 machines a year, which was quite a respectable business for Acorn. But you would have expected a machine with the Archimedes’ capabilities, so far ahead of the competition at the time, in a different environment would have done a lot better.


On the spun-out company ARM's business model:
VLSI Technology was also a small scale investor in contributing the tools but their principal owners were Apple and Acorn. And both Apple and Acorn wanted chips with ARM processors in and so ARM was kept very busy supplying those two owners with what they wanted. And I remember having discussions with Robin where he was saying, you know, the biggest problem he had was getting out from under these two very heavyweight owners, who were quite demanding and seemed to expect 100 percent of ARM’s attention, and if he was ever going to make this a viable business he had to expand beyond that market. But it was Robin who I think originally came up with the change. I said our business plans didn’t look good. Robin came up with this idea that in addition to having a downstream royalty, that customers should pay an upfront licence fee. Effectively they should pay to join the club upfront. And these licence fees started fairly large and got very large, so the cost of joining the ARM club is quite high. And of course that’s wonderful for cash flow because that’s a big chunk of money right upfront.


On the Beeb's video ULA:
And we used a couple of these ULAs on the BBC Micro. They were known as the vidproc and the serproc, which stood for the video processor and the serial processor. The video processor was the thing that had the colour lookup tables and was used to define the colour of pixels on the display. And that had to operate at sixteen megahertz in the fastest display mode and that’s where it struggled. It was fine at eight but at sixteen it got a bit noisy and it – the computer lab had actually done the metallisation design for us using tools they’d developed and they’d actually implemented a very early form of wave pipelining in this colour table lookup. But the real problem with the video processor was the fact that these logic gates changed speeds spectacularly between when they were first switched on and when they got to temperature. And their operating temperature was quite hot. But basically the logic gate delay would change by a factor of two between room temperature and operating and the wave pipeline approach was not able to accommodate that much variability.


As a bit of light relief, a tale from his youth:
I was very interested, particularly in my teens, in model aircraft. Flying has been a sort of fairly persistent interest of mine. And so I built model aircraft and then I got into simple radio control and with a bit of help from my physics teacher I turned my single channel radio control into a proportional control of sorts that never really worked. I was never very good at model aircraft so the most important piece of equipment was the supermarket carrier bag to carry the bits home in afterwards.


On his first computer:
And I started buying chips by mail order from California and hand assembling machines, which I’ve still got, using Verowire, which was a technology where you got a standard circuit board and you put sockets in it. Then you had a wiring pen and you wrapped them round the pins of these sockets. It wasn’t proper wire wrap, which requires long square precision pins. It was very thin copper wire with some kind of polyurethane insulation on it. And when you soldered it, it melted the insulation. So you soldered the connection. Apparently the fumes it gave off were highly carcinogenic but this wasn’t declared at the time. And then you just wrapped – you know, with this wiring pen you wrapped the wires around combs that were stuck onto the board carrying the wires and then when you got to where you wanted to go you wrapped it round the pin again and soldered it. And you could hand assemble circuits of reasonable complexity for the day this way, because effectively you got as many layers of wiring as you wanted. These wires could be bundled through these combs and the insulation meant they didn’t short circuit. So I built a whole range of cards. I used a Signetics 2650 microprocessor, which nobody’s ever heard of, a kilobyte of static RAM chips, put all these things on separate cards and got them up and working with help from friends in the University Processor Group. So it started as a hobby...


On bootstrapping this ROMless machine:
Now my first machine was a bit more primitive than that in that I didn’t have that kind of ROM. What I built was a – I just had a microprocessor connected to RAM and a mechanism for actually loading bits into the RAM before the processor started running based on a row of switches on the front panel. So you would set up the switches that you wanted and then you’d push a button and that would write those eight bits into one memory location. And it was very sophisticated because it would then auto increment the address, so all you had to do was set up the eight switches again and you could enter software one byte at a time – and then you could run it and it would have a seven segment display connected as a peripheral. So one program you’d have to enter is how to generate the output on the display and then you could put other things in. And then gradually you built up from there. So, you know, I built an interface that would allow the computer to – once I’d enter a program I could then save it to cassette tape. Audio cassette tape was used as computer storage then, storing noughts and ones as different frequencies, little squeaks on the tape. And then you could load it back in so you didn’t have to type in the whole program every time. And then I built another card, which would blow the program into an EPROM, which was a programmable ROM chip. So then that bit of code was permanently in the machine. And so on. And all of these things required wiring cards together and understanding the basic interfaces, which are not that complicated.


So the machine that was the prototype for the Proton was actually used as a data logging machine for some of my aerodynamics experiments and I also wrote my PhD thesis on it, having first written an editor to write the thesis on.


On his current research work:
But actually the brain is – you know, it’s human size. You could hold it in your hands and sit and look at it. And there’s this human sized thing that we all depend on and we still fundamentally don’t know how it works. So it seems to me that this is at least as important a scientific quest as Higgs Bosons or the origins of the universe. It’s how do we humans work.


So I started this project to see if we could build a machine specially tuned to this problem. It uses lots of asynchronous logic technology in its implementation. We’re putting a million ARM processors in a single machine. And with a million ARM cores, a million mobile phone processors, you can model about one percent of the human brain, or ten whole mice [laughs].


So if you look at the circuit board, basically what you see is a circuit board about the size of an A4 sheet of paper with forty-eight identical packages on, all with nice little SpiNNaker logos, and a few other chips around the side that keep the thing going. That’s what it looks like. And these would be mounted in racks that’ll be in cabinets in the machine room and the full million processor machine will occupy about ten machine room cabinets. So it’s quite a big machine.


As we continue to shrink transistors, they do get less predictable, less reliable. And, you know, the brain is very good at coping with component failure. Through adult life you lose an average of about a neuron a second and yet the brain keeps working because the neuron a second is no problem. It’s only one or two percent over the useful life of your brain. If you start losing twenty or thirty percent you have a problem, right, that’s serious, but one or two percent is fine. We have no idea how to build computers that will keep working if one or two percent of the transistors fail.


On the Pi (after comments about education):
You know, Raspberry Pi has emerged in a very timely fashion and generated lots of excitement, which is really great because it’s – the Raspberry Pi buzz is kind of the first time I felt an echo of the buzz that the BBC Micro generated in the early ‘80s. And there’s no doubt that the BBC Micro basically encouraged a generation to go into computing, to look at computer programming. Any number of people still say, you know, the BBC Micro set the direction of my career. If Raspberry Pi can do the same again then it would be great.


On the Beeb, looking back:
Well, I think – my impression is that it’s remembered very fondly and very positively. And I think – it’s easy to forget that it emerged in an environment where there were lots and lots of alternatives. And of course, in some sense in terms of home computing, Sinclair had certainly a bigger market, a greater penetration. But it’s still the case that people who wanted to program didn’t find the Sinclair products anything like as good a platform as the BBC Micro. So in terms of introducing computers into schools, the Beeb was extremely robust. It would take ten years of hammering by kids, because the keyboard was seriously over engineered, but also it was a very programmable machine. You could do – control things with it easily, you could do all sorts of stuff easily. And it really did seem to bring a lot of people into the subject in a very timely way.

Commie_User
Posts: 872
Joined: Wed Jan 27, 2016 12:50 am

Re: Some interesting Steve Furber observations

Postby Commie_User » Sun Oct 02, 2016 12:18 am

So that's why, for me, the power supply seems peculiar.

It seems ever so brittle compared to the plastic-encased, thumping blocks of invincibility I perceived for other micros.

But overall, for a micro so sturdy on the outside, the BBC was ever so delicate everywhere inside.

User avatar
dgrubb
Posts: 133
Joined: Thu Jun 02, 2016 8:36 pm

Re: Some interesting Steve Furber observations

Postby dgrubb » Sun Oct 02, 2016 12:45 am

Terrific amount of rich detail. Thanks for sharing.

Commie_User
Posts: 872
Joined: Wed Jan 27, 2016 12:50 am

Re: Some interesting Steve Furber observations

Postby Commie_User » Sun Oct 02, 2016 12:48 am

I second that.

User avatar
daveejhitchins
Posts: 3631
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham

Re: Some interesting Steve Furber observations

Postby daveejhitchins » Sun Oct 02, 2016 8:10 am

@BigEd - Thanks, very interesting =D>

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

User avatar
tricky
Posts: 1823
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Some interesting Steve Furber observations

Postby tricky » Sun Oct 02, 2016 9:05 am

Thanks BigEd,
I'd heard him say most of those bits, but it's great to get them all in one place, it really helps to put them in context.

User avatar
davidb
Posts: 1832
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Some interesting Steve Furber observations

Postby davidb » Sun Oct 02, 2016 12:27 pm

I'm interested in the Acorn-related bits but I also find the social history stuff fascinating. One part on page 50 made me sit up and take notice:
I don’t know. I mean, I – for undergraduates, of course you have some dealings with academic staff and supervisions were arranged by college and you have a tutor in college, but actually in sort of daily life the people you deal with more often are people such as the college porters, who have this sort of slightly dubious job of trying to maintain order in the college. And the name I remember was Big Bob, who was head porter at St Johns, who was a large gentlemen, as the name would suggest.

I seem to recall that one of the characters in Dirk Gently's Holistic Detective Agency is a porter called Bob, though maybe I'm just projecting the name back onto him now. Curiously, Douglas Adams also studied at St. John's College at around the time as Steve Furber, and I think I've read that the porter in the book was based on the one in real life. :)

User avatar
sweh
Posts: 1833
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: Some interesting Steve Furber observations

Postby sweh » Sun Oct 02, 2016 12:58 pm

The porter was called Bill, but MacDuff couldn't remember his name and called him Bob.

The porter didn't blink.

"No sir, and yes sir. Anything else I can help you with, Mr MacDuff, sir?"

"Er, no," said Richard and tapped his fingers a couple of times on the counter. "No. Thank you. Thank you very much for your help. Nice to see you again, er... Bob," he hazarded. "Good-night, then."

He left.

The porter remained perfectly still with his arms folded, but shaking his head a very, very little bit.

"Here's some coffee for you, Bill," said another porter, a short wiry one, emerging from an inner sanctum with a steaming cup.
Rgds
Stephen

User avatar
davidb
Posts: 1832
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Some interesting Steve Furber observations

Postby davidb » Sun Oct 02, 2016 1:37 pm

I imagine the Bob/Bill mix-up may have been a way to indicate where the inspiration for the character came from. ;)

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

Re: Some interesting Steve Furber observations

Postby BigEd » Sun Oct 02, 2016 8:41 pm

I like that!

Richard Russell
Posts: 163
Joined: Sun Feb 27, 2011 10:35 am

Re: Some interesting Steve Furber observations

Postby Richard Russell » Tue Oct 04, 2016 11:13 pm

BigEd wrote:Here's Steve Furber: On the Beeb's inception:
So when the BBC came round looking for a machine, their initial spec was a Z80 running CPM, okay.

Memory can sometimes play tricks, as I know only too well myself, and this is one of those occasions. I happen to have been recently going through some of my saved documents from 1981, and I have both the BBC's specification (as written by John Coll) and Acorn's response to it. The spec doesn't ask for a specific CPU or operating system, indeed the only references to the CPU are in the section on the memory map which I reproduce here in full:

"Memory map: above all this should be designed for expansion and standardisation. Probably should be RAM from 0000 up with ROM from FFFF down (including 8080/Z80 systems). At the very top there should be a simple monitor with any ROM high level languages immediately below. The screen should not be allocated to fixed RAM locations below C000 and could be dynamically allocated from available RAM. Scratchpad RAM for the stack and monitor, and RAM for the DOS should, preferably, be well clear of low memory RAM (6502 problems here) used for user programs".

So whilst this could be argued to be unnecessarily prescriptive, it is clear that the BBC was not trying to mandate the CPU and that the 8080, Z80 and 6502 were all considered as possibilities.

Interestingly, Acorn's initial response was to offer the Atom; there's no mention of the Proton:

"The Acorn ATOM + Super BASIC would go a long way towards meeting the entire specification required by the BBC. However, there remain some aspects of the specification that cannot be met by the ATOM - for example, the screen format - and so Acorn are prepared to offer the alternative of redesigning those sections of the ATOM hardware to bring it in line with the specification. Obviously this is a longer-term project than using the existing ATOM, but nevertheless it would still be possible to meet the specified deadline with the redesigned machine".

Acorn's response is undated, but must have been very early in 1981. The BBC's decision to go with them came on February 12th of that year.

Richard.

User avatar
lazarusr
Posts: 600
Joined: Thu Sep 10, 2015 8:56 pm
Location: London

Re: Some interesting Steve Furber observations

Postby lazarusr » Tue Oct 04, 2016 11:49 pm

Richard Russell wrote:I have both the BBC's specification (as written by John Coll) and Acorn's response to it

Any chance you could be persuaded to post the full documents on here? Are they just text files or do you have scans of the originals? I, for one, would love to see them.

User avatar
daveejhitchins
Posts: 3631
Joined: Wed Jun 13, 2012 5:23 pm
Location: Newton Aycliffe, County Durham

Re: Some interesting Steve Furber observations

Postby daveejhitchins » Wed Oct 05, 2016 7:47 am

lazarusr wrote:
Richard Russell wrote:I have both the BBC's specification (as written by John Coll) and Acorn's response to it

Any chance you could be persuaded to post the full documents on here? Are they just text files or do you have scans of the originals? I, for one, would love to see them.
And to preserve them, if not already preserved - - - I too would definitely be interested to read the full document and any others from the same thread.

Dave H :D
Parts: UM6502CE, GAL22V10D, GAL16V8D, AS6C62256A, TC514400AZ, WD1772, R6522, TMS27C512, AT28C256
Products: ARA II, ABR, ATI, AP6, MGC, AP5 . . .
For a price list, contact me at: Retro Hardware AT dave ej hitchins DOT plus DOT com

Richard Russell
Posts: 163
Joined: Sun Feb 27, 2011 10:35 am

Re: Some interesting Steve Furber observations

Postby Richard Russell » Wed Oct 05, 2016 7:54 am

lazarusr wrote:Any chance you could be persuaded to post the full documents on here? Are they just text files or do you have scans of the originals?

What I have, in general, is photocopies - and there's a lot of material, although much of it is probably of little historical interest. When I retired and had to clear out my filing cabinets at the BBC I realised that some of the BBC Micro paperwork ought to be preserved, so it came home with me and has been in the loft ever since!

I've already scanned the BBC's specification, albeit that it's rather faint and not very easy to read. I don't suppose there are major issues with publication after all this time, so I'll see if I can make it more generally available.

Richard.

paulb
Posts: 764
Joined: Mon Jan 20, 2014 9:02 pm

Re: Some interesting Steve Furber observations

Postby paulb » Wed Oct 05, 2016 10:21 am

Richard Russell wrote:So whilst this could be argued to be unnecessarily prescriptive, it is clear that the BBC was not trying to mandate the CPU and that the 8080, Z80 and 6502 were all considered as possibilities.


I'd agree about prescriptive: why would they have a specific requirement about the location of the screen?

As for use of the Z80, it's interesting to note that the Commodore PET got developed as a potential product for Radio Shack but that they ended up going their own way with a Z80-based machine that could potentially run CP/M: the TRS-80.

Richard Russell
Posts: 163
Joined: Sun Feb 27, 2011 10:35 am

Re: Some interesting Steve Furber observations

Postby Richard Russell » Wed Oct 05, 2016 11:10 am

paulb wrote:I'd agree about prescriptive: why would they have a specific requirement about the location of the screen?

I expect the reasoning was that plonking a block of immovable video RAM somewhere in the middle of the address space could be very limiting as far as expansion is concerned. This was probably based on the existence of earlier machines with exactly that limitation.

As was often the case Acorn used some 'lateral thinking' and addressed the issue in a slightly different way. Whilst the video RAM was indeed at a fixed address (for any given screen mode) it was arranged that it was 'top justified', i.e. the end address was the same for every mode but the start address varied. This neatly solved the problem of expansion (MODEs 0 to 3 being available only on the Model B) without the complication of the video memory being 'movable'.

Richard.

Richard Russell
Posts: 163
Joined: Sun Feb 27, 2011 10:35 am

Re: Some interesting Steve Furber observations

Postby Richard Russell » Wed Oct 05, 2016 2:01 pm

Richard Russell wrote:I don't suppose there are major issues with publication after all this time, so I'll see if I can make it more generally available.

I've put the original BBC Microcomputer Specification, as supplied to the companies who were invited to tender, here; I'm sorry that the quality is rather poor. It needs to be read from the perspective of the day (late 1980) rather than with the benefit of hindsight!

Richard.

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

Re: Some interesting Steve Furber observations

Postby BigEd » Wed Oct 05, 2016 6:32 pm

So glad you preserved this - and thanks for republishing!

User avatar
dgrubb
Posts: 133
Joined: Thu Jun 02, 2016 8:36 pm

Re: Some interesting Steve Furber observations

Postby dgrubb » Thu Oct 06, 2016 3:29 am

Richard Russell wrote:I've put the original BBC Microcomputer Specification, as supplied to the companies who were invited to tender, here


Nice! It's a little amusing that they slip in the Teletext as a single line when that was probably a huge project in and of itself.

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

Re: Some interesting Steve Furber observations

Postby BigEd » Sat Oct 08, 2016 8:20 am

dgrubb wrote:
Richard Russell wrote:I've put the original BBC Microcomputer Specification, as supplied to the companies who were invited to tender, here


Nice! It's a little amusing that they slip in the Teletext as a single line when that was probably a huge project in and of itself.

For peculiar reasons, I typed in the document and posted it here - should be more readable, and also searchable.


Return to “general”

Who is online

Users browsing this forum: No registered users and 1 guest