36C3 - The Ultimate Acorn Archimedes talk

36c3 preroll music

Herald: Our next talk will be "The
ultimate Acorn Archimedes Talk", in which

there will be spoken about everything
about the Archimedes computer. There's a

promise in advance that there will be no
heureka jokes in there. Give a warm

welcome to Matt Evans.

applause

Matt Evans: Thank you. Okay. Little bit of
retro computing first thing in the

morning, sort of. Welcome. My name is Matt
Evans. The Acorn Archimedes was my

favorite computer when I was a small
hacker and I'm privileged to be able to

talk a bit little bit about it with you
today. Let's start with: What is an Acorn

Archimedes? So I'd like an interactive
session, I'm afraid. Please indulge me,

like a show of hands. Who's heard of the
Acorn Archimedes before? Ah, OK, maybe 50,

60%. Who has used one? Maybe 10%,
maybe. Okay. Who has programs -

who has coded on an Archimedes? Maybe
half? Two, three people. Great. Okay.

Three. laughs Okay, so a small
percentage. I don't see these machines as

being as famous as say the Apple Macintosh
or IBM PC. And certainly outside of Europe

they were not that common. So this is kind
of interesting just how many people here

have seen this. So it was the first ARM-
based computer. This is an astonishingly

1980s - I think one of them is drawing,
actually. But they're not just the first

ARM-based machine, but the machine that
the ARM was originally designed to drive.

It's a... Is that a comment for me?
Mic?

I'm being heckled already. It's only slide
two. Let's see how this goes. So it's a

two box computer. It looks a bit like a
Mega S.T. ... to me. Its main unit with

the processor and disks and expansion
cards and so on. Now this is an A3000.

This is mine, in fact, and I didn't bother
to clean it before taking the photo. And

now it's on this huge screen. That was a
really bad idea. You can see all the

disgusting muck in the keyboard. It has a
bit of ink on it, I don't know why. But

this machine is 30 years old. And
this was luckily my machine, as I said, as

a small hacker. And this is why I'm doing
the talk today. This had a big influence

on me. I'd like to say as a person, but
more as an engineer. In terms of what my

programing experience when I was learning
to program and so on. So I live and work

in Cambridge in the U.K., where this
machine was designed. And through the

funny sort of turn of events, I ended up
there and actually work in the building

next to the building where this was
designed. And a bunch of the people that

were on that original team that designed
this system are still around and

relatively contactable. And I thought this
is a good opportunity to get on the phone

and call them up or go for a beer with a
couple of them and ask them: Why are

things the way they are? There's all sorts
of weird quirks to this machine. I was

always wondering this, for 20 years. Can
you please tell me - why did you do it

this way? And they were a really good bunch
of people. So I talked to Steve Ferber,

who led the hardware design, Sophie
Wilson, who was the same with software.

Tudor Brown, who did the video system.
Mike Miller, the IO system. John Biggs and

Jamie Urquhart , who did the silicon
design, I spoiled one of the

surprises here. There's been some silicon
design that's gone on in building this

Acorn. And they were all wonderful people
that gave me their time and told me a

bunch of anecdotes that I will pass on to
you. So I'm going to talk about the

classic Arc. There's a bunch of different
machines that Acorn built into the 1990s.

But the ones I'm talking about started in
1987. There were 2 models, effectively a

low end and a high end. One had an option
for a hard disk, 20 megabytes, 2300

pounds, up to 4MB of RAM. They all share
the same basic architecture, they're all

basically the same. So the A3000 that I
just showed you came out in 1989. That was

the machine I had. Those again, the same.
It had the memory controller slightly

updated, was slightly faster. They all had
an ARM 2. This was the released version of

the ARM processor designed for this
machine, at 8 MHz. And then finally in

1990, what I call the last of the classic
Arc, Archimedes, is the A540. This was the

top end machine - could have up to
16 MB of memory, which is a fair bit

even in 1990. It had a 30 MHz ARM 3. The
ARM 3 was the evolution of the ARM 2, but

with a cache and a lot faster. So this
talk will be centered around how these

machines work, not the more modern
machines. So around 1987, what else

was available? This is a random selection
of machines. Apologies if your favorite

machine is not on this list. It wouldn't
fit on the slide otherwise. So at the

start of the 80s, we had the exotic things
like the Apple Lisa and the Apple Mac.

Very expensive machines. The Amiga - I had
to put in here. Started off relatively

expensive because the Amiga 500 was, you
know, very good value for money, very

capable machine. But I'm comparing this
more to PCs and Macs, because that was the

sort of, you know, market it was going
for. And although it was an expensive

machine compared to Macintosh, it was
pretty cheap. Even put NeXT Cube on there,

I figured that... I'd heard that they were
incredibly expensive. And actually

compared to the Macintosh, they're not
that expensive at all. Well I don't know

which one I would have preferred. So the
first question I asked them - the first

thing they told me: Why was it built? I've
used them in school and as I said, had one

at home. But I was never really quite sure
what it was for. And I think a lot of the

Acorn marketing wasn't quite sure what it
was for either. They told me it was the

successor to the BBC Micro, this 8 bit
machine. Lovely 6502 machine, incredibly

popular, especially in the UK. And the
goal was to make a machine that was 10

times the performance of this. The
successor would be 10 times faster at the

same price. And the thing I didn't know is
they had been inspired. The team Acorn had

seen the Apple Lisa and the Xerox Star,
which comes from the famous Xerox Alto,

Xerox PARC, first GUI workstation in the
70s, monumental machine. They'd been

inspired by these machines and they wanted
to make something very similar. So this is

the same story as the Macintosh. They
wanted to make something that was desktop

machine for business, for office
automation, desktop publishing and that

kind of thing. But I never really
understood this before. So this was this

inspiration came from the Xerox machines.
It was supposed to be obviously a lot more

affordable and a lot faster. So this is
what happens when Acorn marketing gets

hold of this vision. So Xerox Star on the
left is this nice, sensible business

machine. Someone's wearing nice, crisp
suit bumps microphon banging their

microphone - and it gets turned into the
very Cambridge Tweed version on the right.

