[1]ROUGOL logo RISC OS User Group Of London

[1]ROUGOL logo RISC OS User Group Of London
[2]Meetings > [3]Previous Meetings > [4]October 2012
__________________________________________________________________

[5]HOME | [6]ABOUT & CONTACT | [7]MEETINGS | [8]RESOURCES |
[9]OTHER

[people1s.jpg]
__________________________________________________________________

ARX, Arthur and RISC OS - Paul Fellows

Transcript of talk on [10]15th October 2012

All dialog is Paul Fellows, except audience questions that are marked
Q:. Minor hesitation and in-conversation self corrections edited.

Thanks very much for inviting me guys, god knows what you're all doing
here, after 25 years of doing this. I'm very pleased to talk to you
about what me and my boys did all that time ago. Before we talk about
that I've got to explain 'why?', and that means who I am and how we got
to where we got to.

Obviously we started off with the best machine in the world, ever, the
BBC Micro model B. That's what got me into all of this. Though my first
machine was a Sinclair ZX80 which I acquired for free, that I upgraded
with a ZX81 ROM which meant the keyboard was all wrong. My first
sensible computer was the BBC model B that I bought when I was a
student at Cambridge, I was encouraged to do that as a friend was
building an Acorn Atom in his room, a chap called Steve Barlow, which I
thought was a fantastic thing, and I abandoned studying chemistry,
which is what I was supposed to be doing, and started playing with
computers all day.

[11]Acornsoft software titles By the time I'd finished my degree, I'd
written this lot for Acornsoft. A bit of a chemical theme going on
here, using my chemistry degree that I should have been studying, but
was writing programs about it instead. Shirley Conran's Magic Garden
was the worst program in the world ever. I was forced to write that one
as Chris Curry did some bizarre publishing deal with Shirley Conran's
publishers. I apologise profusely for that program if anyone ever saw
it. That's the only one in its shrink wrap, it's so completely useless
I never opened it. Sphinx Adventure warped the minds of a whole
generation. Acornsoft Database was very good for what it did, but
completely made obsolete by Mark Colton's View series.

S-Pascal was a Pascal compiler that I wrote, in BASIC, and was my
thesis for my post-graduate work at the computer lab, so I did that and
got paid for it as Acornsoft published it. The whole of a Pascal
compiler written in BASIC in the 32KB of a BBC Micro. So you had your
program, the compiler and the object code it created, you'll notice
this one is published on a floppy disc, but they also published it on
cassette if you were a real masochist. You could load the compiler off
cassette, and compile a program that was about 1.5KB long, fabulous.

[12]Acornsoft language group titles As a result of writing that Pascal
compiler, I got offered the job of taking over running Acornsoft's
languages group. Myself, Tony Thompson, Stuart Swales and Richard Manby
were responsible for getting all of this lot out the door. We didn't
write any of them, but we managed and tested all of these. LISP was
written by Arthur Norman at the computer lab, Forth by Richard de
Grandis-Harrison who went on to be a driving force in other things,
like Symbian I think. Martin Richards, who invented BCPL, and his
brother were responsible for the compilers over there and the LOGO
implementation. There were some dudes from London that did the Prolog,
David Christiansen did COMAL and Ben and Lionel at Acorn did the ISO
Pascal compiler, which was fully validated and fitted on a 16KB ROM.

[13]Termulator and GXR The languages group kind of went off-piste,
management didn't really care what we did as long as it made money, we
got involved in several other things; Termulator a terminal emulator
for a VT52 terminal, which nobody used, we were very glad as I couldn't
really see why.

Most importantly to our story tonight we wrote the graphics extension
ROM for the BBC Micro. It had been mentioned, and there was a little
bit in one of the User Guides, that was reserved for the graphics
extension ROM and that tweaked my interest. I thought that someone
really ought to do that. And so Richard Manby in the languages group
(working for me) when he ran out of languages to implement he produced
a graphics extension that did ellipses, flood fills and that stuff and
produced the graphics extension ROM and all of that then got
incorporated into the BBC Master 128 Operating System and this is
crucial to the story as it's the first time Acornsoft, which was a
separate company, got to do some system software that went into the
machine, so you can see where this is going, can't you.

[14]BBC Micro Memory Map Right, here is a little lesson on the history
of the memory map of the BBC Micro. So on the slide here you have got
the BBC Computer, 32K, DFS, BASIC, the classic screen that it came up
with, and on this side over here you've got the memory map of how that
64KB of address space was organised. On the bottom here we've got the
RAM from 0 of 0x8000 and then 16KB of ROM space and then the Operating
system ROM and the memory mapped IO at the top. Very simple, and out of
scale, can you see where it says 'movable boundary', graphics memory
started here and worked its way downwards, but more likely it came down
to about here if you put it into high resolution graphics, so 20K of
your 32K went to graphics, and the Operating System had the first
4K-8K, so there wasn't very much left for you if you used high
resolution graphics modes.

