Remix.run Logo
zabzonk 4 days ago

> In many ways, the tuple (BBC Micro, Acorn Computers, arm) is analogous to (IBM PC, Intel, x86)

Except the BBC micro didn't use an ARM processor - it used a 6502. Whereas the IBM PC did use the Intel processor.

afandian 4 days ago | parent | next [-]

Depends how nitpicky you want to be. There was an ARM “BBC Micro”.

https://www.retro-kit.co.uk/page.cfm/content/Acorn-BBC-Archi...

And the IBM PC used an 8088.

https://en.m.wikipedia.org/wiki/IBM_Personal_Computer

djmips 4 days ago | parent | prev | next [-]

Let's be serious, the BBC micro is awesome but it's no more the ancestor to my phone than an Apple II.

Lio 3 days ago | parent | next [-]

Well the ARM's original goal was to run BBC BASIC faster than the BBC B could run assembly code.

To that end the ARM instruction set was heavily inspired by the 6502 in the Beeb and cruicially the BBC Micro was used to simulate the ARM before it went into production.

Latter the original ARM development kits were connected as second processors to Beebs courtesy of the Tube connector.

I think it's fare to say that without the BBC Micro there would be no ARM processors.

https://arstechnica.com/gadgets/2022/09/a-history-of-arm-par...

klelatti 3 days ago | parent [-]

> Well the ARM's original goal was to run BBC BASIC faster than the BBC B could run assembly code.

That seems an unlikely goal given BBC BASIC was interpreted! Happy to be proven wrong but I've never heard one of the original team say that.

Lio 3 days ago | parent | next [-]

Sophie Wilson discusses it here[1] but I've read it in other places too. You'll have to find them yourself though.

> The second thing they didn’t do was that they weren’t fast, they weren’t easy to use. We were used to programming the 6502 in the machine code and we rather hoped that we could get to a power level such that if you wrote in a higher level language you could achieve the same types of results. So you could write 3D graphics games. You could do whatever you wanted to do without having to go all the way down to assembly language and for these processors that were on sale at the time that wasn’t true. They were too slow. So between the two things we felt we needed a better processor.

https://archive.computerhistory.org/resources/access/text/20...

klelatti 3 days ago | parent [-]

Thanks for the quote which is very interesting. Not being pedantic but this isn’t quite what your original comment said. Sophie is saying ‘same type’ of results and not having to use assembly for certain applications which doesn’t imply that BASIC on ARM would be faster than 6502 assembly just that it was fast enough for their purposes.

I think it’s possible that some applications would be faster - floating point for example due to the ARM’s 32 bit registers and the 6502’s lack of even 16 bit arithmetic - but probably not in general.

TheOtherHobbes 3 days ago | parent [-]

You have to remember these 1980s processors were ridiculously slow by modern standards, and "same type of results" implies a ballpark goal that was impressively aspirational on its own terms.

The details of "Does that mean the same speed, or faster?" weren't really relevant, because the speed difference was anywhere between 10X and 100X - which was an astounding, if rather fuzzy, target.

ARM 1 got surprisingly close to that out of the gate, with the added benefit of being unexpectedly power efficient.

Someone 3 days ago | parent | prev | next [-]

The ARM1 ran at 6MHz, three times as fast as the 6502 in the BBC B.

It also had more (16 user registers vs, counting optimistically, 3) and larger (32 bit vs 8bit) registers, compared to the 8 bit registers of the 6502, and a 3-stage pipeline.

I expect that means the BASIC interpreter kept the current program position in a register, where the 6502 one used memory (likely in self modifying code), and could fetch the next token in a single cycle vs at least 5 or so for the 6502 version.

Having a faster CPU and more memory also may have meant they could be smarter in the way programs get stored.

I guess all that combined means there are programs were that goal can be met, for example programs computing a Mandelbrot image.

ARM2 added a hardware multiplier.

JdeBP 3 days ago | parent | next [-]

There was no self-modifying code. BBC BASIC was in ROM.

classichasclass 3 days ago | parent [-]