It's apparently illegal to program one of
these if you're not wearing a top hat. But

no one told me that when I was a kid. And
my court case comes up next week. So

Cambridge is a bit of a funny place. And
for those that been there, this picture on

the right sums it all up. So they began
Project A, which was build this new

machine. And they looked at the
alternatives. They looked at the

processors that were available at that
time, the 286, the 68 K, then that semi

32016, which was an early 32 bit
machine, a bit of a weird processor. And

they all had something in common that
they're ridiculously expensive and in

Tudors words a bit crap. They weren't a
lot faster than the BBC Micro. They're a

lot more expensive. They're much more
complicated in terms of the processor

itself. But also the system around them
was very complicated. They need lots of

weird support chips. This just drove the
price up of the system and it wasn't going

to hit that 10 times performance, let
alone at the same price point. They'd

visited a couple of other companies
designing their own custom silicon. They

got this idea in about 1983. They were
looking at some of the RISC papers coming

out of Berkeley and they were quite
impressed by what a bunch of grad students

were doing. They managed to get a working
RISC processor and they went to Western

Design Center and looked at 6502
successors being design there. They had a

positive experience. They saw a bunch of
high school kids with Apple 2s doing

silicon layout. And they though "OK,
well". They'd never designed a CPU before

at ACORN. ACORN hadn't done any custom
silicon to this degree, but they were

buoyed by this and they thought, okay,
well, maybe RISC is the secret and we can

do this. And this was not really the done
thing in this timeframe and not for a

company the size of ACORN, but they
designed their computer from scratch. They

designed all of the major pieces of
silicon in this machine. And it wasn't

about designing the ARM chip. Hey, we've
got a processor core. What should we do

with it? But it was about designing the
machine that ARM and the history of that

company has kind of benefited from. But
this is all about designing the machine as

a whole. They're a tiny team. They're a
handful of people - about a dozen...ish

that did the hardware design, a similar
sort of order for software and operating

systems on top, which is orders of
magnitude different from IBM and Motorola

and so forth that were designing computers
at this time. RISC was the key. They

needed to be incredibly simple. One of the
other experiences they had was they went

to a CISC processor design center. They
had a team in a couple of hundred people

and they were on revision H and it still
had bugs and it was just this unwieldy,

complex machine. So RISC was the secret.
Steve Ferber has an interview somewhere.

He jokes about ACORN management giving him
two things. Special sauce was two things

that no one else had: He'd no people and
no money. So it had to be incredibly

simple. It had to be built on a
shoestring, as Jamie said to me. So there

are lots of corners cut, but in the right
way. I would say "corners cut", that

sounds ungenerous. There's some very
shrewd design decisions, always weighing

up cost versus benefit. And I think they
erred on the correct side for all of them.

So Steve sent me this picture. That's he's
got a cameo here. That's the outline of

him in the reflection on the glass there.
He's got this up in his office. So he

led the hardware design of all of these
chips at ACORN. Across the top, we've got

the original ARM, the ARM 1, ARM 2 and the
ARM 3 - guess the naming scheme - and the

video controller, memory controller and IO
controller. Think, sort of see their

relative sizes and it's kind of pretty.
This was also on a processor where you

could really point at that and say, "oh,
that's the register file and you can see

the cache over there". You can't really do
that nowadays with modern processors. So

the bit about the specification, what it
could do, the end product. So I mentioned

they all had this ARM 2 8MHz, up to four
MB of RAM, 26-bit addresses, remember

that. That's weird. So a lot of 32-bit
machines, had 32-bit addresses or the ones

that we know today do. That wasn't the
case here. And I'll explain why in a

minute. The A540 had a updated CPU. The
memory controller had an MMU, which was

unusual for machines of the mid 80s. So it
could support, the hardware would support

virtual memory, page faults and so on. It
had decent sound, it had 8-channel sound,

hardware mixed and stereo. It was 8 bit,
but it was logarithmic - so it was a bit

like u-law, if anyone knows that - instead
of PCM, so you got more precision at the

low end and it sounded to me a little bit
like 12 bit PCM sound. So this is quite

good. Storage wise, it's the same floppy
controller as the Atari S.T.. It's fairly

boring. Hard disk controller was a
horrible standard called ST506, MFM

drives, which were very, very crude
compared to disks we have today. Keyboard

and mouse, nothing to write home about. I
mean, it was a normal keyboard. It was

nothing special going on there. And
printer port, serial port and some

expansion slots which, I'll
outline later on. The thing I really liked

about the ARC was the graphics
capabilities. It's fairly capable,

especially for a machine of that era and
of the price. It just had a flat frame

buffer so it didn't have sprites, which is
unfortunate. It didn't have a blitter and

a bitplanes and so forth. But the upshot
of that is dead simple to program. It had

a 256 color mode, 8 bits per pixel, so
it's a byte, and it's all just laid out as

a linear string of bytes. So it was dead
easy to just write some really nice

optimized code to just blit stuff to the
screen. Part of the reason why there isn't

a blitter is actually the CPU was so good
at doing this. Colorwise, it's got

paletted modes out of a 4096 color
palette, same as the Amiga. It has this

256 color mode, which is different. The
big high end machines, the top end

machines, the A540 and the A400 series
could also do this very high res 1152 by

900, which was more of a workstation
resolution. If you bought a Sun

workstation a Sun 3 in those days, could
do this and some higher resolutions. But

this is really not seen on computers that
might have in the office or school or

education at the end of the market. And
it's quite clever the way they did that.

I'll come back to that in a sec. But for
me, the thing about the ARC: For the

money, it was the fastest machine around.
It was definitely faster than 386s and all

the stuff that Motorola was doing at the
time by quite a long way. It is almost

eight times faster than a 68k at about the
same clock speed. And it's to do with it's

pipelineing and to do with it having a 32
bit word and a couple of other tricks

again. I'll show you later on what the
secret to that performance was. About

minicomputer speed and compared to some of
the other RISC machines at the time, it

wasn't the first RISC in the world, it was
the first cheap RISC and the first RISC

machine that people could feasibly buy and
have on their desks at work or in