[15]The Model B+ This too is crucial because, the model B was a very
popular machine but a lot of scrambling around and the competition
coming out with machines like the Commodore 64 and the Amiga coming
along with even more memory, 256KB or even 512KB of RAM, Acorn had to
do something and one of my friends, Martin Gilbert, was beavering away
in the background, building the Model C which became the Master, but it
was taking forever so we had to do something, and Watford Electronics
invented [16]* a way of adding more memory which was to create a shadow
bank of memory for the big chunk of the video memory, and if the
processor tried to access the memory in that range with an instruction
that had been fetched from a range in the operating system ROM then it
must be trying to access the screen so it would magically flip it over
to the other bank of memory and let you access the screen and let the
operating system do that and flip it back. Whereas if the address range
of the instruction fetch was anywhere else then is just accessed the
normal memory, so your program got to access normal RAM and the
operating system graphics routines got to see this other memory. Which
meant that you couldn't poke the screen because your program couldn't
get at it, it had to go through the proper operating system calls, and
that broke all sorts of illegally written software that cheated its way
around the APIs and we were very happy about that because all our stuff
worked.

[17]The B+ 128 But it still wasn't enough, and Acorn thought 'how the
hell can we add any more' and they made the B+ 128, because the Master
was even later. The way they did this was stuff another 64KB into some
of those ROM slots, if I nip back to the memory map, paged ROMs between
0x8000 and 0xBFFF you have the paged ROM area, so BASIC, ADFS and other
ROMs would live within this space and there was a page register that
would say which one was paged in but you could put RAM there as well.
The B+ 128 had four 16K RAMs stuffed into that area, and I've drawn a
little map of it here, so at the top we've got the operating system and
the ROMs, BASIC would live in here normally, but we've got 4 pages of
RAM over here making another 64K that was really hard to get at. This
is the shadow memory that I talked about from the B+ that only the
operating system graphics routines could get at. But I had this idea
that people wanted to write larger BASIC programs and if we were going
to sell a machine with 128KB of RAM we really ought to let you write a
bigger program than the previous version.

[18]Bas64 So I had this mad idea which was to put a BASIC interpreter
down here and let it access your program spread across these four ROM
slots, but of course they all lived in the same address space. By
finding all the places in the assembly language of the BASIC
interpreter where it accessed the source code of your program or its
variables, you discovered they were all done with one particular mode
of addressing, the 'indirect comma y' form of addressing, so we could
do that and stick an extra byte of address in there and poke a hardware
register in order to let you access these chunks as if it was a 64K
address space. So we got that version of BASIC all to work and there
was a lot of page swapping of the ROMs going on. I went along and
proposed that we do this too Roger Wilson, now Sophie Wilson, who was
responsible for BASIC and got the comment "You're insane, that's
suicide, it'll be impossible to do", so we did it anyway and it got
shipped with the B+ 128 and the Master that came along afterwards. Tony
Thompson from my group did this and Acorn were very grateful at the
time as they were able to say "It's bigger, and you've got more
memory", that really put my guys on the map as being able to do things
that Sophie thought were impossible. This is good and you can see where
this story is going.

[19]The first ARM chip Meanwhile, Sophie and Steve had been incredibly
busy designing the ARM chip, and there is a picture of the first ARM
chip with its lid off. The statistics about it are amazing, 25 thousand
transistors, based on 3 micron technology which is 3000 nanometres in
today's money, huge by comparison to anything going on today. It was
running at 6.6MHz and taking one cycle per instruction to do its work.
It only had 26 different instructions at the time and there's no
multiply on this device, which came later with the 2micron version, the
die-shrink. They built it first and put it in the very nice
second-processor cases, pictured here. You could turbo-charge your BBC
but getting one of these systems and putting it on the side, if you
could get hold of one. They were really hard to get hold of and
eventually sold as an ARM development system, they were a bit snotty
about who was allowed to buy them, they didn't put them on general
sale. In fact we had some trouble getting them at Acornsoft and I had
to send Stuart Swales down to the lab, signed for all the parts, and
brought them back and we built four ourselves. This was the only way to
get hold of these wonderful things. I thought it was absolutely amazing
to boot one of these up with BBC BASIC V, and see that I had a whole
Megabyte of RAM to play with and the thing was unbelievably fast
compared to the poor old BBC which we had before.

[20]Why did Acorn do RISC at all? I just wanted to say a bit about why
Acorn decided to do this whole RISC thing at all, Acorn was a
manufacturer of home computers, why on earth would you be crazy enough
to design your own chip?

