Processor Types

Where did it come from?

Acorn made heavy use of the 6502 processor in their early machines. But with a 64K memory restriction, and maximum clock speed of 2MHz (though I believe later faster parts were created, 4MHz or 8MHz?), the 6502 was no longer a suitable processor.
Acorn looked high, and they looked low. But they were unhappy with what they found. Nothing stood out as the perfect processor to put in their new systems. And at the same time, video systems pretty much took the piddly. In one extreme, you could have text or graphics but not both. At the other extreme you had Hercules, MDA, EGA, CGA... which were not exactly compatible with each other.

So Acorn rolled their own.

Please. Take a moment to consider this.
Not only did Acorn create an entire powerful and innovative operating system with a tiny crew (MicroSoft probably employs more people to clean their toilets than Acorn employed in total); but they also designed their own chipset.
So basically these guys designed an entire computer from the ground up, on a tiny budget and with a tiny workforce.

You can fault Acorn for many things - lack of development, lack of advertising - but you can never fault them for having the sheer balls to pull it off in the first place.

At the time the "Archimedes" was released, it was widely touted as the world's fastest desktop machine. It also boasted a display system that could spit out loads of different resolutions. My A5000 can output 640x480 at 256 colours, or 800x600 at 16 colours. It doesn't sound impressive, but this was using hardware developed in the mid '80s. The rest of the world (save Apple Macs) was using CGA and like.

Not a lot was made of the fast that the machines were RISC. Maybe Acorn figured the name of the operating system (RISC OS) was a big hint. Maybe they figured they had enough going for the machine without getting all geeky.

So when, in the early '90s, Apple announced the world's first RISC desktop machine, we laughed. And Acorn ran a good-humoured advert in the Times welcoming Apple to RISC.

The chipset was:

ARM2
This is the central processor, and originally stood for "Acorn RISC microprocessor" (rather than "ARM RISC machine", or whatever they've called it today (may I suggest "Advanced RISC microprocessor"?)).
MEMC1 (Anna)
This was the MEMory Controller. It was very soon replaced by the MEMC1a, which I do not think had a name.
The RiscPC generation of machines use a MMU (Memory Management Unit).
VIDC1 (Arabella)
This was the VIDeo Controller, though due to all it was capable of doing to pixels and sound, many knew it as the Very Ingenious Display Contraption. Certainly, the monitors that can be supported under RISC OS are few and far between. It is a trivial matter to switch from a modern 21" SVGA monitor to a television monitor.
The RiscPC generation of machines use the VIDC2, which takes it the logical step further. Unfortunately, the VIDC is no longer able to keep up with the latest advances in display driver technology. Enter J. Kortink!
IOC (Albion)
This was the Input/Output Controller, and it looked after podules and keyboards and basically anything that did I/O. In a flash of inspiration, it offered an IIC interface which is available on the expansion bus. My teletext receiver is hooked into this.
RiscPC generation machines use the IOMD which is like a souped up IOC.

The ARM250 (mezzanine / macrocell) offered the ARM chipset on one piece of silicon. It was used in the A3010 and A3020 machines. It may have also been used in the A4000, but I've not seen inside such a machine.

In the RiscPC, you have two processor slots. You can place your ARM processor in either. Or you can place an ARM in the first and a 80486 or 80586 class processor in the second.
If that doesn't whet your appetite, you can purchase a little device from Simtec which will allow you to install several processors. Unfortunately there isn't much software around that makes use of this. Then again, how much software would make proper use of a dual-Celeron motherboard?

ARM 1

I do not have any details on the ARM 1, except to say that I believe it was the processor used in the SpringBoard (PC interfaced ARM) and Brazil (BBC Master interfaced ARM), which originally contributed to the development of Arthur.

ARM 2

The ARM 2 processor was the first used within the RISC OS platform, in the A305, A310, and A4x0 range. It is an 8MHz processor that was used on all of the early machines, including the A3000.

ARM 3

Clocked at 25MHz (for the plastic part, or 30MHz for the ceramic part), this processor offers an additional 4K of on-board cache and the SWP instruction. An interesting effect is to turn the cache off (use the *Cache Off command) and the 25MHz processor will give you a very sluggish response, only marginally faster than an ARM 2.

ARM 250

The 'Electron' of ARM processors, this is an ARM 3 with the cache removed. Additionally the ARM, VIDC, IOC, and MEMC are on one chip, making the creation of a cheap'n'cheerful RISC OS computer a simple thing indeed. Certainly, many consumer electronics shops offered the Acorn A3010 and A3020 - but few knew how to operate it or set it up, so called it unreliable and tried to push you in the direction of a PC costing twice the price. Bastards.

ARM 4 and ARM 5

I don't know if these were ever actually created, they were not - to my knowledge - ever fitted into RISC OS machines.

ARM 6

This processor brought with it two important 'firsts'. The first first was the introduction of the RiscPC architecture. Acorn designed a computer with processor/memory on slot-in cards (the A540), but it never really took off despite being one of the few older-generation machines that could be expanded up to 16Mb of memory; most limited to 4Mb or (with varying degrees of stability) 8Mb.

The second first, and a point that went whizzing by with few people actually caring about it is that this was the first 32 bit ARM.
Yes, I did mean that.
Take a look at the Processor Status Register. What do you notice? I'll tell you. Bits 2 to 25 are used as the Program Counter. If we assume, as ARM did, that the bottom two bits are immaterial as the processor is word aligned, then the maximum addressing range of R15 (the Program Counter) is only 26 bits. In real-word terms, that is 64Mb maximum that the processor can address.
In the ARM 6 processor, the PSR has been seperated from PC to allow PC to be a full 32 bit addressing space (4Gb). The processor flags are stored in their own register, with a method for accessing and/or altering them.
The reason that this fact was passed by was that RISC OS didn't operate in 32 bit mode. Luckily, the processor provided a 26 bit mode. Indeed, one of the first things RISC OS does is switch the processor to 26 bit.

ARM 7

The ARM 7M provides instructions for multiplying two 32 bit values (signed or unsigned) and replying with a 64 bit result. These only work in 32 bit modes, while RISC OS works in 26 bit mode...

StrongARM

The StrongARM took the RiscPC from around 40MHz to 200-300MHz and showed a speed boost that was more than the hardware should have been able to support. Still severely bottlednecked by the memory and I/O, the StrongARM made the RiscPC fly. The processor was the first to feature different instruction and data caches, and this caused quite a lot of self-modifying code to fail including, amusingly, Acorn's own runtime compression system. But on the whole, the incompatibilities were not more painful than an OS upgrade (anybody remember the RISC OS 2 to RISC OS 3 upgrade, and all the programs that used SYS OS_UpdateMEMC, 64, 64 for a speed boost froze the machine solid!).
In instruction terms, the StrongARM can offer half-word loads and stores, and signed half-word and byte loads and stores.

The future

The future is here. Newer ARM processors exist, but they are 32 bit devices.
This means, basically, that RISC OS won't run on them until all of RISC OS is modified to be 32 bit safe. As long as BASIC is patched, a reasonable software base will exist. However all C programs will need to be recompiled. All relocatable modules will need to be altered. And pretty much all assembler code will need to be repaired. In cases where source isn't available (ie, anything written by Computer Concepts), it will be a tedious slog.
It is truly one of the situations that could make or break the platform.

I feel, as long as a basic C compiler/linker is made FREELY available, then we should go for it. It need not be a 'good' compiler, as long as it will be a drop-in replacement for Norcroft CC version 4 or 5. Why this? Because RISC OS depends upon enthusiasts to create software, instead of big corporations. And without inexpensive reasonable tools, they might decide it is too much to bother with converting their software, so may decide to leave RISC OS and code for another platform.

I, personally, would happily download a freebie compiler/linker and convert much of my own code. It isn't plain sailing for us - think of all of the library code that needs to be checked. It will be difficult enough to obtain a 32 bit machine to check the code works correctly, never mind all the other pitfalls. Asking us for a grand to support the platform is only going to turn us away in droves. Heck, I'm still using ARM 2 and ARM 3 systems. Some of us smaller coders won't be able to afford such a radical upgrade. And that will be VERY BAD for the platform. Look how many people use the FREE user-created Internet suite in preference to commercial alternatives. Look at all of the support code available on Arcade BBS. Much of that will probably go, yes. But would a platform trying to re-establish itself really want to say goodbye to the rest?
I don't claim my code is wonderful, but if only one person besides myself makes good use of it - then it has been worth it.

Click here to learn more on 32 bit operation

Return to assembler index