education. And if you compare it to
something like the MIPS or the SPARC, it

was not as fast as a MIPS or SPARC chip.
It was also a lot smaller, a lot cheaper.

Both of those other processers had very
big Die. They needed other support chips.

They had huge packages, lots of pins, lots
of cooling requirements. So all this

really added up. So I priced up
a Sun 4 workstation at the time and

it was well over four times the price of
one of these machines. And that was before

you add on extras such as disks and
network interfaces and things like that.

So it's very good, very competitive for
the money. And if you think about building

a cluster, then you could get a lot more
throughput, you could network them

together. So this is about as far as I got
when I was a youngster, I was wasn't brave

enough to really take the machine apart
and poke around. Fortunately, now it's 30

years old and I'm fine. I'm qualified and
doing this. I'm going to take it apart.

Here's the motherboard. Quite a nice clean
design. This was built in Wales for anyone

that's been to the UK. Very unusual these
days. Anything to be built in the UK. It's

got several main sections around these
four chips. Remember the Steve photo

earlier on? This is the chip set: the ARM
BMC, PDC, IOC. So the IOC side of things

happens over on the left video and sound
in the top right. And the memory and the

processor in the middle. It's got a
megabyte onboard and you can plug in an

expansion for 4 MB. So memory map
from the software view. I mentioned this

26-bit addressing and I think this is one
of the key characteristics of one of these

machines. So you have a 64MB address
space, it's quite packed. That's quite a

lot of stuff shoehorned into here. So
there's the memory. The bottom half of the

address space, 32MB of that is the
processor. It's got user space and

privilege mode. It's got a concept of
privilege within the processor execution.

So when you're in user mode, you only get
to see the bottom half and that's the

virtual maps. There's the MMU, that will
map pages into that space and then when

you're in supervisor mode, you get to see
the whole of the rest of the memory,

including the physical memory and various
registers up the top. The thing to notice

here is: there's stuff hidden behind the
ROM, this address space is very packed

together. So there's a requirement
for control registers, for the memory

controller, for the video controller and
so on, and they write only registers in

ROM basically. So you write to the ROM and
you get to hit these registers. Kind of

weird when you first see it, but it was
quite a clever way to fit this stuff into

the address space. So it will start with
the ARM1. So Sophie Wilson designed the

instruction set late 1983, Steve took the
instruction set and designed the top

level, the block, the micro architecture
of this processor. So this is the data

path and how the control logic works. And
then the VLSI team, then implemented this,

did their own custom cells. There's a
custom data path and custom logic

throughout this. It took them about a
year, all in. Well, 1984, that sort of...

This project A really kicked off early
1984. And this staked out first thing

early 1985. The design process the guys
gave me a little bit of... So Jamie

Urquhart and John Biggs gave me a bit of
an insight into how they worked on the

VLSI side of things. So they had an Apollo
workstation, just one Apollo workstation,

the DN600. This is a 68K based washing
machine, as Jamie described it. It's this

huge thing. It cost about 50˙000 £.
It's incredibly expensive. And they

designed all of this with just one of
these workstations. Jamie got in at 5:00

a.m., worked until the afternoon and then
let someone else on the machine. So they

shared the workstation, they worked
shifts so that they could design this

whole thing on one workstation. So this
comes back to that. It was designed on a

bit of a shoestring budget. When they got
a couple of other workstations later on in

the projects, there was an allegation that
the software might not have been licensed

initially on the other workstations and
the CAD software might have been. I can

neither confirm nor deny whether that's
true. So Steve wrote a BBC Basic

simulator for this. When he's designing
this block level micro architecture run on

his BBC Micro. So this could then run real
software. There could be a certain amount

of software development, but then they
could also validate that the design was

correct. There's no cache on this. This is
a quite a large chip. 50 square

millimeters was the economic limit of
those days for this part of the market.

There's no cache. That also would have
been far too complicated. So this was

also, I think, quite a big risk, no pun
intended. The aim of doing this

with such a small team that they're all
very clever people. But they hadn't all

got experience in building chips before.
And I think they knew what they were up

against. And so not having a cache of
complicated things like that was the right

choice to make. I'll show you later that
that didn't actually affect things. So

this was a RISC machine. If anyone has not
programmed ARM in this room then get out

at once. But if you have programed ARM
this is quite familiar with some

differences. It's a classical three
operand RISC, its got three shift on one of

the operands for most of the instructions.
So you can do things like static

multiplies quite easily. It's not purist
RISC though. It does have load or store

multiple instructions. So these will, as
the name implies, load or store multiple

number of registers in one go. So one
register per cycle, but it's all done

through one instruction. This is not RISC.
Again, there's a good reason for doing

that. So when one comes back and it gets
plugged into a board that looks a bit like

this. This is called the A2P, the ARM second
processor. It plugs into a BBC Micro. It's

basically there's a thing called the Tube,
which is sort of a FIFO like arrangement.

The BBC Micro can send messages one way
and this can send messages back. And the

BBC Micro has the discs, it has the I/O,
keyboard and so on. And that's used as the

hosts to then download code into one
megabytes of RAM up here and then you

combine the code on the ARM. So this was
the initial system, 6 MHz. The

thing I found quite interesting about
this, I mentioned that Steve had built

this BBC Basic simulation, one of the
early bits of software that could run on

this. So he'd ported BBC Basic to ARM and
written an ARM version of it. The Basic

interpreter was very fast, very lean, and
it was running on this board early on.

They then built a simulator called ASIM,
which was an event based simulator for

doing logic design and all of the other
chips in the chips on the chipset that

were simulated using ASIM on ARM1 which is
quite nice. So this was the fastest

machine that they had around. They didn't
have, you know, the thousands of machines

in the cluster like you'd have in a
modern company doing EDA. They had

a very small number of machines and these
were the fastest ones they had about. So

ARM2 was simulated on ARM1 and all the
other chipset. So then ARM2 comes along.

So it's a year later, this is a shrink of
the design. It's based on the same basic

micro architecture but has a multiplier
now. It's a booth multiplier , so it is at

