1
00:00:00,000 --> 00:00:10,770
<i>36c3 preroll music</i>

2
00:00:10,770 --> 00:00:24,929
Herald: Our next talk will be "The
ultimate Arcon Archimedes Talk", in which

3
00:00:24,929 --> 00:00:29,599
there will be spoken about everything
about the Archimedes computer. There's a

4
00:00:29,599 --> 00:00:33,590
promise in advance that there will be no
heureka jokes in there. Give a warm

5
00:00:33,590 --> 00:00:40,790
welcome to Matt Evans.

6
00:00:40,790 --> 00:00:48,320
Matt (M): Thank you. Okay. Little bit of
retro computing first thing in the

7
00:00:48,320 --> 00:00:54,949
morning, sort of. Welcome. My name is Matt
Evans. The Acorn Archimedes was my

8
00:00:54,949 --> 00:00:59,379
favorite computer when I was a small
hacker and I'm privileged to be able to

9
00:00:59,379 --> 00:01:04,780
talk a bit little bit about it with you
today. Let's start with: What is an Acorn

10
00:01:04,780 --> 00:01:08,720
Archimedes? So I'd like an interactive
session, I'm afraid. Please indulge me,

11
00:01:08,720 --> 00:01:15,130
like a show of hands. Who's heard of the
Acorn Archimedes before? Ah, OK, maybe 50,

12
00:01:15,130 --> 00:01:23,090
60 percent. Who has used one? Maybe 10
percent, maybe. Okay. Who has programs -

13
00:01:23,090 --> 00:01:31,100
who has coded on an Archimedes? Maybe
half? Two to three people. Great. Okay.

14
00:01:31,100 --> 00:01:34,180
Three. <i>laughs</i> Okay, so a small
percentage. I don't see these machines as

15
00:01:34,180 --> 00:01:39,650
being as famous as - say the Macintosh or
IBM P.C. And certainly outside of Europe,

16
00:01:39,650 --> 00:01:44,030
they were not that common. So this is kind
of interesting just how many people here

17
00:01:44,030 --> 00:01:49,840
have seen this. So it was the first ARM-
based computer. This is an astonishingly

18
00:01:49,840 --> 00:01:55,530
1980s - I think one of them is drawing,
actually. But they're not just the first

19
00:01:55,530 --> 00:02:01,439
ARM-based machine, but the machine that
the ARM was originally designed to drive.

20
00:02:01,439 --> 00:02:07,230
It's a... Is that a comment for me?
(Mike?)?

21
00:02:07,230 --> 00:02:14,300
I'm being heckled already. It's only slide
two. Let's see how this goes. So it's a

22
00:02:14,300 --> 00:02:18,849
two box computer. It looks a bit like a
Mega S.T. ... to me. Its main unit with

23
00:02:18,849 --> 00:02:26,480
the processor and disks and expansion
cards and so on. Now this is an A3000.

24
00:02:26,480 --> 00:02:31,459
This is mine, in fact, and I didn't bother
to clean it before taking the photo. And

25
00:02:31,459 --> 00:02:34,459
now it's on this huge screen. That was a
really bad idea. You can see all the

26
00:02:34,459 --> 00:02:38,209
disgusting muck in the keyboard. It has a
bit of ink on it, I don't know why. But

27
00:02:38,209 --> 00:02:41,660
this this machine is 30 years old. And
this was luckily my machine, as I said, as

28
00:02:41,660 --> 00:02:45,069
a small hacker. And this is why I'm doing
the talk today. This had a big influence

29
00:02:45,069 --> 00:02:52,540
on me. I'd like to say as a person, but
more as an engineer. In terms of what my

30
00:02:52,540 --> 00:02:57,550
programing experience when I was learning
to program and so on. So I live and work

31
00:02:57,550 --> 00:03:02,040
in Cambridge in the U.K., where this
machine was designed. And through the

32
00:03:02,040 --> 00:03:05,470
funny sort of turn of events, I ended up
there and actually work in the building

33
00:03:05,470 --> 00:03:09,310
next to the building where this was
designed. And a bunch of the people that

34
00:03:09,310 --> 00:03:13,720
were on that original team that designed
this system are still around and

35
00:03:13,720 --> 00:03:18,280
relatively contactable. And I thought this
is a good opportunity to get on the phone

36
00:03:18,280 --> 00:03:21,760
and call them up or go for a beer with a
couple of them and ask them: Why are

37
00:03:21,760 --> 00:03:25,670
things the way they are? There's all sorts
of weird quirks to this machine. I was

38
00:03:25,670 --> 00:03:28,901
always wondering this, for 20 years. Can
you please tell me - why did you do it

39
00:03:28,901 --> 00:03:33,330
this way? And they were really good bunch
of people. So I talked to Steve Ferber,

40
00:03:33,330 --> 00:03:37,790
who led the hardware design, Sophie
Wilson, who was the same with software.

41
00:03:37,790 --> 00:03:43,530
Tudor Brown, who did the video system.
Mike Miller, the IO system. John Biggs and

42
00:03:43,530 --> 00:03:46,489
Jamie Urquhart , who did the silicon
design of silicon, I spoiled one of the

43
00:03:46,489 --> 00:03:49,120
surprises here. There's been some silicon
design that's gone on in building this

44
00:03:49,120 --> 00:03:55,060
Acorn. And they were all wonderful people
that gave me their time and told me a

45
00:03:55,060 --> 00:03:59,550
bunch of anecdotes that I will pass on to
you. So I'm going to talk about the

46
00:03:59,550 --> 00:04:04,520
classic Arc. There's a bunch of different
machines that Acorn built into the 1990s.

47
00:04:04,520 --> 00:04:08,960
But the ones I'm talking about started in
1987. There were 2 models, effectively a

48
00:04:08,960 --> 00:04:16,170
low end and a high end. One had an option
for a hard disk, 20 megabytes, 2300

49
00:04:16,170 --> 00:04:20,700
pounds, up to 4MB of RAM. They all share
the same basic architecture, they're all

50
00:04:20,700 --> 00:04:27,540
basically the same. So the A3000 that I
just showed you came out in 1989. That was

51
00:04:27,540 --> 00:04:30,540
the machine I had. Those again, the same.
It had the memory controller slightly

52
00:04:30,540 --> 00:04:35,970
updated, was slightly faster. They all had
an ARM 2. This was the released version of

53
00:04:35,970 --> 00:04:41,550
the ARM processor designed for this
machine, at 8 MHz. And then finally in

54
00:04:41,550 --> 00:04:47,000
1990, what I call the last of the classic
Arc, Archimedes, is the A540. This was the

55
00:04:47,000 --> 00:04:51,670
top end machine - could have up to 16
megabytes of memory, which a fair bit.

56
00:04:51,670 --> 00:04:57,600
even in 1990. It had a 30 MHz ARM 3. The
ARM 3 was the evolution of the ARM 2, but

57
00:04:57,600 --> 00:05:02,130
with the cache and a lot faster. So this
talk will be centered around how these

58
00:05:02,130 --> 00:05:08,820
these machines work, not the more modern
machines. So around 1987, what else was

59
00:05:08,820 --> 00:05:13,760
was available? This is a random selection
machines. Apologies if your favorite

60
00:05:13,760 --> 00:05:19,280
machine is not on this list. It wouldn't
fit on the slide otherwise. So at the

61
00:05:19,280 --> 00:05:22,110
start of the 80s, we had the exotic things
like the Apple Lisa and the Apple Mac.

62
00:05:22,110 --> 00:05:28,720
Very expensive machines. The Amiga - I had
to put in here. Sort off, relatively

63
00:05:28,720 --> 00:05:32,530
expensive course. The Amiga 500 was, you
know, very good value for money, very

64
00:05:32,530 --> 00:05:37,160
capable machine. But I'm comparing this
more to PCs and Macs, because that was the

65
00:05:37,160 --> 00:05:41,950
sort of, you know, market it was going
for. And although it was an expensive

66
00:05:41,950 --> 00:05:46,790
machine compared to Macintosh, it was
pretty cheap. Next cube on there, I

67
00:05:46,790 --> 00:05:50,260
figured that... I'd heard that they were
incredibly expensive. And actually