Sophie did an analysis of the compiler output for a lot of common
compilers as part of the process of trying to choose which chip we
should use next, we were looking at things like the 68000 and the
National Semiconductor 16032, or 32016 as it got renamed. I don't know
if you remember, a second processor was done with that 32016 and Nat
Semi had produced a poster that said "32016 is not a late 16 bit
machine it's an early 32 bit machine", a year later we crossed out
'early' and wrote 'late' on it. This analysis showed that all of the
complicated instructions and all of complicated mem-copies, the
compilers just don't generate them. They generate Load/Store, add,
subtract, and/or, compare, branch, that's about it really, the rest of
them, unless you're writing in assembler, you just don't use them, so
they're a complete waste.

Now, the aforementioned, Arthur Norman, who had written the LISP
interpreter for the BBC Micro, and was in and out of Acorn the whole
time, had come up with a design for a machine with 3 instructions
called the SKI machine. Whose instructions were called 'S', 'K' and 'I'
and it ran LISP in hardware and he built one of these things, it never
worked, it was so big and covered in wire-wrap it was always broken.
The idea was to prove that you really didn't need very many
instructions for a general purpose machine.

Q: What were the three instructions, what did they do?

I can point you at his paper if you like, I've read it but I still
don't understand it. Are you familiar with the LISP programming
language? Basically you could take the right value, the left value or
skip onto the next instruction, those were really only the three
primitives you need in LISP. That's what this machine did, only I've
read his paper and I still don't really get it. Also at the time the
computer lab had just got their IBM 370, and we noticed that had Branch
and Link and put the program counter into R14 rather than having
Jump-To-Subroutine, automatic stamp. That had the model of a
user-accessable register for return-addresses, and returning by just
using MOV R14 PC and why have a special purpose RTS instruction. All of
those things together meant that they thought "Right, it is
sufficiently simple that we could design this". and so they did it,
mostly because they could and because of all the work going on in the
computer lab at the time.

[21]ARX Acorn had also opened a research centre in Paolo Alto and set
about the process of writing an operating system to run on this chip,
ARX. This ARX operating system was preemptively multi tasking,
multi-threaded, multi-user, written in Acorn-extended Modula2+,
god-alone knows why they chose that language. I did some tests on the
compiler for it, which was the only compiler there was for the ARM at
this point. I gave it the task of taking an X and Y coordinate and
working out where that would be as an address in memory, so we had to
add the base address to the Y coordinate times the row width and add X,
not exactly complicated it is two adds and a multiply. The Modula2
compiler generated 25 instructions and then did Branch and Link general
multiply, so it was a bit slow. It was slow because it was written in a
high-level language and because, this a quote from Wikipedia, "much of
the operating system ran in user-mode and suffered from kernel switches
to perform the mutexes" in order to do all of the multi processing
that's mentioned above. Of course the real problem with it was that it
was very, very late. So the hardware was starting to be made and the
software was obviously nowhere to be seen and predicted to be another
six to nine months away from being ready to ship. Hence this is why
project Arthur got the job, born in this absolute crisis of the
hardware coming into existence.

Q: Is there a relationship between Arthur Norman and Arthur?

I'm not sure, that's a good question, I did think about that. I believe
that the word Arthur comes from the fact they wanted ARm on THURsday,
because of the crisis, but that's my memory of it, and there's a bit of
debate and other people may say different things.

Officially it was Project Arthur, but Arthur Norman was never involved,
even though he was around and involved in the design of the ARM.

[22]Project Arthur I was hauled in, in front of the board of directors
at Acorn, and they said "the hardware is being made and we have got no
software, you guys aren't doing very much at Acornsoft, can you make us
a BBC like operating system, you've got 5 months?", as that's when the
hardware is going to hit the streets. And like an idiot I said "yes",
we hadn't got very much to do. The reason they came to us was because
we'd done the graphics extension ROM for the Master, we'd been part of
the recent machine that had gone out the door and because we'd done the
fancy BASIC interpreter that could access more memory, thus proving we
could do hard things, and done all the languages you could possibly
want for the BBC Micro, so we really didn't have much else to do.

[23]Arthur? Who the **** was Arthur? Who were we? It was the Acornsoft
languages group, myself, I was the team leader, I was the fool that
said "yes we can do it". I got to write the I2C drivers, actually I was
given some I2C drivers by John Biggs, who's at ARM today, they were
written in Modula2 which had been ripped off out of the ARX
implementation, he said "here, this is how you do it, make the Real
Time Clock work, that'll be fine, just test it for me will you?". Not
having a compiler that worked on the nascent version of Arthur that we
had at the time, I transliterated it all into assembler, it went 400
times faster and it got slightly upset that I was driving the bus too
fast. I also did things like the colour palette.