worst case, 16 cycle, multiply just two
bits per clock. Again, no cache. But one

thing they did add in on to is banked
registers. Some of the processor modes I

mentioned there's an interrupt mode. Next
slide, some of the processor modes will

basically give you different view on
registers, which is very useful. These

were all validated at 8 MHz. So
the product was designed for 8 MHz.

The company that built them
said, okay, put the stamp on the outside

saying 8 MHz. There's two
versions of this chip and I think they're

actually the same silicon. I've got a
suspicion that they're the same. They just

tested this batch saying that works at 10
or 12. So on my project list is

overclocking my A3000 to see how fast
it'll go and see if I can get it to 12 MHz.

Okay. So the banking of the registers.
ARM has got this even modern 32 bit

type of interrupts and an IRQ
pronounced "erk" in English and FIQ

pronounced "fic" in English. I appreciate it
doesn't mean quite the same thing in

German. So I call if FIQ from here on in
and FIQ mode has this property where

the top half of the registers are effectively
different registers when you get into

this mode. So this lets you first of all
you don't have to back up those registers.

I mean your FIQ handler. And
secondly if you can write an FIQ handler

using just those registers and there's
enough for doing most basic tasks, you

don't have to save and restore anything
when you get an interrupt. So this is

designed specifically to be very, very low
overhead interrupt mode. So I'm coming to

why there's a 26 bit address space. And so
I found this link very unintuitive. So

unlike 32 bit ARM, the more modern
1990s onwards ARMs, the program counter

register 15 doesn't just contain the
program counter, but also contains the

status flags and processor mode and
effectively all of the machine state is

packed in there as well. So I asked the
question, well why, why 64 megabytes of

address space? What's special about 64.
And Mike told me, well, you're asking the

wrong question. It's the other way round.
What we wanted was this property that all

of the machine state is in one register.
So this means you just have to save one

register. Well, you know, what's the harm
in saving two registers? And he reminded

me of this FIQ mode. Well, if you're
already in a state where you've really

optimized your interrupt handler so that
you don't need any other registers to deal

with, you're not saving restoring anything
apart from your PC, then saving another

register is 50 percent overhead on that
operation. So that was the prime motivator

was to keep all of the state in one word.
And then once you take all of the flags

away, you're left with 24 bits for a word
aligned program counter, which leads to

26 bit addressing. And that was then seen
as well, 64 MB is enough. There were

machines in 1985 that, you know, could
conceivably have more memory than that.

But for a desktop that was still seen as a
very large, very expensive amount of

memory. The other thing, you don't need to
reinvent another instruction to do

return from exception so you can return
using one of your existing instructions.

In this case, it's the subtract into PC
which looks a bit strange, but trust me,

that does the right thing. So the memory
controller. This is - I mentioned the

address translation, so this has an MMU in
it. In fact, the thing directly on the

left hand side. I was
worried that these slides actually might

not be the right resolution and they might
be sort of too small for people to see

this. And in fact, it's the size of a
house is really useful here. So the left

hand side of this chip is the MMU. This
chip is the same size as ARM2. Yeah,

pretty much. So that's part of the reason
why the MMU is on another chip ARM2 was

as big as they could make it to fit the
price as you don't have anyone here done

silicon design. But as the area goes
up effectively your yield goes down and

the price it's a non-linear effect on
price. So the MMU had to be on a separate

chip and it's half the size of that as
well. MEMC does most mundane things

like it drives DRAM, it does refresh for
DRAM and it converts from linear addresses

into row and column addresses which DRAM
takes. So the key thing about this

ARM and MEMC binding is the key factor of
performance is making use of memory

bandwidth. When the team had looked at all
the other processors in Project A before

designing their own, one of the things
they looked at was how well they utilized

DRAM and 68K and the semi chips made very,
very poor use of DRAM bandwidth.

Steve said, well, okay. The DRAM is the
most expensive component of any of these

machines and they're making poor use of
it. And I think a key insight here is if

you maximize that use of the DRAM, then
you're going to be able to get much higher

performance in those machines. And so it's
32 bits wide. The ARM is pipelined, so it can

do a 32 bit word every cycle. And it also
indicates whether it's sequential or non

sequential addressing. This
then lets your MEMC

decide whether to do an N cycle or an S
cycle. So there's a fast one and a slow

one basically. So when you access a new
random address and DRAM, you have to open

that row and that takes twice the time.
It's a 4 MHz cycle. But then once

you've access that address and then once
you're accessing linearly ahead of that

address, you can do fast page mode
accesses, which are 8 MHz cycles.

So ultimately, that's the reason
why these load store multiples exist. The

non-RISC instructions, they're there so
that you can stream out registers and back

in and make use of this DRAM bandwidth. So
store multiple. This is just a simple

calculation for 14 registers, you're
hitting about 25 megabytes a second out of

30. So this is it's not 100%, but it's way
more than a 10th or an 8th.

Which a lot of the other processors
were using. So this was really good. This

is the prime factor of why this machine
was so fast. It's effectively the load store

multiple instructions and being able to
access the stuff linearly. So the MMU is

weird. It's not TLB in the traditional
sense, so TLB's today, if you take your

MIPS chip or something where the TLB is
visible to software, it will map a virtual

address into a chosen physical address and
you'll have some number of entries and you

more or less arbitrarily, you know, poke
an entry and with the set mapping in it.

The MEMC does it upside down. So it says it's
got a fixed number of entries for every

page in DRAM. And then for each of those
entries, it checks an incoming address to

see whether it matches. So it has all of
those entries that we've showed on the

chip diagram a couple of slides ago. That
big left hand side had that big array. All

of those effectively just storing a
virtual address and then matching it and

have a comparator. And then one of them
lights up and says yes, it's mine. So

effectively, the aphysical page says that
virtual address is mine instead of the

other way round. So this also limits your
memory. If you're saying I have to have

one of these entries on chip per page of
physical memory and you don't want pages

to be enormous. The 32 K if you do the
maths is 4 MB over 128 pages, it's a

32K page. If you don't want the page to
get much bigger than that and trust me you

don't, then you need to add more of these
entries and it's already half the size of