I don't know the internals of BBC BASIC, but many Microsoft-derived BASICs do keep track of the current location in the program text with self-modifying code; the routine is copied to a reserved portion of zero page on 6502 machines for speed. On the C64 this routine lives at $0073 and the pointer is at $007a. Because it's in RAM, this makes it a popular location for wedging in additional behaviour or commands (hence the term "wedge" for such extensions). On some systems like the PET, this was the only way to accomplish it.

JdeBP 3 days ago | parent [-]

BBC BASIC is not Microsoft BASIC. You cannot reason about the operation of BBC BASIC from only knowing about Microsoft BASIC.

Whereas I suspect that I am nowhere near the only person on this page who once disassembled ROMs on a BBC Micro. We can state, in contrast, that there was no such self-modifying code. Again, BBC BASIC was in ROM.

Those lucky enough to have a copy of Jeremy Ruston's book after all of these years, or the retrocomputing enthusiasts who still have working Beebs, could even tell you exactly where in ROM the code was that fetched the next token for execution.

I never actually owned a copy of the book, and somewhat envy anyone who still has a copy; although to compensate I do have part of one of my own disassembly listings still, buried somewhere. (-:

classichasclass 3 days ago | parent [-]

I made no claim it was. I was pointing out that ROM BASICs on 6502s have kept track of the current pointer in self-modifying code by copying the relevant section to RAM. Just because it originated in ROM doesn't mean it doesn't. Thank you for explaining the situation with BBC BASIC.

klelatti 3 days ago | parent | prev [-]

The interpreter is doing a lot that you’ve not mentioned here; parsing the BASIC source code for example.

guenthert 3 days ago | parent | next [-]

Er, the parsing is done ahead of time. The BASIC interpreters then were byte-code interpreters; the one of the beeb a particular fast one.

I know nothing about the first ARM, but ARM2 of Archimedes (anno 1987) was significantly faster than a MC68k (both at 8MHz), both much faster than a 6502 at one (typical) or two (in the beeb) MHz.

A BASIC interpreter using the ARM 1 or 2 might not have been literally faster than machine code on a 6502 (certainly not for some silly micro benchmarks), but, the stated goal, allowing high level programming where earlier assembly was required, certainly was met.

tomatocracy 3 days ago | parent [-]

The early 8MHz ARM2-based Archimedes machines arguably also outperformed contemporary 16/20MHz 80386 machines (due to the x86-based machines being slower to access RAM before the advent of on-motherboard cache and zero waitstate RAM) as well.

tom_ 3 days ago | parent | prev [-]

You can probably make it happen. If your program uses all the same tricks that worked with 6502 BBC BASIC to reduce the interpreter overhead, the ARM BASIC version will run as well as it can. Then imagine your program does a lot of integer maths with the resident integer variables, multiplication in particular, and (for whatever reason) it needs the full 32 bit integer precision - I'm sure you would stand a chance! 32 bit operations are cheap on the ARM, and it's got a multiply instruction. No such luck with the 6502.

pjmlp 3 days ago | parent | prev [-]

It could be the point of what optimizations would be possible on the interpreter.

One of the optimizations Google introduced on Android 7, when they backtracked for AOT at installation time introduced in Android 5, was that the DEX interpreter was rewriten from scratch in cleverly manually written Assembly, before handing it over to the JIT/AOT infrastructure.

BBC Basic was also one of the few that allowed direct inline Assembly, instead of having to go through DATA blocks.

klelatti 3 days ago | parent [-]

BBC BASIC wasn't JIT'd etc so not sure how all the Android comparisons come in!

Just to make the comparison more concrete the ARM1 ran at 8MHz and was 32-bit and with a lot more registers compared to the BBC Micro's 6502 running at 2MHz. It was a lot faster but not fast enough to make BBC BASIC run at BBC Micro Assembly language speed.

pjmlp 3 days ago | parent [-]

Missed the part about writing interpreters in Assembly?

Most folks nowadays wouldn't even think that is an option, hence the comparison with a product several decades later doing that instead of C kind of approach.

Back to ARM v1, maybe the design did take into account how to improve the developer's life of those writing in Assembly, which was critical for implementation of the whole userspace, meaning BBC Basic.

lproven 3 days ago | parent | prev | next [-]

> it's no more the ancestor to my phone than an Apple II.

It really is.

Both Acorn (BBC Micro designers/manufacturers) and Apple Computer (Apple II ditto) bought in the MOS 6502 chip.

When it came to successor models, both tried the 65C816.

Acorn made the Communicator:

https://chrisacorns.computinghistory.org.uk/Computers/Commun...

Apple made the Apple IIgs:

https://americanhistory.si.edu/collections/object/nmah_55324...

Both were not delighted with its performance and looked elsewhere.

Apple went for the 68000 for its next mass-market model, the Mac. (I am aware the timeline is more complex; this is a simplification.)

Acorn evaluated the 68000, the 80186, the NatSemi 16032 and others.

It designed its own chip instead: the ARM, Acorn RISC Machine.

This was first launched as an add-on accelerator for the BBC Micro.

https://www.computinghistory.org.uk/det/48862/Acorn-1MB-A-Se...

It was later launched as an Acorn computer, running a 32-bit port of Acorn's MOS and BASIC. It included a 6502 emulators and so could run some BBC Micro software.

https://www.onirom.fr/wiki/blog/21-04-2022_Acorn-Archimedes/

That ARM chip is the direct ancestor of the chip in all Android devices, all iOS devices, and modern Macs.

rjsw 4 days ago | parent | prev [-]

It is a bit closer link than that, the same people designed the BBC micro and ARM1.

cesaref 3 days ago | parent [-]

If he'd been talking about the Acorn Archimedes, he'd have had a point.

jacquesm 3 days ago | parent [-]

No, he'd have even less of a point.

jacquesm 4 days ago | parent | prev | next [-]

Except, of course there was the Archimedes. Which was a BBC Micro on steroids.

Besides, it did say 'in many ways' so I think that this is really needless nitpicking.

extraisland 3 days ago | parent | next [-]

I have used both when I was a kid. There were nothing alike really.

I owned a BBC Micro Model B (was given one when a friend was given a 486 PC) and I used the Archimedes at school. The BBC Micro was archaic compared to the Archimedes and PCs of the time.

jacquesm 2 days ago | parent [-]

Of course it was.

It was six years older and this was the era when CPUs evolved massively from one generation to the next. Just like the Acorn 'Atom' was 'nothing like the BBC Micro' in spite of using the same processor.

For some contrast: when the BBC Model A came out in 1981 originally it had cassette tape as mass storage, an 8 bit cpu clocked at 2 MHz, 16K RAM and if you were very lucky yours came with the optional floppy drive which cost nearly as much as the machine itself. When the first ARM was sold to the public, six years later it came with a 32 bit RISC CPU clocked at 4 MHz, 512K or 1M of RAM, an ST 506 based harddrive option.

That's just six years of progress, and we're skipping over many steps in the lineage, the BBC Master series, the tube expansions and the Olivetti saga. You could pick 1980 to 1990 and write a pretty large book about personal computing progress during those years and you likely would still miss important events.

But the lineage was - for those that owned all of the intermediary machines as well - pretty clear, and that is before we get into the lineage of the software that the Archimedes shipped with, MOS and BBC Basic, which both worked more or less as you would expect given the new machines capabilities.

extraisland 2 days ago | parent [-]

I aware of most of the history. I've used a Master briefly while I was at school and honestly it worked like a upgraded BBC Micro Model B and looking at the wikipedia page it looks like that was exactly the case.

taylorius 3 days ago | parent | prev | next [-]

The Archimedes was called a "BBC Micro" because it was part of the BBC's home computing initiative, but architecturally, it had nothing to do with the original BBC Micro.

mcv 3 days ago | parent | next [-]

I don't recall the Archimedes ever getting called a "BBC Micro". I remember the introduction of the Archimedes. We had an Acorn Electron, and we'd seen the introduction of various "BBC Masters"; BBCs with more memory, more powerful hardware, but still a BBC. The Archimedes, was always marketed as something completely new, as far as I recall.

My brother had one. Really cool machine, and as far as I remember, on a completely different level than anything that had existed before it. Soon succeeded by the Risc PC, which I mostly remember for being able to accept various configurations of additional processors (it could get either an x86 as co-processor, or several additional ARMs).

lproven 3 days ago | parent | next [-]

> I don't recall the Archimedes ever getting called a "BBC Micro"

Pictures:

https://chrisacorns.computinghistory.org.uk/Computers/A3000....

Note the logo at top right of the keyboard.

Also note the bright red function keys.

taylorius 3 days ago | parent | prev [-]

It was something entirely new, of course. In fact it wasn't called a BBC Micro - however it was "endorsed" by the BBC - had the owl logo on it etc. Was indeed a cool machine, and streets ahead of anything else at the time. Typical UK tech story...

jacquesm 3 days ago | parent | prev | next [-]

Hardware architecture not, for very obvious reasons. But if you wrote BBC Basic you'd have felt right at home and this continuity was one of the reasons they sold quite well, lots of people that were using the BBC Micro in ways that it wasn't intended for had run into the limitations of the platform and wanted something similar but bigger and faster. The Archimedes was that - and more. To get maximum performance (still very anemic by today's standards) out of a 6502 based BBC you'd have been programming in assembly and that of course did not port at all to the ARM based machines.

As I wrote in another comment I was pretty close to the fire and had very early access to the ARM architecture based beebs courtesy of a friendly contact but I realized soon enough that the future for home computing and SMB business computing did not lie with either Acorn, Atari, Commodore or any of the other contenders. In '88 or so (my memory is a bit hazy about the dates, there was a lot going on in my life back then) I moved to x86 professionally with a side of Atari ST (using the fantastic Mark Williams C compiler + documentation) for more fun stuff and with the advent of the availability of the internet for the masses I ran SGI Irix for a couple of years until I settled on Linux which has been my daily driver for decades now. Hardware architecture used to be a super important factor for me, now the only thing that matters is whether or not I can run Ubuntu and whether the hardware is sufficiently powerful to get me through my working day. The fact that my daily driver is a 12 year old laptop is a nice indication of how far we've come, it is pretty rare that I put together machines where performance really matters.

But regardless of all of that I have a fond spot in my heart for the BBC, regardless of processor used, it was the machine that allowed me to finally do some more structured programming and explore other languages without breaking the bank.

lproven 3 days ago | parent | prev [-]

> architecturally, it had nothing to do with the original BBC Micro.

This is not true. It had lots to do with it.

* The Archimedes used a CPU whose designers (Sophie Wilson and Steve Furber) have specifically said they built it to be conceptually similar to the 6502. Source: I have met both and seen them say this in person.

* The Archimedes ran RISC OS which is a rewrite of the BBC MOS. Source: I have interviewed the project leader, Paul Fellows.

https://www.theregister.com/2022/06/23/how_risc_os_happened/

The Archie came with !6052tube and could run some BBC apps.

Source code: http://bbc.nvg.org/rom/Acorn/os/?C=N;O=A

talideon 3 days ago | parent | prev [-]

Somewhat more than that. RISC OS was MOS on steroids too.

Kim_Bruning 4 days ago | parent | prev | next [-]

Sort of true, but yet, what does my eye spy on an early Archimedes A310 keyboard?

(detail: https://www.retro-kit.co.uk/user/custom/Acorn/32bit/A310/310... )

(full article for reference: https://www.retro-kit.co.uk/page.cfm/content/Acorn-BBC-Archi... )

... and besides, it runs BBC BASIC!

3 days ago | parent | prev | next [-]
[deleted]
cperciva 4 days ago | parent | prev [-]

Sure, but modern x86 has very little in common with the 8088.

mojuba 4 days ago | parent | next [-]

Depends on how you define "common" but the entire lineage 8080 -> 8086 -> 8088 are backwards compatible and therefore are very much related.

jacquesm 3 days ago | parent | next [-]

It goes further back than that, just not as backwards compatible. 4004 -> 8008, 8080 and so on. Just like the 6800, 6809, 68000 etc progression. All of these are families that have more in common with each other from one generation to the next than with other such families. It's logical: usually those were the same teams designing them with better tools and more money at their disposal, as well as a vastly increased transistor budget. Notable exception: the 6800 is in many ways simply an improved 6502 but by a different manufacturer.

leoc 3 days ago | parent | next [-]

The 8008 is not a 4004 descendant, though: it was a new design originally done for the Datapoint 2200!

jacquesm 3 days ago | parent | next [-]

Fair point, that's true in the direct lineage sense, but, 6809 to 68000 is a similar jump, there is nothing to say the one was based on the other except for general ideas and some addressing modes that turned out to be handy (when writing compilers, rather than writing assembly). Every widening of the databus caused a redesign from the ground up, even if some of the concepts survived. The 4004 was early enough that there was not much installed base to worry about so a clean start for a new chip made very good sense.

But in the 65XX family there is the 65816, a chip that tried really hard to maintain as much backward compatibility as possible. It saw some commercial deployment (Apple, Nintendo). At that point in time backwards compatibility began to have real value and intel really made some lucky calls: the weird addressing modes resulting from the lack of register width eventually culminated in a setup that worked very well for CPUs that were running multi-tasking OS's. The 386 was a very nice match for such code and this model was a major factor in the success of the line (which really was creaking badly with the 80286 out vs the 68K, which effectively had a 32 bit flat model built in because of its ability to run position independent code).

But in 1987, when the 80386 hit GA it was pretty much game over for the rest even if it took a while for the other empires to crumble, only ARM survived and that is mostly because Acorn had a completely different idea about power consumption and use of silicon than Intel did. The current crop of x86 hardware is insane in terms of power consumption and transistor count, ARM is so much more elegant (in spite of its warts).

leoc 3 days ago | parent [-]

And a nearly opposite business model too: IIUC ARM was more or less the first company to behave like it actually wanted customers for its CPU-design licenses.

jacquesm 3 days ago | parent [-]

Yes, that's a very good observation, ARM was always an IP company rather than a one-stop-shop and that in turn served as a very effective avenue for the evangelism of its architecture.

klelatti 3 days ago | parent | prev [-]

With Datapoint’s own ISA of course!

tonyedgecombe 3 days ago | parent | prev [-]

Another similar exception is the Z80 to the 8080.

jacquesm 3 days ago | parent [-]

That's Zilog, not Intel!

tonyedgecombe 3 days ago | parent [-]

That's the point:

>Notable exception: the 6800 is in many ways simply an improved 6502 but by a different manufacturer.

jacquesm 3 days ago | parent [-]

Ah I see now what you meant.

klelatti 4 days ago | parent | prev [-]

8080 -> 8086 not compatible although assembly code translation was possible.

mananaysiempre 3 days ago | parent [-]

Some parts of the lineage are nevertheless very important. When I wrote a 8086 assembler, I’ve come across the idea of of writing the instruction encodings in octal instead of hexadecimal purely by accident, described as some sort of little-known neat trick hidden from the casual reader of the CPU documentation. It’s only by reading the manual for the Datapoint 2200 much later that I found a confirmation that this was very much intentional and (in the distant past) documented.

klelatti 3 days ago | parent [-]

100%! There is clear lineage back to the Datapoint 2200 which is remarkable given that it wasn't even an Intel design and CTC gave away the rights IIRC.

lproven 3 days ago | parent | prev | next [-]

> modern x86 has very little in common with the 8088.

It is directly binary compatible. A Core i7 can boot and run MS-DOS from the 8088.

I offer a freebie DOS distro for modern PCs:

https://github.com/lproven/usb-dos

What more do you want than "executes the same binaries"?

userbinator 3 days ago | parent | prev [-]

The 16-bit mode instruction set of a modern x86 is almost entirely a superset of the 8088.