Tony Thompson, who had done that implementation of BASIC 64, he got to
do the core of the operating system, so the real guts of Arthur itself.
That brought it out of reset, powered it up, organised all the memory
and so forth. We had a really interesting time with part of that, we
had one of the machines that we just could not get this thing to boot
reliably. You could boot it, turn it off, reboot it and sometimes it
would work and sometimes it wouldn't. It turned out, it would boot fine
if you left it long enough, but if you didn't turn it off for very long
then it didn't reset properly, and this was because the fan on the
board was still spinning and the back EMF on the fan was enough power
to keep the ARM running. And that's why you've got an ARM in your phone
today, it would take no power to keep a 3 micron ARM with 25000
transistors would run for 30 seconds off the energy stored in the fan.

Stuart Swales, wrote fileswitch and I think the Heap manager as well,
we couldn't have done it without Stuart, he just fixed everything.

Richard Manby, graphics extension ROM author, did the graphics and in
RISC OS 2 he went on to do Draw which is really quite a fantastic
program.

Then we've got our ace games programmer out of semi-retirement where
he'd been out writing games for the beeb with no market for them, Tim.
Tim works at Broadcom these days, he did the text, the sound, the
keyboard, the serial. We drafted in a couple of other guys from Acorn
as the team grew.

We got Nick Reeves who did the disk filing system stuff and Brian
Cockburn, that was the team, just those guys. Tony is at ARM, Stuart
has retired, Richard Manby works at ANT in Cambridge on embedded
browsers, Tim works on chips with Sophie at Broadcom, things like
Raspberry Pi core chips and related work, Nick Reeves is at ARM and
Brian is at Amino. Amino is a company that I started with Martin
Gilbert in 1997, Martin designed the Master 128. If you look inside one
of these Amino set top boxes you find there's a boot ROM in the NOR
flash, and a filing system on the NAND flash, and the boot ROM doesn't
half look like the core operating system and a load of separate
relocatable modules, it boots up and runs *exec !Boot and that's inside
the NAND flash which goes 'run Linux'. I think we sold 4.5 million of
those set-top-boxes, which is more instances of an operating system
than Acorn ever managed.

[24]A500 2nd Processor Things got serious when I got some hardware on
my desk, this is the first piece of hardware I got (A500 second
processor card), you can see the four core chips, the ARM, MEMC, VIDC
and IOC, in their square flat-pack holders, the RAM over there, some
operating system software of some sort in these EEPROMs here, and the
TUBE interface. So this was plugged into, via a tube interface, a BBC
Micro, so it was a giant second processor (as it says on the board
"A500 second processor"). This was the development board that we had,
we first had one and gradually got to the point of having one each to
do the development work on. You could attach a keyboard to it, graphics
output from it to a monitor, so gradually the functionality of Arthur
came to life and you could migrate more and more of the IO features
over onto the board from the BBC Micro. Of course this thing could
never run entirely standalone it always needed that host micro to get
it going. We got everything going, the sound, graphics, the memory
management and everything running on here as the initial systems.
There's still quite a few of these boards around and they still work.

[25]A500 The first stand alone machine, the A500, which is very
confusing because they're both called A500, but the other one was the
A500 second processor. There's a photo of said machine with its lid on
and lid off. I thought it was quite smart, this design with this
plastic moulding on the front and the keyboard that plugged in. I think
this is actually my computer, I can tell it's mine because it's got red
stickies on some of the function keys, to change the names of what
those buttons did, because the keyboard was designed for ARX and had
some weird buttons on it that nobody ever knew what they were supposed
to do, so we stuck some labels on, I think it was Tipex on this one to
make it more appropriate. It's booted up there running what seems to be
RISC OS 2 to me. Inside you've got the floppy drive, hard drive, podule
bus, you've all seen this, it's very similar to any other Archimedes.
There's the fan that you have to stop in order to reboot it.

Then the real machines came along, the Archimedes, they changed one
important thing, the keyboard. A different style of keyboard and
keyboard connector. I don't quite know where the keyboard came from,
but there was obviously a micro in there which would chuck it (the
keyboard data) to us down the serial lead. One of my funny stories is
trying to debug the interface between Tony's software and the keyboard,
myself and Stuart and Tony and Bruce (Brian Cockburn) were there all
night trying to get this damn thing to work, because the guys who made
the keyboard had got this fantastically useless protocol that they'd
come up with. The keyboard sent you 0xFF, you replied 0xFF, then it
sent you 0xFF again, you replied 0xFF, then it sent 0xFE, and you were
supposed to reply 0xFE. The only trouble was, when you received an 0xFF
from it, you didn't know if it was the first one or the second one. We
spent ages trying to create some code on the ARM end make it reliably
boot up and start the keyboard properly. Eventually, at about 1:30 in
the morning I suggested we just send it something illegal, so we sent
it F0, well you would wouldn't you?