the chip. So effectively, this is one of
the limits of why you can only have 4 MB

on one of these memory
controller chips. OK. So VIDC is the core

of the video and sound system. It's a set
of FIFOs and a set of shift digital analog

converters for doing video and sound. You
stream stuff into the FIFOs and it does

the display timing and pallet lookup and
so forth. It has an 8 bit mode I

mentioned. It's slightly strange. It also
has an output for transparency bit. So in

your palette you can set 12 bits of
color, but you can set a bit of

transparency as well so you can do video
gen- looking quite easily with this. So

there was a revision later on Tudor
explains that the very first one had a bit

of crosstalk between the video and the
sound, so you'd get sound with noise on

it. That was basically video noise and
it's quite hard to get rid of. And so they

did this revision and the way he fixed it
was quite cool. They shuffled the power

supply around and did all the sensible
engineering things. But he also filtered

out a bit of the noise that is being
output on the sound. He

inverted it and then fed that back in as
the reference current for the DACs. So that

sort of self compensating and took the
noise a bit like the noise canceling

headphones. It was kind of a nice hack.
And that was that was VIDC1. OK, the final

one, I'm going to stop showing you chip
plots after this, unfortunately, but just

get your fill while we're here. And again,
I'm really glad this is enormous for the

people in the room and maybe those zooming
in online. There's a cool little

Illuminati eye logo in the bottom left
corner. So I feared that you weren't gonna

be able to see and I didn't have time to
do zoomed in version, but. Okay. So IOC

is the center of the IO system as much of
the IO system as possible, all the random

bits of glue logic to do things like
timing. Some peripherals are slower than

others lives in IOC. It contains a UART
for the keyboard, so the keyboard is

looked after by an 8051 microcontroller. Just
nice and easy, you don't have to do scanning

in software. This microcontroller just sends
stuff up of serial port to this chip. So

UART keyboard, asynchronous receiver and
transmitter. It was at one point called

the fast asynchronous receiver and
transmitter. Mike got forced to change the

name. Not everyone has a 12 year old sense
of humor, but I admire his spirit. So the

other thing it does is interrupts all the
interrupts go into IOC and it's got masks

and consolidates them effectively for
sending an interrupt up to the on the ARM.

The ARM can then check the status and do
fast response to it. So the eye of providence

there, the little logo I pointed out, Mike
said he put that in for future

archaeologists to wonder about. Okay.
That was it. I was hoping there'd be

this big back story about, you know, he
was in the Illuminati or something. Maybe

he is, but not allowed to say anyway. So just
like the other dev board I showed you so

this one's A 500 2P, it's still a second
processor that plugs into a BBC Micro.

It's still got this host having disk
drives and so forth attached to it and

pushing stuff down the tube into the
memory here. But now, finally

all of this, the chip set now
assembled in one place. So this is

starting to look like an Archimedes. It
got video out. It's got keyboard

interface. It's got some expansion stuff.
So this is bring up an early software

headstart. But very shortly afterwards, we
got the a five A500 internal to Acorn. And

this is really the first Archimedes. This
is the prototype Archimedes. Actually got

a gorgeous gray brick sort of look to it,
kind of concrete. It weighs like concrete,

too, but it has all the hallmarks. It's
got the IO interfaces, it's got the

expansion slots. You can see at the back.
It's got all, it runs the same operating

system. Now, this was used for the OS
development. There's only a couple of

hundred of these made. Well, this is a
serial 222. So this is one of the last,

I think. But yeah. Only an internal to
ACORN. There are lots of nice tweaks to this

machine. So the hardware team had designed
this, Tudor designed this as well as the

video system. And he said, well, his A500
was the special one that he had a video

controller. He'd hand-picked one
of the VCs so that instead of running

at 24 MHz to run at 56, so some silicon
variations in manufacturer. So he found a

56 MHz part so he could do. I
think it was 1024 x 768, which is way out

of respect for the rest of the Archimedes.
So he had the really, really cool machine.

They also ran some of them at 12 MHz
as well instead of 8. This is a massive

performance improvement. I think it used
expensive memory, which is kind of out of

reach for the product. Right. So
believe me, this is the simplified

circuit diagram. The technical reference
manuals are available online if anyone wants

the complicated one. The main parts of the
display are ARM, MEMC, VIDC and some RAM

and we have a little walk through them. So
the clocks are generated actually by the

memory controller. Memory controller gives
the clocks to the ARM. The main reason for

this is that the memory controller has to
do some slow things now and then. It has

to open pages of DRAMs, refresh cycles and
things. So it stops the CPU and generates

the clock and it pauses the CPU by
stopping that clock from time to time.

When you do a DRAM access, your adress on
bus along the top, the ARM outputs an

address that goes into the MEMC. The
MEMC then converts that, it does an address

translation and then it converts that into
a row and column addresses suitable for

DRAM. And then if you're doing a read
DRAM outputs the address, outputs the data

onto the data bus, which ARM then sees.
MEMC is the the critical path on

this, but the address flows through MEMC
effectively. Notice that MEMC is not on

the data bus. It just gets addresses
flowing through it, this is important later

on. ROM is another slow thing.

Another reason why MEMC might slow down
the access from the CPU, it works in a

similar sort of way. There is also a
permission check done when you're doing

the address translation per... user
permission versus OS, a supervisor.

And so this information is output as part
of the cycle when the ARM does that access.

If you miss in that translation, you get
a page fault or permission fault, then an

abort signal comes back and you
take an exception.

And the ARM deals with that in software.

The data bus is a critical path, and so
the IO stuff is buffered, it is kept away

from that. So the IO bus is 16 bits and
not a lot 32 bit peripherals were around

in those days. All the peripherals 8 or
16 bits. So that's the right thing to do.

The IOC decodes that and there's a
handshake with MEMC. If it needs more

time, if it's accessing one of the
expansion cards and the expansion card

has something slow on it then that's dealt
with in the IOC. So I mentioned the

interrupt status that gets funneled into
IOC and then back out again. There's a

VSync interrupt, but not an HSync
interrupt. You have to use timers for that,