68
00:05:50,260 --> 00:05:53,330
compared to the Macintosh, they're not
expensive at all. Oh well, I (don't?) know

69
00:05:53,330 --> 00:05:57,930
which one I would have preferred. So the
first question I asked them - the first

70
00:05:57,930 --> 00:06:04,210
thing they told me: Why was it built? I've
used them in school and as I said, had one

71
00:06:04,210 --> 00:06:08,560
at home. But I was never really quite sure
what it was for. And I think a lot of the

72
00:06:08,560 --> 00:06:11,850
Acorn marketing wasn't quite sure what it
was for either. They told me it was the

73
00:06:11,850 --> 00:06:15,940
successor to the BBC Micro, this 8 bit
machine. Lovely 6502 machine, incredibly

74
00:06:15,940 --> 00:06:20,100
popular, especially in the UK. And the
goal was to make a machine that was 10

75
00:06:20,100 --> 00:06:23,770
times the performance of this. The
successor would be 10 times faster at the

76
00:06:23,770 --> 00:06:29,680
same price. And the thing I didn't know is
they had been inspired. The team Acorn had

77
00:06:29,680 --> 00:06:35,620
seen the Apple Lisa and the Xerox Star,
which comes from the famous Xerox Alto,

78
00:06:35,620 --> 00:06:41,700
Xerox PARC, first GUI workstation in the
70s, monumental machine. They'd been

79
00:06:41,700 --> 00:06:45,290
inspired by these machines and they wanted
to make something very similar. So this is

80
00:06:45,290 --> 00:06:49,480
the same story as the Macintosh. They
wanted to make something that was desktop

81
00:06:49,480 --> 00:06:52,310
machine for business, for office
automation and desktop publishing and that

82
00:06:52,310 --> 00:06:56,270
kind of thing. But I never really
understood this before. So this was this

83
00:06:56,270 --> 00:07:01,650
inspiration came from the Xerox machines.
It was supposed to be obviously a lot more

84
00:07:01,650 --> 00:07:06,680
affordable and a lot faster. So this is
what happens when Acorn marketing gets

85
00:07:06,680 --> 00:07:12,290
hold of this vision. So Xerox Star on the
left is this nice, sensible business

86
00:07:12,290 --> 00:07:15,380
machine. Someone's wearing nice, crisp
suit <i>bumps microphone</i> - banging their

87
00:07:15,380 --> 00:07:20,940
microphone - and it gets turned into the
very Cambridge Tweed version on the right.

88
00:07:20,940 --> 00:07:24,410
It's apparently illegal to program one of
these if you're not wearing a top hat. But

89
00:07:24,410 --> 00:07:29,630
no one told me that when I was a kid. And
my court case comes up next week. So

90
00:07:29,630 --> 00:07:32,240
Cambridge is a bit of a funny place. And
for those that been there, this picture on

91
00:07:32,240 --> 00:07:38,680
the right is sums it all up. So they began
Project A, which was build this new

92
00:07:38,680 --> 00:07:43,240
machine. And they looked at the
alternatives. They looked at the

93
00:07:43,240 --> 00:07:49,560
processors that were available at that
time, the 286, the 68 K, then that semi

94
00:07:49,560 --> 00:07:55,720
32, a 16, which was an early 32 bit
machine, a bit of a weird processor. And

95
00:07:55,720 --> 00:07:58,030
they all had something in common that
they're ridiculously expensive and in

96
00:07:58,030 --> 00:08:03,410
Tudors words a bit crap. They weren't a
lot faster than the BBC Micro. They're a

97
00:08:03,410 --> 00:08:06,620
lot more expensive. They're much more
complicated in terms of the processor

98
00:08:06,620 --> 00:08:10,490
itself. But also the system around them
was very complicated. They need lots of

99
00:08:10,490 --> 00:08:15,400
weird support chips. This just drove the
price up of the system and it wasn't going

100
00:08:15,400 --> 00:08:21,390
to hit that 10 times performance, let
alone at the same price point. They'd

101
00:08:21,390 --> 00:08:24,690
visited a couple of other companies
designing their own custom silicon. They

102
00:08:24,690 --> 00:08:28,090
got this idea in about 1983. They were
looking at some of the RISC papers coming

103
00:08:28,090 --> 00:08:31,180
out of Berkeley and they were quite
impressed by what a bunch of grad students

104
00:08:31,180 --> 00:08:38,070
were doing. They managed to get a working
RISC processor and they went to Western

105
00:08:38,070 --> 00:08:42,570
Design Center and looked at 6502
successors being design there. They had a

106
00:08:42,570 --> 00:08:45,210
positive experience. They saw a bunch of
high school kids with Apple 2s doing

107
00:08:45,210 --> 00:08:48,930
silicon layout. And they though "OK,
well". They'd never designed a CPU before

108
00:08:48,930 --> 00:08:53,310
at ACORN. ACORN hadn't done any custom
silicon to this degree, but they were

109
00:08:53,310 --> 00:08:57,160
buoyed by this and they thought, okay,
well, maybe RISC is the secret and we can

110
00:08:57,160 --> 00:09:02,250
do this. And this was not really the done
thing in this timeframe and not for a

111
00:09:02,250 --> 00:09:06,450
company the size of ACORN, but they
designed their computer from scratch. They

112
00:09:06,450 --> 00:09:09,320
designed all of the major pieces of
silicon in this machine. And it wasn't

113
00:09:09,320 --> 00:09:12,830
about designing the ARM chip. Hey, we've
got a processor core. What should we do

114
00:09:12,830 --> 00:09:16,000
with it? But it was about designing the
machine that ARM and the history of that

115
00:09:16,000 --> 00:09:20,310
company has kind of benefited from. But
this is all about designing the machine as

116
00:09:20,310 --> 00:09:26,710
a whole. They're a tiny team. They're a
handful of people - about a dozent, if -

117
00:09:26,710 --> 00:09:30,990
that did the hardware design, a similar
sort of order for software and operating

118
00:09:30,990 --> 00:09:36,210
systems on top, which is orders of
magnitude different from IBM and Motorola

119
00:09:36,210 --> 00:09:41,880
and so forth that were designing computers
at this time. RISC was the key. They

120
00:09:41,880 --> 00:09:43,893
needed to be incredibly simple. One of the
other experiences they had was they went

121
00:09:43,893 --> 00:09:48,820
to a CISC processor design center. They
had a team in a couple of hundred people

122
00:09:48,820 --> 00:09:52,650
and they were on revision H and it still
had bugs and it was just this unwieldy,

123
00:09:52,650 --> 00:09:58,160
complex machine. So RISC was the secret.
Steve Ferber has an interview somewhere.

124
00:09:58,160 --> 00:10:03,470
He jokes about ACORN management giving him
two things. Special sauce was two things

125
00:10:03,470 --> 00:10:07,810
that no one else had: He'd no people and
no money. So it had to be incredibly

126
00:10:07,810 --> 00:10:14,890
simple. It had to be built on a
shoestring, as Jamie said to me. So there

127
00:10:14,890 --> 00:10:19,760
are lots of corners cut, but in the right
way. I would say "corners cut", that

128
00:10:19,760 --> 00:10:23,220
sounds ungenerous. There's some very
shrewd design decisions, always weighing

129
00:10:23,220 --> 00:10:30,210
up cost versus benefit. And I think they
erred on the correct side for all of them.

130
00:10:30,210 --> 00:10:34,960
So Steve sent me this picture. That's he's
got a cameo here. That's the outline of

131
00:10:34,960 --> 00:10:39,750
him in the reflection on the glass there.
He's got this stuff in his office. So he

132
00:10:39,750 --> 00:10:43,630
led the hardware design of all of these
chips at ACORN. Across the top, we've got

133
00:10:43,630 --> 00:10:50,080
the original ARM, the ARM 1, ARM 2 and the
ARM 3 - guess the naming scheme - and the

134
00:10:50,080 --> 00:10:53,090
video controller, memory controller and IO
controller. Think, sort of see their

135
00:10:53,090 --> 00:10:57,320
relative sizes and it's kind of pretty.
This was also on a processor where you

136
00:10:57,320 --> 00:11:00,930
could really point at that and say, "oh,
that's the register five and you can see

137
00:11:00,930 --> 00:11:06,410
the cache over there". You can't really do
that nowadays with modern processors. So

138
00:11:06,410 --> 00:11:11,670
the bit about the specification, what it
could do, the end product. So I mentioned

139
00:11:11,670 --> 00:11:16,850
they all had this ARM 2 8MHz, up to four
MB of RAM, 26-bit addresses, remember

140
00:11:16,850 --> 00:11:21,670
that. That's weird. So a lot of 32-bit
machines, had 32-bit addresses or the ones

141
00:11:21,670 --> 00:11:25,550
that we know today do. That wasn't the
case here. And I'll explain why in a

142
00:11:25,550 --> 00:11:32,610
minute. The A540 had a updated CPU. The
memory controller, had an MMU, which was

143
00:11:32,610 --> 00:11:39,350
unusual for machines of the mid 80s. So it
could support, the hardware would support

144
00:11:39,350 --> 00:11:45,620
virtual memory, page faults and so on. It
had decent sound, it had 8-channel sound,

145
00:11:45,620 --> 00:11:49,460
hardware mixed and stereo. It was 8 bit,
but it was logarithmic - so it was a bit

146
00:11:49,460 --> 00:11:53,240
like u-law, if anyone knows that - instead
of PCM, so you got more precision at the

147
00:11:53,240 --> 00:11:58,620
low end and it sounded to me a little bit
like 12 bit PCM sound. So this is quite

148
00:11:58,620 --> 00:12:04,840
good. Storage wise, it's the same floppy
controller as the Atari S.T.. It's fairly

149
00:12:04,840 --> 00:12:09,690
boring. Hard disk controller was a
horrible standard called ST506, MFM

150
00:12:09,690 --> 00:12:17,440
drives, which were very, very crude
compared to disks we have today. Keyboard

151
00:12:17,440 --> 00:12:20,440
and mouse, nothing to write home about. I
mean, it was a normal keyboard. It was

152
00:12:20,440 --> 00:12:23,430
nothing special going on there. And
printer port, serial port and some

153
00:12:23,430 --> 00:12:29,380
expansion slots which, all them, I'll
outline later on. The thing I really liked

154
00:12:29,380 --> 00:12:32,650
about the arc was the graphics
capabilities. It's fairly capable,

155
00:12:32,650 --> 00:12:37,800
especially for a machine of that era and
of the price. It just had a flat frame

156
00:12:37,800 --> 00:12:42,170
buffer so it didn't have sprites, which is
unfortunate. It didn't have a blitter and

157
00:12:42,170 --> 00:12:48,680
a bitplanes and so forth. But the upshot
of that is dead simple to program. It had

158
00:12:48,680 --> 00:12:52,320
a 256 color mode, 8 bits per pixel, so
it's a byte, and it's all just laid out as

159
00:12:52,320 --> 00:12:55,890
a linear string of bytes. So it was dead
easy to just write some really nice

160
00:12:55,890 --> 00:12:59,910
optimized code to just blit stuff to the
screen. Part of the reason why there isn't

161
00:12:59,910 --> 00:13:05,090
a blitter is actually the CPU was so good
at doing this. Colorwise, it's got

162
00:13:05,090 --> 00:13:10,620
paletted modes out of a 4096 color
palette, same as the Amiga. It has this

163
00:13:10,620 --> 00:13:16,350
256 color mode, which is different. The
big high end machines, the top end

164
00:13:16,350 --> 00:13:21,290
machines, the A540 and the A400 series
could also do this very high res 1152 by

165
00:13:21,290 --> 00:13:24,060
900, which was more of a workstation
resolution. If you bought a Sun

166
00:13:24,060 --> 00:13:28,560
workstation a Sun 3 in those days, could
do this and some higher resolutions. But

167
00:13:28,560 --> 00:13:32,890
this is really not seen on computers that
might have been the office or school or

168
00:13:32,890 --> 00:13:36,370
education at the end of the market. And
it's quite clever the way they did that.

169
00:13:36,370 --> 00:13:40,450
I'll come back to that in a sec. But for
me, the thing about the ARC: For the

170
00:13:40,450 --> 00:13:45,920
money, it was the fastest machine around.
It was definitely faster than 386s and all

171
00:13:45,920 --> 00:13:49,460
the stuff that Motorola was doing at the
time by quite a long way. It is almost

172
00:13:49,460 --> 00:13:55,250
eight times faster than a 68k at about the
same clock speed. And it's to do with it's

173
00:13:55,250 --> 00:13:57,020
pipelineing and to do with it having a 32
bit word and a couple of other tricks

174
00:13:57,020 --> 00:14:01,790
again. I'll tell you later on what the
secret to that performance was. About

175
00:14:01,790 --> 00:14:04,850
minicomputer speed and compared to some of
the other RISC machines at the time, it

176
00:14:04,850 --> 00:14:09,450
wasn't the first RISC in the world, it was
the first cheap RISC and the first RISC

177
00:14:09,450 --> 00:14:14,020
machine that people could feasibly buy and
have on their desks at work or in

178
00:14:14,020 --> 00:14:19,222
education. And if you compare it to
something like the MIPS or the SPARC, it

179
00:14:19,222 --> 00:14:25,300
was not as fast as a MIPS or SPARC chip.
It was also a lot smaller, a lot cheaper.

180
00:14:25,300 --> 00:14:29,240
Both of those other processers had very
big die. They needed other support chips.

181
00:14:29,240 --> 00:14:33,350
They had huge packages, lots of pins, lots
of cooling requirements. So all this

182
00:14:33,350 --> 00:14:36,180
really added up. So I looked up the price
of the Sun 4 workstation at the time and

183
00:14:36,180 --> 00:14:40,050
it was well over four times the price of
one of these machines. And that was before

184
00:14:40,050 --> 00:14:44,400
you add on extras such as disks and
network interfaces and things like that.

185
00:14:44,400 --> 00:14:47,480
So it's very good, very competitive for
the money. And if you think about building

186
00:14:47,480 --> 00:14:51,070
a cluster, then you could get a lot more
throughput, you could network them

187
00:14:51,070 --> 00:14:56,980
together. So this is about as far as I got
when I was a youngster, I was wasn't brave

188
00:14:56,980 --> 00:15:03,230
enough to really take the machine apart
and poke around. Fortunately, now it's 30

189
00:15:03,230 --> 00:15:07,180
years old and I'm fine. I'm qualified and
doing this. I'm going to take it apart.

190
00:15:07,180 --> 00:15:12,089
Here's the motherboard. Quite a nice clean
design. This is built in Wales for anyone

191
00:15:12,089 --> 00:15:18,190
that's been to the UK. Very unusual these
days. Anything to be built in the UK. It's

192
00:15:18,190 --> 00:15:23,420
got several main sections around these
these four chips. Remember the Steve photo

193
00:15:23,420 --> 00:15:29,470
earlier on? This is the chip set: the arm
BMC, PDC, IOC. So the IOC side of things

194
00:15:29,470 --> 00:15:34,510
happens over on the left video and sound
in the top right. And the memory and the

195
00:15:34,510 --> 00:15:38,399
processor in the middle. It's got a
megabyte onboard and you can plug in an

196
00:15:38,399 --> 00:15:44,210
expansion for four megabytes. So memory
maps and software view. I mentioned this

197
00:15:44,210 --> 00:15:46,930
26-bit addressing and I think this is one
of the key characteristics of one of these

198
00:15:46,930 --> 00:15:52,690
machines. So you have a 64MB address
space, it's quite packed. That's quite a

199
00:15:52,690 --> 00:15:56,980
lot of stuff shoehorned into here. So
there's the memory. The bottom half of the

200
00:15:56,980 --> 00:16:02,040
address space, 32MB of that is the
processor. It's got user space and

201
00:16:02,040 --> 00:16:08,100
privilege mode. It's got a concept of
privilege within the processor execution.

202
00:16:08,100 --> 00:16:11,851
So when you're in user mode, you only get
to see the bottom half and that's the

203
00:16:11,851 --> 00:16:16,250
virtual maps. There's the MMU, that will
map pages into that space and then when

204
00:16:16,250 --> 00:16:18,980
you're in supervisor mode, you get to see
the whole of the rest of the memory,

205
00:16:18,980 --> 00:16:23,610
including the physical memory and various
registers up the top. The thing to notice

206
00:16:23,610 --> 00:16:27,460
here is: there's stuff hidden behind the
ROM, this address space is very packed

207
00:16:27,460 --> 00:16:31,390
together. So there's there's a requirement
for control registers, for the memory

208
00:16:31,390 --> 00:16:34,770
controller, for the video controller and
so on, and they write only registers in

209
00:16:34,770 --> 00:16:39,700
ROM basically. So you write to the ROM and
you get to hit these registers. Kind of

210
00:16:39,700 --> 00:16:43,730
weird when you first see it, but it was
quite a clever way to fit this stuff into

211
00:16:43,730 --> 00:16:50,810
the address space. So it will start with
the ARM one. So Sophie Wilson designed the

212
00:16:50,810 --> 00:16:59,150
instruction sets late 1983, Steve took the
instruction set and designed the top

213
00:16:59,150 --> 00:17:03,100
level, the block, the micro architecture
of this processor. So this is the data

214
00:17:03,100 --> 00:17:08,140
path and how the control logic works. And
then the VLSI team, then implemented this

215
00:17:08,140 --> 00:17:12,420
to their own custom cells. There's a
custom data path and custom logic

216
00:17:12,420 --> 00:17:18,179
throughout this. It took them about a
year, all in. Well, 1984, that sort of...

217
00:17:18,179 --> 00:17:22,760
This project A really kicked off early
1984. And this staked out first thing

218
00:17:22,760 --> 00:17:34,690
early 1985. The design process the guys
gave me a little bit of... So Jamie

219
00:17:34,690 --> 00:17:40,800
Urquhart and John Biggs gave me a bit of
an insight into how they worked on the

220
00:17:40,800 --> 00:17:46,870
VLSI side of things. So they had an Apollo
workstation, just one Apollo workstation,

221
00:17:46,870 --> 00:17:51,990
the DN600. This is a 68K based washing
machine, as Jamie described it. It's this

222
00:17:51,990 --> 00:17:56,970
huge thing. It cost about 50000 pounds.
It's incredibly expensive. And they

223
00:17:56,970 --> 00:18:00,580
designed all of this with just one of
these workstations. Jamie got in at 5:00

224
00:18:00,580 --> 00:18:04,710
a.m., worked until the afternoon and then
let someone else on the machine. So they

225
00:18:04,710 --> 00:18:06,760
shared the workstation that they worked
shifts so that they could design this

226
00:18:06,760 --> 00:18:10,390
whole thing on one workstation. So this
comes back to that. It was designed on a

227
00:18:10,390 --> 00:18:13,660
bit of a shoestring budget. When they got
a couple of other workstations later on in

228
00:18:13,660 --> 00:18:17,760
the projects, there was an allegation that
the software might not have been licensed

229
00:18:17,760 --> 00:18:21,950
initially on the other workstations and
the CAD software might have been. I can

230
00:18:21,950 --> 00:18:28,450
neither confirm nor deny whether that's
true. So Steve wrote a BBC-basics

231
00:18:28,450 --> 00:18:33,300
simulator for this. When he's designing
this block level micro architecture run on

232
00:18:33,300 --> 00:18:38,750
his BBC Micro. So this could then run real
software. There could be a certain amount

233
00:18:38,750 --> 00:18:42,890
of software development, but then they
could also validate that the design was

234
00:18:42,890 --> 00:18:47,480
correct. There's no cache on this. This is
a quite a large chip. 50 square

235
00:18:47,480 --> 00:18:52,820
millimeters was the economic limit of
those days for this part of the market.

236
00:18:52,820 --> 00:18:56,420
There's no cache. That also would have
been far too complicated. So this was

237
00:18:56,420 --> 00:19:03,120
also, I think, quite a big risk, no pun
intended. The the the aim of doing this

238
00:19:03,120 --> 00:19:07,620
with such a small team that they're all
very clever people. But they haven't all

239
00:19:07,620 --> 00:19:11,490
got experience in building chips before.
And I think they knew what they were up

240
00:19:11,490 --> 00:19:15,100
against. And so not having a cache of
complicated things like that was the right

241
00:19:15,100 --> 00:19:21,740
choice to make. I'll show you later that
that didn't actually affect things. So

242
00:19:21,740 --> 00:19:25,030
this was a risk machine. If anyone has not
programed in this room, then get out at

243
00:19:25,030 --> 00:19:29,680
once. But if you have programed on this is
quite familiar with some distance, aehm,

244
00:19:29,680 --> 00:19:36,210
differences. The. It's a classical three
operand risk its got three shift on one of

245
00:19:36,210 --> 00:19:38,790
the operands for most of the instructions.
So you can do things like static

246
00:19:38,790 --> 00:19:43,820
multiplies quite easily. It's not purist
risk though. It does have loads or

247
00:19:43,820 --> 00:19:47,980
multiple instructions. So these will, as
the name implies, load or store multiple

248
00:19:47,980 --> 00:19:51,460
number of registers in one go. So one
register per cycle, but it's all done

249
00:19:51,460 --> 00:19:54,970
through one instruction. This is not risk.
Again, there's a good reason for doing

250
00:19:54,970 --> 00:19:59,300
that. So when one comes back and it gets
plugged into a board that looks a bit like

251
00:19:59,300 --> 00:20:07,400
this. This is called the ATP, the second
processor. It plugs into a BBC Micro. It's

252
00:20:07,400 --> 00:20:11,280
basically there's a thing called the Tube,
which is sort of a FIFO like arrangement.

253
00:20:11,280 --> 00:20:15,780
The BBC Micro can send messages one way
and this can send messages back. And the

254
00:20:15,780 --> 00:20:20,250
BBC Micro has the discs, it has the IO
keyboard and so on. And that's used as the

255
00:20:20,250 --> 00:20:23,960
hosts to then download code into one
megabytes of ram up here and then you

256
00:20:23,960 --> 00:20:30,030
combine the code on the arm. So this was
the initial system, six megahertz. The

257
00:20:30,030 --> 00:20:32,350
thing I found quite interesting about
this, I mentioned that Steve had built

258
00:20:32,350 --> 00:20:37,200
this BBC basic simulation, one of the
early bits of software that could run on

259
00:20:37,200 --> 00:20:41,870
this. So he d ported BBC Basic to arm and
written it on version of it. The basic

260
00:20:41,870 --> 00:20:47,780
interpreter was very fast, very lean, and
it was running on this board early on.

261
00:20:47,780 --> 00:20:51,750
They then built a simulator called ACM,
which was an event based simulator for

262
00:20:51,750 --> 00:20:55,240
doing logic design and all of the other
chips in the chips on the chipset that

263
00:20:55,240 --> 00:20:59,020
were simulated using ACM on one, which is
quite nice. So this was the fastest

264
00:20:59,020 --> 00:21:02,480
machine that they had around. They didn't
have, you know, the thousands of machines

265
00:21:02,480 --> 00:21:08,330
in the cluster like you'd have in a
modern, modern company doing PDA. They had

266
00:21:08,330 --> 00:21:11,370
a very small number of machines and these
were the fastest ones they had about. So

267
00:21:11,370 --> 00:21:17,910
ARM 2 simulated ARM one and all the other
chipset. So then ARM 2 comes on. So

268
00:21:17,910 --> 00:21:21,590
there's a year later, this is a shrink of
the design. It's based on the same basic

269
00:21:21,590 --> 00:21:26,000
micro architecture that has a multiplier
now. It's a booth multiplier , so it is at

270
00:21:26,000 --> 00:21:32,090
worst case, 16 cycle, multiply just two
bits per clock. Again, no cache. But one

271
00:21:32,090 --> 00:21:36,950
thing they did add in on to is banked
registers. Some of the processor modes I

272
00:21:36,950 --> 00:21:42,130
mentioned there's an interrupt mode. Next
slide, some of the processor modes will

273
00:21:42,130 --> 00:21:48,950
basically give you different view on
registers, which is very useful. These

274
00:21:48,950 --> 00:21:51,090
were all validated at eight megahertz. So
the product was designed for eight

275
00:21:51,090 --> 00:21:54,020
megahertz. The company that built them
said, okay, put the stamp on the outside

276
00:21:54,020 --> 00:21:57,681
saying that megahertz. There's two
versions of this chip and I think they're

277
00:21:57,681 --> 00:22:01,390
actually the same silicon. I've got a
suspicion that they're the same. They just

278
00:22:01,390 --> 00:22:05,420
tested this batch saying that works at 10
or 12. So on my project list is

279
00:22:05,420 --> 00:22:12,020
overclocking my 80000 to see how fast
it'll go and see if I can get it to 12

280
00:22:12,020 --> 00:22:18,559
megahertz. Okay. So the banking have the
registers just got this even modern 32.

281
00:22:18,559 --> 00:22:25,280
But arms have got a type of interrupts and
pronounced ERC in English and FIQ I queue

282
00:22:25,280 --> 00:22:28,559
pronounced fic in English. Appreciate. It
doesn't mean quite the same thing in

283
00:22:28,559 --> 00:22:34,290
German. So I call if FIQ from here on in
and if FIQ mode has this property where

284
00:22:34,290 --> 00:22:38,260
the top half of the registers effectively
different registers. When you get into

285
00:22:38,260 --> 00:22:42,670
this mode. So this lets you first of all
you don't have to back up those registers.

286
00:22:42,670 --> 00:22:47,950
Mean if your are an FIQ handler and
secondly if you can write an FIQ handler

287
00:22:47,950 --> 00:22:51,970
using just those registers and there's
enough for doing most basic tasks, you

288
00:22:51,970 --> 00:22:55,940
don't have to save and restore anything
when you get an interrupt. So this is

289
00:22:55,940 --> 00:23:02,510
designed specifically to be very, very low
overhead. Interrupt mode. So I'm coming to

290
00:23:02,510 --> 00:23:08,580
why there's a 26 address base. And so I
found this link very, very unintuitive. So

291
00:23:08,580 --> 00:23:13,520
unlike 32 bit on the more the more modern
1990s onwards ARMs, the program council

292
00:23:13,520 --> 00:23:17,020
register 15 doesn't just contain the
program council, but also contains the

293
00:23:17,020 --> 00:23:20,420
status lags and processor mode and
effectively all of the machines date is

294
00:23:20,420 --> 00:23:24,200
packed in there as well. So I asked the
question, well why, why 64 megabytes of

295
00:23:24,200 --> 00:23:27,700
address space? What's special about 64.
And Mike told me, well, you're asking the

296
00:23:27,700 --> 00:23:31,980
wrong question. It's the other way round.
What we wanted was this property that all

297
00:23:31,980 --> 00:23:35,990
of the machine state is in one register.
So this means you just have to save one

298
00:23:35,990 --> 00:23:40,360
register. Well, you know, what's the harm
in saving two registers? And he reminded

299
00:23:40,360 --> 00:23:43,490
me of this FIQ mode. Well, if you're
already in a state where you've really

300
00:23:43,490 --> 00:23:47,890
optimized your interrupt handler so that
you don't need any other registers to deal

301
00:23:47,890 --> 00:23:51,390
with, you're not saving restoring anything
apart from UPC, then saving another

302
00:23:51,390 --> 00:23:56,000
register is 50 percent overhead on that
operation. So that was the prime motivator

303
00:23:56,000 --> 00:24:00,500
was to keep all of the state in one word.
And then once you take all of the flags

304
00:24:00,500 --> 00:24:04,600
away, you're left with 24 bits for a word
airlines program counter, which leads to

305
00:24:04,600 --> 00:24:09,799
26 addressing. And that was then seen as
well, 64 megs is enough. There were

306
00:24:09,799 --> 00:24:14,690
machines in 1985 that, you know, could
conceivably have more memory than that.

307
00:24:14,690 --> 00:24:19,290
But for a desktop that was still seen as a
very large, very expensive amount of

308
00:24:19,290 --> 00:24:24,450
memory. The other thing, you don't need to
reinvent a another instruction to do and

309
00:24:24,450 --> 00:24:28,170
return from exception so you can return
using one of your existing instructions.

310
00:24:28,170 --> 00:24:32,740
In this case, it's this attract into PCG
which looks a bit strange, but trust me,

311
00:24:32,740 --> 00:24:39,030
that does the right thing. It's a memory
controller. This is I mentioned the

312
00:24:39,030 --> 00:24:43,040
address translation, so this has an MMU in
it. In fact, the thing directly on the

313
00:24:43,040 --> 00:24:46,080
left hand slight left hand side. I was
worried that these slides actually might

314
00:24:46,080 --> 00:24:49,520
not be the right resolution and they might
be sort of too small for people to see

315
00:24:49,520 --> 00:24:53,750
this. And in fact, it's the size of a
house is really useful here. So the left

316
00:24:53,750 --> 00:24:59,110
hand side of this chip is the emu. This
chips the same size as the ARM 2. Yeah,

317
00:24:59,110 --> 00:25:02,380
pretty much. So that's part of the reason
why the MMU is on another chip ARM two was

318
00:25:02,380 --> 00:25:06,610
as big as they could make it to fit the
price as you don't have anyone here done

319
00:25:06,610 --> 00:25:10,810
silicon design. But as the the area goes
up effectively your yield goes down and

320
00:25:10,810 --> 00:25:14,690
the price it's it's a non-linear effect on
price. So the MMU had to be on a separate

321
00:25:14,690 --> 00:25:19,910
chip and it's half the size of that as
well. Means he does most mundane things

322
00:25:19,910 --> 00:25:23,920
like it drives DRAM, it does refresh for
DRAM and it converts from linear addresses

323
00:25:23,920 --> 00:25:33,799
into row and column addresses which DRAM
takes. So the key thing about this, this

324
00:25:33,799 --> 00:25:39,090
ARM and MMC binding is the key factor of
performance is making use of memory

325
00:25:39,090 --> 00:25:43,740
bandwidth. When the team had looked at all
the other processors in Project A before

326
00:25:43,740 --> 00:25:49,380
designing their own, one of the things
they looked at was how well they utilized

327
00:25:49,380 --> 00:25:56,320
DRAM and 68K and the semi chips made very,
very poor use of different bandwidth.

328
00:25:56,320 --> 00:25:59,940
Steve said, well, okay. The DRAM is the
most expensive component of any of these

329
00:25:59,940 --> 00:26:04,280
machines and they're making poor use of
it. And I think a key insight here is if

330
00:26:04,280 --> 00:26:07,740
you maximize that use of the DRAM, then
you're going to be able to get much higher

331
00:26:07,740 --> 00:26:13,490
performance in those machines. And so it's
32 bits wide. The ARM pipelined, so it can

332
00:26:13,490 --> 00:26:19,010
do 32 bit word every cycle. And it also
indicates whether it's sequential or non

333
00:26:19,010 --> 00:26:25,960
sequential. Addressing this then lets
your. Yes. Okay. This then lets your BMC

334
00:26:25,960 --> 00:26:31,200
decide whether to do an N cycle or an S
cycle. So there's a fast one in the slow

335
00:26:31,200 --> 00:26:35,220
one basically. So when you access a new
random address and DRAM, you have to open

336
00:26:35,220 --> 00:26:40,710
that row and that takes twice the time.
It's a four megahertz cycle. But then once

337
00:26:40,710 --> 00:26:45,150
you've access that address and then once
you're accessing linearly ahead of that

338
00:26:45,150 --> 00:26:48,220
address, you can do fast page mode
accesses, which are eight megahertz

339
00:26:48,220 --> 00:26:54,720
cycles. So ultimately, that's the reason
why these loadstore multiples exist. The

340
00:26:54,720 --> 00:26:57,820
non risk instructions, they're there so
that you can stream out registers and back

341
00:26:57,820 --> 00:27:03,100
in and make use of this DRAM bandwidth. So
store multiple. This is just a simple

342
00:27:03,100 --> 00:27:07,860
calculation for 14 registers, you're
hitting about 25 megabytes a second out of

343
00:27:07,860 --> 00:27:12,809
30. So this is it's not 100%, but it's way
more than, you know, 10 for an eighth.

344
00:27:12,809 --> 00:27:17,130
It's a lot of the other processes where
we're using. So this was really good. This

345
00:27:17,130 --> 00:27:21,170
is the prime factor of why this machine
was so fast. is effectively the most or

346
00:27:21,170 --> 00:27:30,169
multiple instructions and being able to
access the stuff linearly. So the MMU is

347
00:27:30,169 --> 00:27:36,980
weird. It's not TLB in the traditional
sense, so TLB's today, if you take your

348
00:27:36,980 --> 00:27:43,040
MIPS chip or something where the TSB is
visible to software, it will map a virtual

349
00:27:43,040 --> 00:27:47,760
address into a chosen physical address and
you'll have some number of entries and you

350
00:27:47,760 --> 00:27:54,220
more or less arbitrarily, you know, poke
an entry and with the set mapping in it.

351
00:27:54,220 --> 00:27:57,789
MEMC does it upside down. So it says it's
got a fixed number of entries for every

352
00:27:57,789 --> 00:28:02,380
page in DB. And then for each of those
entries, it checks an incoming address to

353
00:28:02,380 --> 00:28:08,600
see whether it matches. So it has all of
those entries that we've showed on the

354
00:28:08,600 --> 00:28:13,500
chip diagram a couple of slides ago. That
big left hand side had that big array. All

355
00:28:13,500 --> 00:28:16,831
of those effectively just storing a
virtual address and then matching it and

356
00:28:16,831 --> 00:28:21,840
have a comparator. And then one of them
lights up and says, yes, it's mine. So

357
00:28:21,840 --> 00:28:24,551
effectively, the aphysical page says that
virtual address is mine instead of the

358
00:28:24,551 --> 00:28:30,030
other way round. So this also limits your
memory. If you're saying I have to have

359
00:28:30,030 --> 00:28:34,480
one of these entries on chip per page of
physical memory and you don't want pages

360
00:28:34,480 --> 00:28:40,960
to be enormous. The 32 K if you do the
math for megabytes over 128 pages is the

361
00:28:40,960 --> 00:28:44,690
32K page. If you don't want the page to
get much bigger than that and trust me you

362
00:28:44,690 --> 00:28:47,890
don't, then you need to add more of these
entries and it's already half the size of

363
00:28:47,890 --> 00:28:52,110
the chip. So effectively, this is one of
the limits of why you can only have four

364
00:28:52,110 --> 00:28:58,360
megabytes on one of these memory
controller chips. OK. So Vinci is the core

365
00:28:58,360 --> 00:29:05,230
of the video and sound system. It's set a
FIFO is and a set of shift digital analog

366
00:29:05,230 --> 00:29:09,970
converters for doing video and sound
stream stuff into the FIFO zone. It does

367
00:29:09,970 --> 00:29:14,850
the display timing and pallet lookup and
so forth. It has an 8 bit mode I

368
00:29:14,850 --> 00:29:21,840
mentioned. It's slightly strange. It also
has an output for transparency bit. So in

369
00:29:21,840 --> 00:29:23,830
your palette you can sense 12 bits of
color, but you can set a bit of

370
00:29:23,830 --> 00:29:31,910
transparency as well so you can do video
(gen?) looking quite easily with this. So

371
00:29:31,910 --> 00:29:36,701
there was a revision later on Tudor
explains that the very first one had a bit

372
00:29:36,701 --> 00:29:41,230
of crosstalk between the video and the
sound, so you'd get sound with noise on

373
00:29:41,230 --> 00:29:45,980
it. That was basically video noise and
it's quite hard to get rid of. And so they

374
00:29:45,980 --> 00:29:50,000
did this revision and the way he fixed it
was quite cool. They shuffled the power

375
00:29:50,000 --> 00:29:54,000
supply around and did all the sensible
engineering things. But he also filtered

376
00:29:54,000 --> 00:29:58,610
out a bit of the noise that is being
output on the that's the sound. He

377
00:29:58,610 --> 00:30:02,630
inverted it and then fed that back in as
the reference current for the DAC. So that

378
00:30:02,630 --> 00:30:06,090
sort of self compensating and took the
noise a bit like the noise canceling

379
00:30:06,090 --> 00:30:10,809
headphones. So it was kind of a nice hack.
And that was that was VIDC1. OK, the final

380
00:30:10,809 --> 00:30:17,700
one, I'm going to stop showing you chip
plots after this, unfortunately, but just

381
00:30:17,700 --> 00:30:20,980
get your fill while we're here. And again,
I'm really glad this is enormous for the

382
00:30:20,980 --> 00:30:25,590
people in the room and maybe those zooming
in online. There's a cool little

383
00:30:25,590 --> 00:30:29,510
Illuminati eye logo in the bottom left
corner. So I feared that you weren't gonna

384
00:30:29,510 --> 00:30:34,630
be able to see and I didn't have time to
do zoomed in version, but. Okay. So I see

385
00:30:34,630 --> 00:30:38,030
is the center of the IOC system as much of
the IO system as possible? All the random

386
00:30:38,030 --> 00:30:41,030
bits of blue logic to do things like
timing. Some peripherals are slower than

387
00:30:41,030 --> 00:30:47,309
others lives in IOC. It contains a UART
for the keyboard, so the keyboard is

388
00:30:47,309 --> 00:30:52,320
looked after by an 851 microcontroller.
Just nice and easy to do. Scanning in

389
00:30:52,320 --> 00:30:57,429
software. This microcontroller just sends
stuff up of serial port to this chip. So

390
00:30:57,429 --> 00:31:02,039
UART keyboard, asynchronous receiver and
transmitter. It was at one point called

391
00:31:02,039 --> 00:31:06,080
the fast asynchronous receiver and
transmitter. Mike got forced to change the

392
00:31:06,080 --> 00:31:12,730
name. Not everyone has a 12 year old sense
of humor, but I admire his spirit. So the

393
00:31:12,730 --> 00:31:15,630
other thing it does is interrupts all the
interrupts go into IOC and it's got masks

394
00:31:15,630 --> 00:31:20,341
and consolidates them effectively for
sending an interrupt up to the on the ARM

395
00:31:20,341 --> 00:31:24,690
can then check the status to a fast
response to it. So the eye of providence

396
00:31:24,690 --> 00:31:27,540
there, the little logo I pointed out, Mike
said you put that in for future

397
00:31:27,540 --> 00:31:35,799
archaeologists to wonder about.Okay That
was that was it. I was hoping there'd be

398
00:31:35,799 --> 00:31:40,500
this big back story about, you know, he
was in the Illuminati or something. Maybe

399
00:31:40,500 --> 00:31:44,690
he is not allowed to say anyway. So just
like the other Dave Porter showed, you say

400
00:31:44,690 --> 00:31:49,930
this one's A 500 to B, it's still a second
processor that plugs into a BBC Micro.

401
00:31:49,930 --> 00:31:54,460
It's still got this this hosts having disk
drives and so forth attached to it and

402
00:31:54,460 --> 00:32:00,289
pushing stuff down the tube into the
memory here. But now, finally, all of the

403
00:32:00,289 --> 00:32:05,370
all of this, the chips that are now
assembled in one place. So this is

404
00:32:05,370 --> 00:32:08,370
starting to look like an Archimedes. It
got video out. It's got keyboard

405
00:32:08,370 --> 00:32:11,620
interface. It's got some expansion stuff.
So this is bring up an early software

406
00:32:11,620 --> 00:32:18,460
headstart. But very shortly afterwards, we
got the a five A500 internal 2 Acorn. And

407
00:32:18,460 --> 00:32:21,460
this is really the first Archimedes. This
is the prototype. Archimedes actually got

408
00:32:21,460 --> 00:32:27,660
a gorgeous gray brick sort of look to it,
kind of concrete. It weighs like concrete,

409
00:32:27,660 --> 00:32:31,480
too, but it has all the hallmarks. It's
got the. IO interfaces, it's got the

410
00:32:31,480 --> 00:32:36,950
expansion slots. It can see at the back.
It's got all it runs the same operating

411
00:32:36,950 --> 00:32:39,950
system. Now, this was used for the OS
development. There's only a couple of

412
00:32:39,950 --> 00:32:44,820
hundred of these made. Well, this is a
serial 2 2 2. So this is one of the last,

413
00:32:44,820 --> 00:32:50,730
I think. But yeah. Only an internal to
ACORN. There is a nice tweaks to this

414
00:32:50,730 --> 00:32:55,700
machine. So the hardware team had designed
this Tudor design this as well as the

415
00:32:55,700 --> 00:33:01,710
video system. And he said, well, his A500
was the special one that he had a video

416
00:33:01,710 --> 00:33:05,409
control of the heat. He'd hand-picked one
of the videos so that instead of running

417
00:33:05,409 --> 00:33:11,190
at 24 megahertz to 56, so some silicon
variations in manufacturer. So he found a

418
00:33:11,190 --> 00:33:16,169
56 megahertz pipe. And so he could do. I
think it was 1024 x 768, which is way out

419
00:33:16,169 --> 00:33:22,400
of respect for the rest of the Archimedes.
So he had the really, really cool machine.

420
00:33:22,400 --> 00:33:26,220
They also ran some of them at 12 megahertz
as well instead of 8. This is a massive

421
00:33:26,220 --> 00:33:30,500
performance improvement. I think it use
expensive memory, which is kind of out of

422
00:33:30,500 --> 00:33:37,180
reach for the product. Right. So believe
me, this is the simplified circle, the

423
00:33:37,180 --> 00:33:41,240
circuit diagram. The technical reference
manuals are available online if anyone

424
00:33:41,240 --> 00:33:46,159
wants the complicated one. The main parts
of the display are ARM , MEMC and some RAM

425
00:33:46,159 --> 00:33:52,049
and we have a little walk through them. So
the clocks are generated actually by the

426
00:33:52,049 --> 00:33:57,200
memory controller. Memory controller gives
the clocks the ARM. The main reason for

427
00:33:57,200 --> 00:34:01,030
this is that the memory controller has to
do some slow things now and then. It has

428
00:34:01,030 --> 00:34:05,860
to open pages of DRAMs, refresh cycles and
things. So it stops the CPU and generates

429
00:34:05,860 --> 00:34:11,559
the clock and it pauses the CPU by
stopping that clock from time to time.

430
00:34:11,559 --> 00:34:16,079
When you do a DRAM access, your adress on
bus along the top, the arm outputs an

431
00:34:16,079 --> 00:34:19,720
address that goes into the memory. The
MEMCthen converts that, it does an address

432
00:34:19,720 --> 00:34:23,599
translation and then it converts that into
a row and column addresses sheet with

433
00:34:23,599 --> 00:34:27,139
them. And then if you're doing a reading
and outputs the address aehm outputs the

434
00:34:27,139 --> 00:34:33,419
data onto the date bus, which on then sees
this kind of menses, the critical path on

435
00:34:33,419 --> 00:34:37,279
this. But the address flows through memory
effectively. Notice that MEMC is not on

436
00:34:37,279 --> 00:34:41,329
the data bus. It just gets addresses
flowing through it become important later

437
00:34:41,329 --> 00:34:47,260
on ROM is another slow things. Another
reason why memory might slow down the

438
00:34:47,260 --> 00:34:54,099
access and in a similar sort of way. There
is also a permission check done when

439
00:34:54,099 --> 00:35:00,259
you're doing the address translation per
user permission versus I was a supervisor

440
00:35:00,259 --> 00:35:06,640
and so this information's output as part
of the cycle when when he does access. If

441
00:35:06,640 --> 00:35:09,730
you miss and that translation, you get a
page false or permission fault, then an

442
00:35:09,730 --> 00:35:17,410
abort signal comes back and you take an
exception on deals with that in software.

443
00:35:17,410 --> 00:35:22,289
The database is a critical path, and so
the IO stuff is buffered, it is kept away

444
00:35:22,289 --> 00:35:27,599
from that. So the IO bus is 16 bits and
not a lot 32 bit peripherals around in

445
00:35:27,599 --> 00:35:32,599
those days that will the peripherals 8 or
16 bits. So that's the right thing to do.

446
00:35:32,599 --> 00:35:36,150
The IOC decodes that and there's a
handshake with memory if it needs more

447
00:35:36,150 --> 00:35:39,809
time, if it's accessing one of the
expansion cards in the expansion card. Is

448
00:35:39,809 --> 00:35:47,691
that something slow on X then that's dealt
with in the IOC. So I mentioned the

449
00:35:47,691 --> 00:35:53,680
interrupt status that gets funneled into
IOC and then back out again. There's a V

450
00:35:53,680 --> 00:35:57,599
Sync interrupt, but not an H Sync
interrupt. You have to use timers for that

451
00:35:57,599 --> 00:36:02,010
really annoyingly. There's one timer and
there's a 2 megahertz timer available. I

452
00:36:02,010 --> 00:36:05,539
think I had in a previous life not
previously mentioned it. So if you want to

453
00:36:05,539 --> 00:36:09,730
do funny palette switching stuff or copper
bars or something as possible with the

454
00:36:09,730 --> 00:36:13,400
timers, it's also simple hardware mod to
make a real HD sync interrupt as well.

455
00:36:13,400 --> 00:36:18,529
There's some spare interrupt inputs on the
IOC as an exercise for you . So the bit I

456
00:36:18,529 --> 00:36:23,440
really like about this system, I mentioned
that MEMC is not on the data bus. The VIDC

457
00:36:23,440 --> 00:36:28,079
is only on the data bus and it doesn't
have an address by C. Then the VIDC is the

458
00:36:28,079 --> 00:36:31,200
thing responsible for turning the frame
buffer into video reading that frame

459
00:36:31,200 --> 00:36:35,509
buffer out of RAM, so on. So how does it
actually do that? DRam read without the

460
00:36:35,509 --> 00:36:40,960
address? Well, the memory contains all of
the registers for doing this DNA. The

461
00:36:40,960 --> 00:36:45,140
start of the frame buffer, the current
position and size and so on. They will

462
00:36:45,140 --> 00:36:51,410
live in the MEMC. So there's a handshake
where VIDC sends a request up to the MEMC.

463
00:36:51,410 --> 00:36:55,239
When it's FIFO gets low, the memory then
actually generates the address into the

464
00:36:55,239 --> 00:37:00,349
DRAM diagram, DRAM outputs that data and
then gives the memory, gives an

465
00:37:00,349 --> 00:37:05,509
acknowledged to the... I mean...too many
chips. The memory gives an acknowledged to

466
00:37:05,509 --> 00:37:11,210
VIDC, which then matches that data into
the into the FIFO. So this partitioning is

467
00:37:11,210 --> 00:37:16,710
quite neat. A lot of the video, DMA, while
the video DMA all lives in MEMC and

468
00:37:16,710 --> 00:37:20,799
there's this kind of split across the two
chips. The sound one I've just

469
00:37:20,799 --> 00:37:24,839
highlighted, one interrupt that comes from
MEMC. Sound works exactly the same way,

470
00:37:24,839 --> 00:37:27,730
except there's a double buffering scheme
that goes on. And when one half of it

471
00:37:27,730 --> 00:37:32,359
becomes empty, you get an interrupt so you
can be sure that so you don't get your

472
00:37:32,359 --> 00:37:39,700
sound. So this this all works really very
smoothly. So finally the high res mono

473
00:37:39,700 --> 00:37:44,509
thing that I mentioned before is quite
novel way they did that to do had realized

474
00:37:44,509 --> 00:37:49,931
that with one external component to the
shift register and running very fast, he

475
00:37:49,931 --> 00:37:53,400
could implement this very high resolution
mode without really affecting the rest of

476
00:37:53,400 --> 00:38:00,099
the chip. So VIDC still runs at 24
megahertz to sort of PGA resolution. The

477
00:38:00,099 --> 00:38:05,450
outputs on a digital bus that was a test
boardoriginally. It outputs 4 bits. So 4

478
00:38:05,450 --> 00:38:09,420
pixels in one chunk at 24 megahertz and
then this external component then shifts

479
00:38:09,420 --> 00:38:13,880
through that 4 times the speed. There's
one component. I mean, this is this is a

480
00:38:13,880 --> 00:38:17,569
very cheap way of doing this. And as I
said, this this high res mode is very

481
00:38:17,569 --> 00:38:23,009
unusual for machines of this of this era.
I've got a feeling and a 500 the top end

482
00:38:23,009 --> 00:38:26,979
machine, if anyone's got one of these and
wants to try this trick and please get in

483
00:38:26,979 --> 00:38:31,080
touch, I've got a feeling and a five
hundred will do 1280 x 1024 by

484
00:38:31,080 --> 00:38:35,750
overclocking this. I think all of the
parts survive it. But for some reason,

485
00:38:35,750 --> 00:38:40,369
ACORN didn't support that on the board.
And finally, clock selection obviously on

486
00:38:40,369 --> 00:38:44,839
some of the machines, quite flexible set
of clocks for different resolutions,

487
00:38:44,839 --> 00:38:51,589
basically. So MEMC is not on the data bus.
How do we program it? It's got registers

488
00:38:51,589 --> 00:38:55,259
for DNA and it's got all this address
translation. So the memory map I showed

489
00:38:55,259 --> 00:39:01,089
before has an 8 megabyte space reserve for
the address translation registers doesn't

490
00:39:01,089 --> 00:39:04,690
have eight megabytes of it. I mean,
doesn't have two million 32 bit registers

491
00:39:04,690 --> 00:39:09,819
behind them, which is a hint of what's
going on here. So what you do is you write

492
00:39:09,819 --> 00:39:14,410
any value to this space and you encode the
information that you want to put into one

493
00:39:14,410 --> 00:39:19,539
of these registers in the address. So this
address, the top three bits, the one it's

494
00:39:19,539 --> 00:39:25,230
in the top eight megabytes of the 64
megabyte address space and you format your

495
00:39:25,230 --> 00:39:28,999
logical physical page information in this
address and then you write any byte

496
00:39:28,999 --> 00:39:35,479
effectively. This is a sort of feels
really dirty, but also really a very nice

497
00:39:35,479 --> 00:39:39,779
way of doing it because there's no other
space in the address map. And this reads

498
00:39:39,779 --> 00:39:45,069
to the the price balance. So it's not
worth having an address bus going into

499
00:39:45,069 --> 00:39:49,809
MEMC costing 32 more pins just to write
these registers as opposed to playing this

500
00:39:49,809 --> 00:39:55,849
sort of trick. If you have that address.
But adjust for that database just for

501
00:39:55,849 --> 00:39:59,990
that, then you know, you have to get to a
more expensive package. And this was this

502
00:39:59,990 --> 00:40:05,140
was really in their minds a 68 pin chip
versus an 84 pin chip. It was a big deal,

503
00:40:05,140 --> 00:40:08,719
right. So everything they really strived
to make sure it was in the very smallest

504
00:40:08,719 --> 00:40:13,250
package possible. And this system
partitioning effort led to these sorts of

505
00:40:13,250 --> 00:40:22,890
tricks to then then program it. So on the
A540, we get multiple MEMCs. Each one is

506
00:40:22,890 --> 00:40:27,329
assigned a colored stripe here of the
physical address space. So you have a 16

507
00:40:27,329 --> 00:40:31,049
megabyte space, each one looks after four
megabytes of it. But then when you do a

508
00:40:31,049 --> 00:40:36,039
virtual access in the bottom half of the
user space, regular program access, all of

509
00:40:36,039 --> 00:40:40,080
them light up and all of them will
translate that address in parallel. And

510
00:40:40,080 --> 00:40:44,290
one of them hopefully will translate and
then energize the RAM to do the read. For

511
00:40:44,290 --> 00:40:49,930
example, when you put an ARM 3 in this
system, on three has its cache and then

512
00:40:49,930 --> 00:40:54,420
the address leads into the memory. So then
that means that the address is being

513
00:40:54,420 --> 00:40:58,240
translated outside of the cache or after
the cache. So your caching virtual

514
00:40:58,240 --> 00:41:02,900
addresses and as we all know, this is kind
of bad for performance because whenever

515
00:41:02,900 --> 00:41:06,749
you change that virtual address space, you
have to invalidate your cache target. But

516
00:41:06,749 --> 00:41:11,799
they didn't do that. There's other ways of
solving this problem. Basically on this

517
00:41:11,799 --> 00:41:14,950
machine, what you need to do is invalidate
the whole cache. It's quite a quick

518
00:41:14,950 --> 00:41:24,150
operation, but it's still not good for
performance to have an empty cache. The

519
00:41:24,150 --> 00:41:28,730
only DMA present in the system is for the
video, for the video and sound. I/O

520
00:41:28,730 --> 00:41:32,569
doesn't have any DMA at all. And this is
another area where as younger engineers

521
00:41:32,569 --> 00:41:35,969
see crap, why didn't they have DMA? That
would be way better. DMA is the solution

522
00:41:35,969 --> 00:41:40,989
to everyone's problems, as we all know.
And I think the quote on the right hand

523
00:41:40,989 --> 00:41:47,390
ties in with the ACORN team's discovery
that all of these other processes needed

524
00:41:47,390 --> 00:41:51,969
quite complex chipsets, quite expensive
support chips. So the quote on the right

525
00:41:51,969 --> 00:41:56,539
says that if you've got some chips, that
vendors will be charging more for their

526
00:41:56,539 --> 00:42:03,259
DMA devices even than the CPU. So not
having dedicated DMA engine on board is a

527
00:42:03,259 --> 00:42:08,930
massive cost saving. The comment I made on
the previous to slide about the system

528
00:42:08,930 --> 00:42:14,440
partitioning, putting a lot of attention
into how many pins were on one chip versus

529
00:42:14,440 --> 00:42:19,380
another, how many buses were going around
the place. Not having IOC having to access

530
00:42:19,380 --> 00:42:25,019
memory was a massive saving and cost for
the number of pins and the system as a

531
00:42:25,019 --> 00:42:33,539
whole. The other thing is the the FIQ mode
was effectively the means for doing IO.

532
00:42:33,539 --> 00:42:37,999
Therefore, FIQ Mode was designed to be an
incredibly low overhead way of doing

533
00:42:37,999 --> 00:42:44,010
programed IO by having the CPU, you do the
IO. So this was saying that the CPU is

534
00:42:44,010 --> 00:42:48,850
going to be doing all of the IO stuff, but
lets just optimize it, let's make it make

535
00:42:48,850 --> 00:42:53,930
it as good as it could be and that's what
led to the threatened IO (?). I also

536
00:42:53,930 --> 00:42:57,849
remember ARM 2 didn't have a cache. If you
don't have a cache on your CPU you can.

537
00:42:57,849 --> 00:43:03,099
DMA is going to hold up the CPU anyway, so
we'll know cycles. DMA is not any

538
00:43:03,099 --> 00:43:06,960
performance. Again, you may as well get
the CPU to do it and then get the CPU to

539
00:43:06,960 --> 00:43:13,029
do it in the lowest overhead way possible.
I think this can be summarized as bringing

540
00:43:13,029 --> 00:43:17,410
the "RISC principles" to the system. So
the RISC principle, say for your CPU, you

541
00:43:17,410 --> 00:43:21,420
don't put anything in the CPU that you can
do in software and this is saying, okay,

542
00:43:21,420 --> 00:43:26,789
we'll actually software can do the IO just
as well without the cache as the DMA

543
00:43:26,789 --> 00:43:29,799
system. So let's get software to do that.
And I think this is a kind of a nice way

544
00:43:29,799 --> 00:43:34,339
of seeing it. This is part of the cost
optimization for really very little

545
00:43:34,339 --> 00:43:39,910
degradation in performance compared to
doing in hardware. So this is an IO card.

546
00:43:39,910 --> 00:43:43,380
The euro cards then nice and easy. The
only thing I wanted to say here was this

547
00:43:43,380 --> 00:43:49,339
is my SCSI card and it has a ROM on the
left hand side. And so. This is the

548
00:43:49,339 --> 00:43:54,339
expansion ROM basically many, many years
before PCI made this popular. Your drivers

549
00:43:54,339 --> 00:43:58,950
are on this ROM. This is a SCSI disc
plugging into this and you can plug this

550
00:43:58,950 --> 00:44:02,990
card in and then boot off the desk. You
don't need any other software to make it

551
00:44:02,990 --> 00:44:07,670
work. So this is just a very nice user
experience. There is no messing around

552
00:44:07,670 --> 00:44:11,690
with configuring IO windows or interrupts
or any of the ISIS sort of stuff that was

553
00:44:11,690 --> 00:44:17,869
going on at the time. So to summarize some
of the the hardware stuff that we've seen,

554
00:44:17,869 --> 00:44:21,950
the AMAs pipeline and it has the load-
store-multiple -instructions which make

555
00:44:21,950 --> 00:44:27,950
for a very high bandwidth utilization.
That's what gives it its high performance.

556
00:44:27,950 --> 00:44:32,670
The machine was really simple. So
attention to detail about separating,

557
00:44:32,670 --> 00:44:37,239
partitioning the work between the chips
and reducing the chip cost as much as

558
00:44:37,239 --> 00:44:44,569
possible. Keeping that balanced was really
a good idea. The machine was designed when

559
00:44:44,569 --> 00:44:49,400
memory and CPUs were about the same speed.
So this is before that kind of flipped

560
00:44:49,400 --> 00:44:52,910
over. An eight megahertz on two is
designed to use 8 megahertz memory.

561
00:44:52,910 --> 00:44:56,509
There's no need to have a cache at all on
there these days. It sounds really crazy

562
00:44:56,509 --> 00:45:01,410
not to have a cache on you, but if your
memory is not that much slower than this

563
00:45:01,410 --> 00:45:07,809
is a huge cost saving, but it is also risk
saving This was the first real proper CPU.

564
00:45:07,809 --> 00:45:11,670
If we don't count ARM 1 to say oh, was a
test, but ARM 2 is that, you know, the

565
00:45:11,670 --> 00:45:16,490
first product, CPU. And having a cache on
that would have been a huge risk for a

566
00:45:16,490 --> 00:45:20,640
design team that hadn't hadn't dealt with
structures that complicated it at that

567
00:45:20,640 --> 00:45:26,299
point. So that was the right thing to do,
I think, and took that DMA. I'm actually

568
00:45:26,299 --> 00:45:29,299
converse on this. I thought this was crap.
And actually, I think this was a really

569
00:45:29,299 --> 00:45:33,319
good example of balanced design. What's
the right tool for the job? Software is

570
00:45:33,319 --> 00:45:38,009
going to do the IO, so let's make sure
that the FIQ mode, it makes sure that

571
00:45:38,009 --> 00:45:44,640
there's low overhead as possible. Have you
talked about system partitioning the MMU ?

572
00:45:44,640 --> 00:45:49,569
I've seen ones about. I still think it's
weird and backward. I think there is a

573
00:45:49,569 --> 00:45:56,029
strong argument though that a more
familiar TB(?) is a massively complicated

574
00:45:56,029 --> 00:45:59,339
compared to what they did here. And I
think the main drive here was not just

575
00:45:59,339 --> 00:46:06,770
area on the chip, but also to make it much
simpler to implement. So it worked. And I

576
00:46:06,770 --> 00:46:09,450
think this was they really didn't have
that many shots of doing this. This wasn't

577
00:46:09,450 --> 00:46:14,779
a company or a team that could afford to
have many goes at this product. And I

578
00:46:14,779 --> 00:46:20,660
think that says it all. I think they did a
great job. Okay. So the ARX story is a

579
00:46:20,660 --> 00:46:24,599
little bit more complicated. Remember,
it's gonna be this office automation

580
00:46:24,599 --> 00:46:28,920
machine a bit like a Xerox star. Was going
to have this wonderful highres mono mode

581
00:46:28,920 --> 00:46:33,729
and people gonna be laser printing from
it. So just like Xerox PARC Aiken started

582
00:46:33,729 --> 00:46:37,911
Palo Alto based research center.
Californians and beanbags writing an

583
00:46:37,911 --> 00:46:43,319
operating system using a micro kernel in
modular 2 all of the trendy boxes ticked

584
00:46:43,319 --> 00:46:49,400
here for the mid 80s. It was the sounds
that very advanced operating system and it

585
00:46:49,400 --> 00:46:54,349
did virtual memory and so on is very
resource hungry, though. And it was never

586
00:46:54,349 --> 00:47:00,130
really very performance. Ultimately, the
hardware got done quicker than the

587
00:47:00,130 --> 00:47:05,930
software. And after a year or two.
Management got the jitters. Hardware was

588
00:47:05,930 --> 00:47:09,460
looming and said, well, next year we're
going to have the computer ready. Where's

589
00:47:09,460 --> 00:47:13,650
the operating system? And the project got
canned. And this is a real shame. I'd love

590
00:47:13,650 --> 00:47:16,599
to know more about this operating system.
Virtually nothing is documented outside of

591
00:47:16,599 --> 00:47:21,569
ACORN. Even the people I spoke to didn't
work on this. A bunch of people in

592
00:47:21,569 --> 00:47:25,250
California that kind of disappeared with
it. So if anyone has this software

593
00:47:25,250 --> 00:47:29,259
archived anywhere, then get in touch.
Computer Museum around the corner from me

594
00:47:29,259 --> 00:47:35,699
is raring to go on that. That'll be really
cool things to archive. So anyway, they

595
00:47:35,699 --> 00:47:39,979
had now a desperate situation. They had to
go to Plan B, which was in under a year.

596
00:47:39,979 --> 00:47:42,719
Right. An operating system for the machine
that was on its way to being delivered.

597
00:47:42,719 --> 00:47:48,260
And it kind of shows Arthur was I mean, I
think the team did a really good job in

598
00:47:48,260 --> 00:47:53,160
getting something out of the door in half
a year, but it was a little bit flaky.

599
00:47:53,160 --> 00:47:57,160
Risk, cost. Then a year later, developed
from Arthur. I don't know if anyone's

600
00:47:57,160 --> 00:48:01,609
heard of risk OS, but this is Arthur is
very, very niche and basically got

601
00:48:01,609 --> 00:48:07,170
completely replaced by risk loss because
it was a bit less usable than risk.

602
00:48:07,170 --> 00:48:12,059
Another really strong point that this is
quite a big wrong. So two megabytes going

603
00:48:12,059 --> 00:48:17,400
up. So half a megabytes in the 80s going
up to two megabytes in the early 90s.

604
00:48:17,400 --> 00:48:22,019
There's a lot of stuff in ROM. One of
those things is BBC Basic Five. I know

605
00:48:22,019 --> 00:48:29,289
it's 2019, but I know basic is basic, but
BBC Basic is actually quite good. It has

606
00:48:29,289 --> 00:48:32,859
procedures and it's got no support for all
the graphics and sound. You could give me

607
00:48:32,859 --> 00:48:36,660
applications and basic and a lot of people
did. It's also very fast. So Sophie Wilson

608
00:48:36,660 --> 00:48:42,920
wrote this this very, very optimized basic
interpreter. I talked about the modules

609
00:48:42,920 --> 00:48:45,589
and produles (?). This is the expansion
room. Things are really great user

610
00:48:45,589 --> 00:48:50,589
experience there. But speaking of user
experience, this was ARTHUR . I never used

611
00:48:50,589 --> 00:48:58,559
Arthur. I just dug out from it how to play
with it. It is bloody horrible. So that

612
00:48:58,559 --> 00:49:03,819
went away quickly. At the time also. So
part of this emergency plan B was to take

613
00:49:03,819 --> 00:49:08,210
the ACORN soft team who were supposed to
be writing applications for this and get

614
00:49:08,210 --> 00:49:12,079
them to quickly knock out an operating
system. So at launch, basically, this is

615
00:49:12,079 --> 00:49:15,750
one of the only things that you could do
with the machine. Had a great demo called

616
00:49:15,750 --> 00:49:20,569
Lender of Great Game called Arch, which is
3D space. You could fly around it, didn't

617
00:49:20,569 --> 00:49:27,029
have business, operate serious business
applications. And, you know, it was very

618
00:49:27,029 --> 00:49:31,079
there was not much you could do with this
really expensive machine at launch and

619
00:49:31,079 --> 00:49:35,450
that really hurt it, I think. So let me
get the risk as to 1988 and this is now

620
00:49:35,450 --> 00:49:42,219
looking less like a vomit sort of thing,
much nicer machine. And then eventually

621
00:49:42,219 --> 00:49:46,749
you Risc OS 3. It was drag and drop
between applications. It's all

622
00:49:46,749 --> 00:49:52,849
multitasking, does outline anti aliasing
and so on. So just lastly, I want to

623
00:49:52,849 --> 00:49:55,769
quickly touch on the really interesting
operating systems that ACORN had a Unix

624
00:49:55,769 --> 00:49:59,079
operating system. So as well as being a
geek, I'm also UNIX geek and I've always

625
00:49:59,079 --> 00:50:04,609
been fascinated by RISCiX. These machines
are astonishing and expensive. They were

626
00:50:04,609 --> 00:50:08,191
the existing Archimedes machines with a
different sticker on. So that's a 540 with

627
00:50:08,191 --> 00:50:13,890
a sticker on the front. And this system
was developed after the Archimedes was

628
00:50:13,890 --> 00:50:18,529
really designed at that point when this
open system was being developed. So

629
00:50:18,529 --> 00:50:20,950
there's a lot of stuff about the hardware
that wasn't quite right for a Unix

630
00:50:20,950 --> 00:50:26,230
operating system. 32K. page size on a 4
megabyte machine really, really killed you

631
00:50:26,230 --> 00:50:29,900
in terms of your page cache and and that
kind of thing. They turned this into a bit

632
00:50:29,900 --> 00:50:35,089
of an opportunity. At least they made good
on some of this. There was a quite a novel

633
00:50:35,089 --> 00:50:42,380
online decompression scheme for you to
demand Page in all text from the binary

634
00:50:42,380 --> 00:50:46,170
and it would decompressed into your search
to get a page, but it was stored in a

635
00:50:46,170 --> 00:50:54,309
sparse way on disk. So actually on disk
use was a lot less than you'd expect. The

636
00:50:54,309 --> 00:50:59,609
only way it fit on some of the smaller
machines. Also tackles the department does

637
00:50:59,609 --> 00:51:05,049
on the cyber track. It turns out this is
their view of the 680, which is an

638
00:51:05,049 --> 00:51:08,940
unreleased workstation. I love this
picture. I like that piece of cheese or

639
00:51:08,940 --> 00:51:13,959
cake is the mouse. That's my favorite
part. But this is the real machine. So

640
00:51:13,959 --> 00:51:20,650
this is an unreleased prototype I found at
the computer museum. It's notable. And

641
00:51:20,650 --> 00:51:24,650
there's got to MEMC. It's got a 8MB of
RAM. It's only designed to run. Respects

642
00:51:24,650 --> 00:51:26,099
the Unix operating system and has highres
monitor only doesn't have color, who's

643
00:51:26,099 --> 00:51:30,279
designed to run frame maker and driver
laser printers and be a kind of desktop

644
00:51:30,279 --> 00:51:35,249
publishing workstation. I've always been
fascinated by Risk X, as I said a while

645
00:51:35,249 --> 00:51:41,450
ago. I hacked around on ACORN for a while.
I got a beating and I can. I've never seen

646
00:51:41,450 --> 00:51:46,640
this before. I never used to risk X
machine. So there we go it Boots, it is

647
00:51:46,640 --> 00:51:51,730
multi-user. But wait, there's more. It has
a really cool X-Server, a very fast one. I

648
00:51:51,730 --> 00:51:54,730
think so. If you Wilson again worked on
the server here. So it's very, very well

649
00:51:54,730 --> 00:51:58,019
optimized and very fast for a machine of
its era. And it makes quite a nice little

650
00:51:58,019 --> 00:52:02,900
Unix workstation. It's quite a cool little
system, by the way TUDOR the guy that

651
00:52:02,900 --> 00:52:07,099
designed the VIDC and the IO system called
me a sado forgetting this working in

652
00:52:07,099 --> 00:52:14,150
there. That's my claim to fame. Finally,
and I want to leave some time for

653
00:52:14,150 --> 00:52:19,510
questions. There's a lot of useful stuff
in Rome. One of them is BBC Basic Basic

654
00:52:19,510 --> 00:52:23,009
has an assembler so you can walk up to
this machine with a floppy disk and write

655
00:52:23,009 --> 00:52:30,239
assembler has a special bit of syntax
there and then you can just call it. And

656
00:52:30,239 --> 00:52:32,460
so this is really powerful. So at school
or something with the floppy disk, you can

657
00:52:32,460 --> 00:52:37,199
do something that's a bit more than basic
programing. Bizarrely, I mostly write that

658
00:52:37,199 --> 00:52:41,420
with only two or three tiny syntax errors
after about 20 years away from this. It's

659
00:52:41,420 --> 00:52:46,059
in there somewhere legacy wise. The
machine didn't sell very many under a

660
00:52:46,059 --> 00:52:50,930
hundred thousand easily. I don't think it
really made a massive impact. PCs had

661
00:52:50,930 --> 00:52:54,640
already taken off. By then. The ARM
processor is going to go on about the

662
00:52:54,640 --> 00:52:58,920
company. That's that's clear that that
obviously has changed the world in many

663
00:52:58,920 --> 00:53:04,140
ways. The thing I really took away from
this exercise was that a handful of smart

664
00:53:04,140 --> 00:53:10,089
people. Not that many. No order of a dozen
designed multiple chips, designed a custom

665
00:53:10,089 --> 00:53:14,869
computer from scratch, got it working. And
it was quite good. And I think that this

666
00:53:14,869 --> 00:53:17,380
really turned people's heads. It made
people think differently that the people

667
00:53:17,380 --> 00:53:21,160
that were not Motorola and IBM really,
really big companies with enormous

668
00:53:21,160 --> 00:53:27,479
resources could do this and could make it
work. I think actually that led to the

669
00:53:27,479 --> 00:53:30,809
thinking that people could design their
systems on the chip in the 90s and that

670
00:53:30,809 --> 00:53:35,309
market taking off. So I think this is
really key in getting people thinking that

671
00:53:35,309 --> 00:53:40,420
way. It was possible to design your own
silicon. And finally, I just want to thank

672
00:53:40,420 --> 00:53:45,279
the people I spoke to and Adrian and
Jason. Their sense of computing history in

673
00:53:45,279 --> 00:53:49,049
Cambridge. If you're in Cambridge, then
please visit there. It's a really cool

674
00:53:49,049 --> 00:53:56,270
museum. And with that, I'll wrap up. If
there's any time for questions, then I'm

675
00:53:56,270 --> 00:54:01,890
getting a blank look. No time for
questions. There's about 5 minutes left.

676
00:54:01,890 --> 00:54:09,680
Say it or come up to me afterwards. I'm
happy to. Happy to talk more about this.

677
00:54:09,680 --> 00:54:18,940
<i>Applause</i>
Herald:The first question is for the

678
00:54:18,940 --> 00:54:29,799
Internet. Internet signal angel, will you?
Well, get your microphones and get the

679
00:54:29,799 --> 00:54:36,700
first of the audio in the room here. Since
the microphone, please ask a question.

680
00:54:36,700 --> 00:54:44,130
Mic1: You mentioned that the system is
making good use of the memory, but how is

681
00:54:44,130 --> 00:54:50,459
that actually not completely being
installed on memory? Having no cache and

682
00:54:50,459 --> 00:54:55,450
same cycle time for the cache as for the
memory as for the CPU.

683
00:54:55,450 --> 00:55:01,140
M: Good question. So how is it not always
build on memory ? I mean. Well, it's

684
00:55:01,140 --> 00:55:04,390
sometimes stored on memory when you do
something that's non sequential. You have

685
00:55:04,390 --> 00:55:08,869
to take one of the slow cycles. This was
the N cycle. The key is this you try and

686
00:55:08,869 --> 00:55:11,469
maximize the amount of time that you're
doing sequential stuff.

687
00:55:11,469 --> 00:55:16,220
So on the ARM 2 you wanted to unroll loops
as much as possible. So you're fetching

688
00:55:16,220 --> 00:55:19,799
your instructions sequentially, right? You
wanted to make as much use as lodestone

689
00:55:19,799 --> 00:55:24,290
multiples. You could load single registers
with an individual register load, but it

690
00:55:24,290 --> 00:55:28,710
was much more efficient to pay that cost.
Just once the start of the instruction and

691
00:55:28,710 --> 00:55:33,619
then stream stuff sequentially. So you're
right that it is still stored sometimes,

692
00:55:33,619 --> 00:55:37,141
but that was still there. Still a good
tradeoff, I think, for a system that

693
00:55:37,141 --> 00:55:40,549
didn't have a cache for other reasons.
M1: Thanks.

694
00:55:40,549 --> 00:55:45,530
Herald: Next question is for the Internet.
Signal Angel(S): Are there any other ACORN

695
00:55:45,530 --> 00:55:49,839
here right now or if you want to get into
this kind of party together?

696
00:55:49,839 --> 00:55:51,980
Herald: Can you repeat the first sentence,
please?

697
00:55:51,980 --> 00:55:55,839
S: Sorry. The first part if you want to
get into this kind of popular vibe right

698
00:55:55,839 --> 00:55:58,839
now.
M: Yeah, good question, sir. How do you

699
00:55:58,839 --> 00:56:06,359
get hold of one drive prices up on eBay? I
guess I hate to say it might be fun to

700
00:56:06,359 --> 00:56:09,170
play around and emulators. Always
professors that are hack around on the

701
00:56:09,170 --> 00:56:12,309
real thing. Emulators always feel a bit
strange. There are a bunch of really good

702
00:56:12,309 --> 00:56:19,180
emulators out there. Quite complete. Yeah,
I think it just I would just go on on on

703
00:56:19,180 --> 00:56:23,260
auction sites and try and find one.
Unfortunately, they're not completely

704
00:56:23,260 --> 00:56:27,829
rare. I mean that's that's the thing they
did sell. Not quite sure. Exact figure,

705
00:56:27,829 --> 00:56:31,500
but you know, there were tens and tens of
thousands of these things made. So I would

706
00:56:31,500 --> 00:56:35,130
look also in Britain more than elsewhere.
Although I do understand that Germany had

707
00:56:35,130 --> 00:56:40,170
quite a few. If you can get a hold of one,
though, I do suggest doing so. I think

708
00:56:40,170 --> 00:56:46,259
they're really fun to play with.
Herald: OK, next question.

709
00:56:46,259 --> 00:56:51,860
M2: So I found myself looking at the
documentation for the LV MSU instructions

710
00:56:51,860 --> 00:56:58,049
while devaluing something on. Just last
week. And just maybe wonder what's your

711
00:56:58,049 --> 00:57:04,029
thought? Are there any quirks of the
Archimedes that have crept into the modern

712
00:57:04,029 --> 00:57:06,900
arm design and instruction set that you
were aware of?

713
00:57:06,900 --> 00:57:13,449
M: Most of them got purged. So there are
the 26 bits of dressing. There was a

714
00:57:13,449 --> 00:57:20,039
couple of strange uses of theirs A XOR or
instruction into PC for changing flags. So

715
00:57:20,039 --> 00:57:25,160
there was a great purge when the ARM 6 was
designed and the arm 6. I should know

716
00:57:25,160 --> 00:57:31,559
there's ARM v3. That's what first step
addressing and lost this. These witnesses

717
00:57:31,559 --> 00:57:35,690
got moved out.
I can't think of aside from just the

718
00:57:35,690 --> 00:57:40,619
resulting on 32 instructions that being
quite quirky and having a lot of good

719
00:57:40,619 --> 00:57:47,099
quirks. This shifted register as sort of a
free thing you can do. For example, you

720
00:57:47,099 --> 00:57:52,059
can add one register to a shifted register
in one cycle. I think that's a good quirk.

721
00:57:52,059 --> 00:57:55,119
So in terms of the inheriting that
instruction set and not changing those

722
00:57:55,119 --> 00:58:05,959
things. Maybe that counts this.
Herald: Any further questions Internet ?

723
00:58:05,959 --> 00:58:10,959
And if you have questions. No. Okay. No.
In that case, one round of applause.

724
00:58:10,959 --> 00:58:12,959
M: Thank you.

725
00:58:12,959 --> 00:58:13,959
<i>Applause</i>

726
00:58:13,959 --> 00:58:14,959
<i>postroll music</i>

727
00:58:14,959 --> 00:58:28,130
Subtitles created by c3subtitles.de
in the year 2020. Join, and help us!