The keyboard took that and went "oh I don't know how to deal with that,
I'll start again" and sent 0xFF, but this time we knew it was the first
one, and it's still like that today, because we never could get to the
bottom of why it didn't work.

[26]Inside the A500 So that's it with its lid off, all the rest of the
bits that were hidden under the drives and so forth. There's an awful
lot of components on there by today's standards, I think it broke the
CAD program because there were more than 512, the CAD program that the
guys were trying to use to design the hardware couldn't handle it.

[27]Arthur was still a command prompt Software wise, the core operating
system was made to look like the BBC MOS, with relocatable modules made
to look like those sideways ROMs, all the service calls in the Beeb are
mirrored by those that go chaining through, but you don't have to do
hardware paging to go from one to the other. Underneath all versions of
RISC OS still have a BBC inside them and in fact if you turn on one of
my Amino set top boxes, with the debug lead in, it doesn't half look
like that. In 2007 I finished my association with Amino set top boxes
and did another company with Adrian Chritchlow and some other guys who
were from the Acorn world, and we built something called AlertMe.com in
Cambridge which does home gateways, which are connected to the
internet, have a modem in them and through a collection of Zigbee based
sensors have got a burglar alarm function. There's a programmable
infra-red sensor and some magnetics ones and key-fob and so forth and
you can do it really well. Those little sensors have all got a small
processor with 5K RAM and 128K ROM and they don't half look like these
inside as well. All the Amino set top boxes and all the AlertMe sensors
are the great grandchildren of all of this. I kept the faith, I've
built another 5 million units that have got an operating system just
like this one in them that probably no one has ever really heard of.
Why change a good plan eh?

[28]Enter Neil Raine I want to talk a little about my friend Neil,
sadly no longer with us. By that stage we were here, Arthur 1.something
that fired up and looked like that. And it did what the management had
asked us to do, it built a BBC Micro. But Neil came along and said
"I've finished writing these games", that was his best game ever
'Planetoid', defender, a great game. He got interested in writing a
font manager to run on Arthur, so he wrote two, a bitmap one which was
all well and good but a bit clunky and horrible. Then he wrote an
outline font manager later that was so much nicer, which is the one
that's still in there today I think.

And he wrote a Window Manager, I think he just wrote that because he
wanted too, the addition of these two modules transformed Arthur from
that command-line world to a desktop based system.

[29]Richard wrote a demo app The Arthur Desktop There's a cautionary
tale behind this, Richard Manby wrote this (Arthur Desktop), in BASIC
as a demonstration of the Window Manager and what it could do, using
the bitmap fonts and so forth, the outline font manager wasn't ready at
this point. As a piece of demo-ware it escaped into the wild, they
burnt it into the ROM and it's what it boots up with, but it was a
demonstration of how you can write programs to use the window manager,
but never underestimate the marketing department, they'll get you every
time, if you write a demo, they'll sell it. How many times have we all
been bitten by that one?

[30]Tin Hats on: ARX So after we'd written that, the great show-down
meeting happened, as it says here, the ARX and the ARm on THURsday
showdown meeting. In the boardroom at Acorn, in the morning the team
from Paolo-Alto turned up with their 4MB A500 with a hard-drive running
ARX to do a demonstration of how far they'd got and what a wonderful
thing it was. But big mistake, they'd told us what their demo was going
to be before hand. So they'd got a ticking clock running, and they said
"and you can click on another one and run several of these at once, you
won't be able to do that on Arthur as it can't multitask, look!", they
clicked on three or four of them and got them running. When the fourth
one started the system started to engage virtual memory and started
swapping, on a 4MB machine and the hands on the clock started ticking
once every 16 seconds.

[31]Tin Hats on: Arthur So they did their demonstration and we turned
up, Tim Dobson had written a clock program, we turned up with an A305
with 256KB RAM, an Arthur desktop and a ticking clock program, and we
ran 16 of them which ticked smoothly, and ARX got cancelled the next
day.

It (ARX) was hopeless, there was no way that we (Acorn) could afford to
go to market with a machine that needed 4MB of RAM and a hard drive, in
those days, and even then was going to be that slow. We were absolutely
going to have to launch it with the smallest amount of RAM and no hard
drive.

Q: When was this?

1986/87, something like that. I think it was Sept 1985 when I had that
come to Jesus meeting where they said "Write it in 5 months, we'll have
the hardware in early 86", of course the hardware took longer than
that, it always does, doesn't it. But so did we, we took a year to get
to Arthur 1.20, we shipped a few versions earlier than that.

Q: How much was 4MB of RAM in 1986?

A shit load.