really annoyingly. There's one timer and
there's a 2 MHz timer available. I

think I had that in a previous slide,
forgot to mention it. So if you want to

do funny palette switching stuff or copper
bars or something - that's possible with the

timers, it's also simple hardware mod to
make a real HSync interrupt as well.

There's some spare interrupt inputs on the
IOC as an exercise for you . So the bit I

really like about this system, I mentioned
that MEMC is not on the data bus. The VIDC

is only on the data bus and it doesn't
have an address bus either. The VIDC is the

thing responsible for turning the frame
buffer into video, reading that frame

buffer out of RAM, so on. So how does it
actually do that RAM read without the

address? Well, the MEMC contains all of
the registers for doing this DMA: the

start of the frame buffer, the current
position and size, and so on. They all

live in the MEMC. So there's a handshake
where VIDC sends a request up to the MEMC.

When it's FIFO gets low, the MEMC then
actually generates the address into the

DRAM, DRAM outputs that data and
then the MEMC, gives an acknowledge

to the ARM Excuse me - too many
chips. The MEMC gives an acknowledged to

VIDC, which then latches that data
into the FIFO. So this partitioning is

quite neat. A lot of the video, DMA.
The video DMA stuff all lives in MEMC and

there's this kind of split across the two
chips. The sound one I've just

highlighted one interrupt that comes from
MEMC. Sound works exactly the same way,

except there's a double buffering scheme
that goes on. And when one half of it

becomes empty, you get an interrupt so you
can refill that so you don't glitch your

sound. So this all works really very
smoothly. So finally the high res- mono

thing that I mentioned before is quite
novel way they did that. Tudor had realized

that with one external component to the
shift register and running very fast, he

could implement this very high resolution
mode without really affecting the rest of

the chip. So VIDC still runs at
24 MHz to sort of VGA resolution. It

outputs on a digital bus that was a test
board, originally. It outputs 4 bits. So 4

pixels in one chunk at 24 MHz and
this external component then shifts

through that 4 times the speed. There's
one component. I mean, this is a

very cheap way of doing this. And as I
said, this high res- mode is very

unusual for machines of this era.
I've got a feeling an A500 the top end

machine, if anyone's got one of these and
wants to try this trick and please get in

touch, I've got a feeling an
A500 will do 1280 x 1024 by

overclocking this. I think all of the
parts survive it. But for some reason,

ACORN didn't support that on the board.
And finally, clock selection VIDC on

some of the machines, quite flexible set
of clocks for different resolutions,

basically. So MEMC is not on the data bus.
How do we program it? It's got registers

for DMA and it's got all this address
translation. So the memory map I showed

before has an 8 MB space reserved for
the address translation registers. It

doesn't have 8 MB of it. I mean,
doesn't have two million... 32 bit registers

behind there, which is a hint of what's
going on here. So what you do is you write

any value to this space and you encode the
information that you want to put into one

of these registers in the address. So this
address, the top three bits are 1 - it's

in the top 8 MB of the 64 MB
address space and you format your

logical physical page information in this
address and then you write any byte

effectively. This sort of feels
really dirty, but also really a very nice

way of doing it because there's no other
space in the address map. And this reads

to the the price balance. So it's not
worth having an address bus going into

MEMC costing 32 more pins just to write
these registers as opposed to playing this

sort of trick. If you have that address
bus just for that data bus, just for

that, then you have to get to a more
expensive package. And this was

really in their minds: a 68 pin chip
versus an 84 pin chip. It was a big deal.

So everything they really strived
to make sure it was in the very smallest

package possible. And this system
partitioning effort led to these sorts of

tricks to then program it. So on the
A540, we get multiple MEMCs. Each one is

assigned a colored stripe here of the
physical address space. So you have a

16 MB space, each one looks after
4 MB of it. But then when you do a

virtual access in the bottom half of the
user space, regular program access, all of

them light up and all of them will
translate that address in parallel. And

one of them hopefully will translate and
then energize the RAM to do the read, for

example. When you put an ARM 3 in this
system, the ARM 3 has its cache and then

the address leads into the MEMC. So then
that means that the address is being

translated outside of the cache or after
the cache. So your caching virtual

addresses and as we all know, this is kind
of bad for performance because whenever

you change that virtual address space, you
have to invalidate your cache. Or tag it,

but they didn't do that. There's other ways
of solving this problem. Basically on this

machine, what you need to do is invalidate
the whole cache. It's quite a quick

operation, but it's still not good for
performance to have an empty cache. The

only DMA present in the system is for the
video, for the video and sound. I/O

doesn't have any DMA at all. And this is
another area where as younger engineer

"crap, why didn't they have DMA? That
would be way better." DMA is the solution

to everyone's problems, as we all know.
And I think the quote on the right

ties in with the ACORN team's discovery
that all of these other processes needed

quite complex chipsets, quite expensive
support chips. So the quote on the right

says that if you've got some chips, that
vendors will be charging more for their

DMA devices even than the CPU. So not
having dedicated DMA engine on board is a

massive cost saving. The comment I made on
the previous 2 slides about the system

partitioning, putting a lot of attention
into how many pins were on one chip versus

another, how many buses were going around
the place. Not having IOC having to access

memory was a massive saving in cost for
the number of pins and the system as a

whole. The other thing is the FIQ mode
was effectively the means for doing IO.

Therefore, FIQ Mode was designed to be an
incredibly low overhead way of doing

programed IO, having the CPU do the
IO. So this was saying that the CPU is

going to be doing all of the IO stuff, but
lets just optimize it, let's make it make

it as good as it could be and that's
what led to the programmed IO. I also

remember ARM 2 didn't have a cache. If you
don't have a cache on your CPU then

DMA is going to hold up the CPU anyway,
so no cycles. DMA is not any

performance gain. You may as well get
the CPU to do it and then get the CPU to

do it in the lowest overhead way as possible.
I think this can be summarized as bringing

the "RISC principles" to the system. So
the RISC principle, say for your CPU, you

don't put anything in the CPU that you can
do in software and this is saying, okay,

we'll actually software can do the IO just
as well without a cache as the DMA