The A500 would have been 3000 ukp worth of computer, and the little
A305 and A310 were about 1000 ukp all in. 700 ukp for the smallest
system, so still fairly expensive compared to the beebs at 400-500 ukp.
The problem was that the price of these systems was ratcheting up,
although the functionality was going up. What happened to Acorn, in my
opinion, it went to fast up the functionality curve, that the price
crept up. It left an enormous gap underneath into which Nintendo,
Playstation and everyone else marched with their games engines and took
away their core market, that's my view.

[32]Neil's Wizzard Idea Going back to Neil, he had a wizard idea, he
said at the coffee machine one day "you know what, if we fool around
with MEMC we can do overlays, we can take an application program, use
the memory controller to whisk it away and map it somewhere else in the
memory map and put another program in at 0x8000 (which was where we
mapped our applications too), the logical equivalent of PAGE on the BBC
Micro, we can do overlays, switch from one program to another. I
thought "that's all very well Neil but why would we want to bother
doing that?". He came up with the most astonishing idea I'd ever heard,
If I do this on the return from Wimp_Poll instead, so that your program
calls Wimp_Poll and instead of getting an answer back, it get swapped
out and someone else gets swapped in, and they get the return from the
Wimp_Poll that they called sometime earlier. Then we can actually have
the full multi tasking system that is RISC OS.

Q: What did Wimp_Poll do before that? (In Arthur)

In the world of the Arthur 1.20 desktop, you called Wimp_Poll to the
operating system, which is a SWI call and it would get any messages
from the Mouse or Keyboard and return them too you, or quite often say
'null', there's nothing to do. So you'd sit there, polling away,
responding to input. What Neil did was, you would call Wimp_Poll and
that would see if there were any input messages for any other window,
and if there was a message for another window, for another task,
instead of returning the answer 'null' to you it would return to them,
having poked around in MEMC to put their code into the space. They
thought they'd made a call to Wimp_Poll and the very next thing as far
as they were concerned was that they got their answer back, but
actually you'd been running for a while in the mean time, because it
had paged them out and put you in, you didn't even know they were
there. I thought this was absolutely brilliant.

Q: So how did you run multiple clocks at once? (In the Arthur demo)

We just wrote a BASIC program that was allowed to draw itself lots of
times, absolute fraud. If they'd said "Can you run two clocks and a
calculator", I was screwed. But we went second and they went first, and
they showed us their demo the night before and said "this is fabulous",
and we wrote something that did exactly the same, but better. The thing
was that their system was never going to fit on a machine that we were
actually going to sell, so, all's fair, it needed doing.

I'm coming to the end of this now, I did a little bit of Googling for
RISC OS, Arthur and various other things and I found this page. I was
very pleased by this, somebody pointing out "the Windows 7 task bar is
decidedly dock like with large label-less icons like dock, this is now
a place to launch programs as well as somewhere to minimise windows,
you can drag an application anywhere on the taskbar and drag to arrange
them, as on the Mac. In windows 7 the box around the icon indicates
that a program is running", blah blah blah, "Apple acquired the Dock
from Steve Jobs' NextStep OS which stole it from Acorn's Arthur
Operating System of 1987". Damn right it did! Tragically you couldn't
patent software at that point. So this was the one I invented, I came
up with the idea of the iconbar across the bottom. In case anyone ever
asked where it came from, we were sat in a room thinking "how do we
design this to be different, so we don't get sued by Apple". The Mac of
the day had a menu bar of text across the top, so we thought "we can't
go across the top, we'll have to go across the bottom and we can't use
text so we'll have to use icons", that's why it's like that.

My proof that this is in fact true, have you ever asked yourself why
some of the icons are on the right and some are on the left? Have you
noticed that Windows has exactly the same distribution, some things go
that side and some things go that side. We started off with having a
world of physical devices on the left and application programs on the
right. That was the rational for it in the first place, and it's
exactly the same way, up to a point, in Windows. Printers and floppy
drives, all turned up on this side. It's become a bit more confused in
the later versions, generally when you ran things they appeared there
and when you had things they appear there. So I think I'll come to the
end of my rant and I'm happy to take any questions. or regale you with
further amusing stories of some of the naughtiness that we got up to
along the way that I didn't dare write down.

Q: ARX, who was actually developing it?

A group in Paolo Alto, there was a guy called Jim Mitchell that lead
the ARX development team out there and a lot of very highly paid
Californian software engineers writing it. It would have been
absolutely wonderful, it just needed about another 20 years of Moore's
Law to make it plausible.

Q: Was it started from scratch or based on something?

As a paradigm there was a Linux like core called Mach, a
multi-threaded, multi-user core, they were trying to follow that, and
built it up from that sort of base.

Q: A bit like Mac OS X?

Yeah a bit like Mac OS X, it wouldn't surprise me to find that some of
those guys ended up working at Apple. There was a guy at Colton
Software with us, Dave ???? who joined Microsoft in Seattle and it was
shortly after that that Windows acquired an iconbar. I know how that
idea got there.

Q: The board of directors at Acorn when you were there, were they
technical people?

During the Arthur project, I think we had Brian Long as the
CEO/Managing director, he was a financial man. Herman (Hauser) was
technical director, in name, but Jim Merryman, the operations director
was doing technical director role, because Herman and Chris (Curry)
were too busy doing other things. No, none of them were particularly
technical. The technical leads of the company were really Sophie
(Wilson) and Steve Furber, and then people such as Tudor Brown and Mike
Muller, who subsequent to that story separated off from the mothership
and went off to be ARM.

Q: How important do you think it is that directors should have a
background in electronics, hardware or programming?

I think if you look at the history of Acorn it was started by Chris
(Curry) and Herman (Hauser), Herman was a deeply technical guy, I've a
lot of respect for Herman. It was when those guys let go of control of
the day to day side of it, shortly after this episode that things
really started to go wrong. The rush to market, to release products
before the right time, set in because the company had 300-400 employees
and needed to feed them, and kept having to churn out new products, and
the financial side of it was running it. Yes, it's vitally important
that technical people with the vision to see where it's going are the
ones that lead the company. You need the business people there to
execute it, but if you let go of that technical vision, it goes
pear-shaped.

Q: You say it all started to go wrong after the release of Arthur, when
the technical guys let the finance guys take over, wasn't the whole
story of Arthur basically a product being released before it was ready?

Yeah, the whole thing should have taken longer. I completely agree, I
think the mad rush to design the hardware and get it out to market
meant that it came out at a price point that was unaffordable, 700-1000
ukp was too much in the face of the competition, a 68000 based Amiga,
at 500 ukp. We had a machine that was better, but more expensive, we
didn't have an entry level product underneath.

So it was an extremely tough sell.

Q: I remember Sophie Wilson saying a similar thing when she gave a
talk. In the experience of selling the Archimedes it was the high end
models that got pulled first because people bought the low end ones,
people cared more about price, than features.

Yeah, sadly exactly right, it was a wonderful machine.

Q: Did you have a role beyond Arthur?

No, I decided to leave, after about Arthur 1.60, I think I took it up
to there, I left and was offered a lot of money to go and work for
Clive Sinclair, building his machines. William Stoye took over from
1.60 through to 2.something when they renamed it RISC OS. 1.60 had all
that Neil Raine magic in it, that happened on my watch. I went off to
do other things and for about a year I designed, with Mark Colton, a
machine for Clive Sinclair called the Z88 which was a laptop that ran
on 4 AA batteries, the screen at the top and the black rubber keys, we
had a lot of fun doing that. It had Pipedream in it that Mark had
written and BBC BASIC which Richard Russell did, a nice machines. We
were designing a follow on for it which was going to use an ARM
processor and be in a nice magnesium case and then Clive, bless him,
decided the future was satellite dishes, dropped doing computers and I
went "you don't need any software for a satellite dish", so I set my
own business up.

Q: Is that what happened to the 'Quantum Leap' ?

That had died sometime before, a long time before.

Q: You mentioned William Stoye. There was a Stoye who did some work on
semantics in programming languages, now are they related, it's an
unusual surname?

I think it might be the same person, that's what his PhD was in. He was
in Acorn's R&D group when I decided to move on, and they got him too
look after RISC OS.

Q: You mentioned you were in charge of the languages group, when it
came to the Arthur Operating System, there didn't seem to be the same
collection of languages available?

One of the things the history of it showed was that Acornsoft, a
separate limited company, whose mission was to make money by selling
software titles for Acorn's computers. We were in the same Group but a
separate thing and when we got merged together and the Arthur project
was born there was no Acornsoft to go and do the exploitation work. To
build the software titles and the games, we had a game, that David
Braben wrote 'Zarch', that was it. There was no Acornsoft games
department ready to build all of those software titles. I remember
after we got the operating system working, banging on about this for
some time saying "look, this is all well and good, we've got this
machine, but we need loads of application software for it like we had
before in order to make it useful", but there was no resource to do
that.

It took a fair time before various third parties, Computer Concepts and
a whole bunch of others managed to catch up and start producing enough
software. Impression, Rhapsody and all that that made it actually
useful. It would have helped if we'd had the same group of guys
beavering away churning out titles. There was still a belief within
parts of Acorn that this was only a temporary solution and that the ARX
stuff would come back, and there was another lot that was trying to
build BSD UNIX that was going on as well. All the guys that they hired
that were working on compilers were focusing on them, so it was
absolutely ages before we had a compiler for anything. We couldn't get
anyone to put any effort in to making the tools to go with the thing,
because it was only an interim solution.