system. So let's get software to do that.
And I think this is a kind of a nice way

of seeing it. This is part of the cost
optimization for really very little

degradation in performance compared to
doing in hardware. So this is an IO card.

The euro cards then nice and easy. The
only thing I wanted to say here was this

is my SCSI card and it has a ROM on the
left hand side. And so. This is the

expansion ROM basically many, many years
before PCI made this popular. Your drivers

are on this ROM. This is a SCSI disc
plugging into this and you can plug this

card in and then boot off the disk. You
don't need any other software to make it

work. So this is just a very nice user
experience. There is no messing around

with configuring IO windows or interrupts
or any of the iSCSI sort of stuff that was

going on at the time. So to summarize some
of the the hardware stuff that we've seen,

the ARM is pipelined and it has the load-
store-multiple -instructions which make

for a very high bandwidth utilization.
That's what gives it its high performance.

The machine was really simple. So
attention to detail about separating,

partitioning the work between the chips
and reducing the chip cost as much as

possible. Keeping that balanced was really
a good idea. The machine was designed when

memory and CPUs were about the same speed.
So this is before that kind of flipped

over. An 8 MHz ARM 2 was
designed to use 8 MHz memory.

There's no need to have a cache at all on
there these days it sounds really crazy

not to have a cache on the CPU, but if your
memory is not that much slower than this

is a huge cost saving, but it is also risk
saving. This was the first real proper CPU.

If we don't count ARM 1 to say ARM 1 was a
test, but ARM 2 is that, you know, the

first product CPU. And having a cache on
that would have been a huge risk for a

design team that hadn't dealt with the
structures that complicated at that

point. So that was the right
thing to do, I think

and I talked about DMA. I'm actually

converse on this. I thought this was crap.
And actually, I think this was a really

good example of balanced design. What's
the right tool for the job? Software is

going to do the IO, so let's make sure
that FIQ mode, it makes sure that

there's low overhead as possible. We
talked about system partitioning. The MMU.

I still think it's weird and
backward. I think there is a

strong argument though that a more
familiar TLB is a massively complicated

compared to what they did here. And I
think the main drive here was not just

area on the chip, but also to make it much
simpler to implement. So it worked. And I

think this was they really didn't have
that many shots of doing this. This wasn't

a company or a team that could afford to
have many goes at this product. And I

think that says it all. I think they did a
great job. Okay. So the OS story is a

little bit more complicated. Remember,
it's gonna be this office automation

machine a bit like a Xerox star. Was going
to have this wonderful high res mono mode

and people gonna be laser printing from
it. So just like Xerox PARC, Acorn started

Palo Alto based research center.
Californians and beanbags writing an

operating system using a micro kernel in
Modula-2 all of the trendy boxes ticked

here for the mid 80s. It was by the sounds
a very advanced operating system and it

did virtual memory and so on, is very
resource hungry, though. And it was never

really very performant. Ultimately, the
hardware got done quicker than the

software. And after a year or two.
Management got the jitters. Hardware was

looming and said, well, next year we're
going to have the computer ready. Where's

the operating system? And the project got
canned. And this is a real shame. I'd love

to know more about this operating system.
Virtually nothing is documented outside of

Acorn. Even the people, I spoke to, didn't
work on this. A bunch of people in

California that kind of disappeared with
it. So if anyone has this software

archived anywhere, then get in touch.
Computer Museum around the corner from me

is raring to go on that. That'll be really
cool thing to archive. So anyway, they

had now a desperate situation. They had to
go to Plan B, which was in under a year write

an operating system for the machine
that was on its way to being delivered.

And it kind of shows Arthur was I mean, I
think the team did a really good job in

getting something out of the door in half
a year, but it was a little bit flaky.

RISC OS then a year later, developed
from Arthur. I don't know if anyone's

heard of RISC OS, but Arthur is
very, very niche and basically got

completely replaced by RISC OS because
it was a bit less usable than RISC OS.

Another really strong point that this
had it's quite a big ROM. So 2 MB going

up...sorry, 0,5 MB in the 80s going
up to 2 MB in the early 90s.

There's a lot of stuff in ROM. One of
those things is BBC Basic 5. I know

it's 2019, and I know Basic is basic, but
BBC Basic is actually quite good. It has

procedures and it's got support for all
the graphics and sound. You could write GUI

applications in Basic and a lot of people
did. It's also very fast. So Sophie Wilson

wrote this very, very optimized Basic
interpreter. I talked about the modules

and podules. This is the expansion
ROM things. And a really great user

experience there. But speaking of user
experience, this was ARTHUR . I never used

ARTHUR. I just dug out a ROM and had a
play with it. It's bloody horrible. So that

went away quickly. At the time also. So
part of this emergency plan B was to take

the Acorn soft team who were supposed to
be writing applications for this and get

them to quickly knock out an operating
system. So at launch, basically, this is

one of the only things that you could do
with the machine. Had a great demo called

Lander, of a great game called Zarch,
which is 3D space. You could fly around,

it didn't have serious business
applications. And, you know, it was very

there was not much you could do with this
really expensive machine at launch and

that really hurt it, I think. So let me
get RISC OS 2 in 1988 and this is now

looking less like a vomit sort of thing,
much nicer machine. And then eventually

RISC OS 3. It was drag and drop between
applications. It's all multitasking,

does outline font anti aliasing
and so on. So just lastly, I want to

quickly touch on the really interesting
operating systems that ACORN had a Unix

operating system. So as well as being a
geek, I'm also UNIX geek and I've always

been fascinated by RISCiX. These machines
are astonishingly expensive. They were

the existing Archimedes machines with a
different sticker on. So that's A540 with

a sticker on the front. And this OS
was developed after the Archimedes was

already designed at that point when this
OS was being developed. So

there's a lot of stuff about the hardware
that wasn't quite right for a Unix

operating system. 32K page size on a 4
megabyte machine really, really killed you

in terms of your page cache and and that
kind of thing. They turned this into a bit

of an opportunity. At least they made good
on some of this. There was a quite a novel

online decompression scheme for you to
demand a page- text from a binary

and it would decompress into your 32K
page, but it was stored in a

sparse way on disk. So actually on disk
use was a lot less than you'd expect. The

only way it fit on some of the
smaller machines.

Also Acorn TechL the department that
designed the cyber truck it turns out.

This was their view of the A680,
which is an unreleased workstation.

I love this picture.
I like that piece of cheese or

cake as the mouse. That's my favorite
part. But this is the real machine. So

this is an unreleased prototype I found at
the computer museum. It's notable. And

it's got 2 MEMCs. It's got a 8MB of
RAM. It's only designed to run RISC iX,

the Unix operating system and has highres
monitor only doesn't have color, who's

designed to run frame maker and driver
laser printers and be a kind of desktop

publishing workstation. I've always been
fascinated by RISC iX, as I said a while

ago I hacked around on ArcEm for a while.
I got it booting in ArcEm. I'd never seen

this before. I never used a RISC iX
machine. So there we go, it boots, it is

multi-user. But wait, there's more. It has
a really cool X-Server, a very fast one. I

think Sophie Wilson again worked on
the X server here. So it's very well

optimized and very fast for a machine of
its era. And it makes quite a nice little

Unix workstation. It's quite a cool little
system, by the way Tudor, the guy that

designed the VIDC and the IO system called
me a sado forgetting this working in

there. That's my claim to fame. Finally,
and I want to leave some time for

questions. There's a lot of useful stuff
in ROM. One of them is BBC Basic. Basic

has an assembler so you can walk up to
this machine with a floppy disk and write

assembler has a special bit of syntax
there and then you can just call it. And

so this is really powerful. So at school
or something with the floppy disk, you can

do something that's a bit more than basic
programing. Bizarrely, I mostly write that

with only two or three tiny syntax errors
after about 20 years away from this. It's

in there somewhere. Legacy wise, the
machine didn't sell very many under a

hundred thousand easily. I don't think it
really made a massive impact. PCs had

already taken off by then. The ARM
processor, not going to go on about the

company. That's clear that that
obviously has changed the world in many

ways. The thing I really took away from
this exercise was that a handful of smart

people. Not that many. No, order of a dozen
designed multiple chips, designed a custom

computer from scratch, got it working. And
it was quite good. And I think that this

really turned people's heads. It made
people think differently that the people

that were not Motorola and IBM really,
really big companies with enormous

resources could do this and could make it
work. I think actually that led to the

thinking that people could design their
systems on the chip in the 90s and that

market taking off. So I think this is
really key in getting people thinking that

way. It was possible to design your own
silicon. And finally, I just want to thank

the people I spoke to and Adrian and
Jason. Their center of computing history in

Cambridge. If you're in Cambridge, then
please visit there. It's a really cool

museum. And with that, I'll wrap up. If
there's any time for questions, then I'm

getting a blank look. No time for
questions?

Herald: There's about 5 minutes left for
questions.

Matt: Fantastic! Or come up to me afterwards.
I'm happy to chat more about this.

applause
Herald:The first question is for the

Internet. Signal angel, will you?
Well, grab your microphones and get the

first of the audio in the room here. There
that microphone, please ask a question.

Mic1: You mentioned that the system is
making good use of the memory, but how is

that actually not completely being
stalled on memory? Having no cache and

same cycle time for the cache- for the
memory as for the CPU.

M: Good question. So how is it not always
stalled on memory ? I mean. Well, it's

sometimes stalled on memory when you do
something that's non sequential. You have

to take one of the slow cycles. This was
the N cycle. The key is you try and

maximize the amount of time that you're
doing sequential stuff.

So on the ARM 2 you wanted to unroll loops
as much as possible. So you're fetching

your instructions sequentially, right? You
wanted to make as much use of load-store

multiples. You could load single registers
with an individual register load, but it

was much more efficient to pay that cost.
Just once the start of the instruction and

then stream stuff sequentially. So you're
right that it is still stalled sometimes,

but that was still a good
tradeoff, I think, for a system that

didn't have a cache for other reasons.
M1: Thanks.

Herald: Next question is for the Internet.
Signal Angel: Are there any Acorns on

sale right now or if you want to get into
this kind of hardware where do you get it?

Herald: Can you repeat the first sentence,
please? Sorry, the first part.

S: If you want to get into this kind of
hardware right now, if you want to buy it

right now.
M: Yeah, good question. How do you

get hold of one drive prices up on eBay? I
guess I hate to say it. Might be fun to

play around in emulators. Always
perfer that to hack around on the

real thing. Emulators always feel a bit
strange. There are a bunch of really good

emulators out there. Quite complete. Yeah,
I think it just I would just go on

auction sites and try and find one.
Unfortunately, they're not completely

rare. I mean that's the thing, they
did sell. Not quite sure. Exact figure,

but you know, there were tens and tens of
thousands of these things made. So I would

look also in Britain more than elsewhere.
Although I do understand that Germany had

quite a few. If you can get a hold of one,
though, I do suggest doing so. I think

they're really fun to play with.
Herald: OK, next question.

M2: So I found myself looking at the
documentation for the LVM/STM instructions

while devaluing something on ARM just last
week. And just maybe wonder what's your

thought? Are there any quirks of the
Archimedes that have crept into the modern

ARM design and instruction set that you
are aware of?

M: Most of them got purged. So there are
the 26 bits adressing. There was a

couple of strange uses of, there is an XOR
instruction into PC for changing flags. So

there was a great purge when the ARM 6 was
designed and the ARM 6. I should know

this ARM v3. That's got 32 bit addressing
and lost this. These weirdnesses

got moved out.
I can't think of aside from just the

resulting ARM 32 instructions that being
quite quirky and having a lot of good

quirks. This shifted register as sort of a
free thing you can do. For example, you

can add one register to a shifted register
in one cycle. I think that's a good quirk.

So in terms of the inheriting that
instruction set and not changing those

things. Maybe that counts?
Herald: Any further questions? Internet,

any new questions? No? Okay, so in that
case one round of applause for Matt Evans.

M: Thank you.

applause

postroll music

Subtitles created by c3subtitles.de
in the year 2021. Join, and help us!