Q: Too quiet to hear

The A305 and A310 were the first machines, if we'd had a team of half a
dozen people to write applications they could have started a year
before that on the A500.

Q: Presumably that would have been your team if you hadn't had to take
over from ARX?

Yes, it would have been us, but we were writing the operating system,
it would have been our job to build all that stuff for people.

Q: Sometime afterwards there was a PC emulator?

Yes, a guy called Ian Jack wrote the PC emulator, he wasn't part of my
team, but he was in the next door office. A 186 emulator, and then a
286.

Q: Are you surprised that RISC OS still attracts so many of us?

Yes, I think you're all bonkers.

Q: Is it nostalgia?

I think it is, but we did a good job given the mad history of it all
and I wish my computer would boot in 2 seconds. It does my head in
every day when I confront Microsoft Windows and think what things could
have been like. Over time, Windows particularly, and some of the Mac
stuff has evolved more and more to look like RISC OS. You've all got
iPads and things like that, does that all feel horribly familiar?

Q: The Arthur way you can only run one application at a time?

Yeah exactly!

I think it is fantastic that things like the Raspberry Pi are coming
out. David Braben has done a lot to publicise that, not because he
thinks RISC OS is wonderful, but that we really want to encourage a
whole new generation of people to understand the technology. I've got
my software businesses but I can't hire anyone who knows what is going
on. It's very rare these days that someone knows what an interrupt is,
knows how to poke a register or how to debug anything when the tools
don't work. It's quite a problem.

I won't tell you the story about who was arrested on the premises!

Not only did we not have not have any tools or compilers. All we had
was an assembler.

Q: The BASIC assembler?

No John Thackery had done an assembler for the ARM development kit, we
used that. That and the BASIC interpreter, that was it.

We had no source control, we had 7 or 8 guys trying to write an
operating system to go into a ROM, so you've got to get it right, and
they're all doing different bits of it and some of these share system
files. No CVS, no source control, no Sourcesafe, none of that. The
solution was the main system header file with all the constants, SWI
numbers and addresses of everything lived in. You could edit that if
you had the pink dinosaur on your desk. If you did not have the pink
dinosaur on your desk you could not edit it. If you edited it without
the pink dinosaur, my Australian friend, Brian Cockburn, would come
round and see you. I remember a squealing as Stuart had made some
interesting macro changes to the header system without the dinosaur and
Brian had spent most of the night trying to figure out why his stuff
didn't work, and had finally found out and had got Stuart cowering
under the desk saying "come on I want to do the other arm", after
giving him a chinese-burn on one arm.

I remember going to one of the first shows down at Olympia when we were
launching stuff. Acorn had a massive stand there and we had one
Archimedes A310 on one end, and on the other end lots of the Acorn
marketing guys in suits with the Acorn ABC, the awful things that
Olivetti had forced them to do. Myself and Stuart there, I had my very
ancient brown jumper on and Stuart with orange hair 'out here'. There
was a great mob around us to see what we were showing with Arthur 1.20
and you could hear the suited Acorn sales guys saying "no, no, no, I
don't know anything about it, you need to either speak to him with the
jumper or him with the hair".
* Actually shadow RAM was invented by Chris Jordan and David Barnett,
and first marketed by Aries Computers
__________________________________________________________________

[33]BACK TO TOP OF PAGE

References

Visible links
1. http://www.rougol.jellybaby.net/
2. http://www.rougol.jellybaby.net/meetings/index.html
3. http://www.rougol.jellybaby.net/meetings/previous.html
4. http://www.rougol.jellybaby.net/meetings/2012/oct.html
5. http://www.rougol.jellybaby.net/index.html
6. http://www.rougol.jellybaby.net/about/index.html
7. http://www.rougol.jellybaby.net/meetings/index.html
8. http://www.rougol.jellybaby.net/education/index.html
9. http://www.rougol.jellybaby.net/riscos/index.html
10. http://www.rougol.jellybaby.net/meetings/2012/oct.html
11. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8098.jpg
12. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8101.jpg
13. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8102.jpg
14. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8103.jpg
15. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8104.jpg
16. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/#watnot
17. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8105.jpg
18. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8106.jpg
19. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8107.jpg
20. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8111.jpg
21. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8115.jpg
22. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8119.jpg
23. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8125.jpg
24. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8126.jpg
25. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8127.jpg
26. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8128.jpg
27. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8129.jpg
28. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8130.jpg
29. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8131.jpg
30. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8135.jpg
31. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8136.jpg
32. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8140.jpg
33. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/#top

Hidden links:
35. http://www.rougol.jellybaby.net/meetings/2012/PaulFellows/1024/IMG_8141.jpg