Processor Types

ARM 1 (v1)

This was the very first ARM processor. Actually, when it was first manufactured in April 1985,
it was the very first commercial RISC processor. Ever.
As a testament to the design team, it was "working silicon" in it's first incarnation,
it exceeded it's design goals, and it used less than 25,000 transistors.

The ARM 1 was used in a few evaluation systems on the BBC micro (Brazil - BBC interfaced ARM),
and a PC machine (Springboard - PC interfaced ARM).
It is believed a large proportion of Arthur was developed on the Brazil hardware.
In essence, it is very similar to an ARM 2 - the differences being that R8 and R9 are not banked
in IRQ mode, there's no multiply instruction, no LDR/STR with register-specified shifts, and no
co-processor gubbins.

ARM evaluation system for BBC Master(original picture source not known - downloaded from a website full of
BBC-related imagesthis version created by Rick Murray to include zoomed-up ARM down the
bottom...)

ARM 2 (v2)

Experience with the ARM 1 suggested improvements that could be made. Such additions as the MUL
and MLA instructions allowed for real-time digital signal processing. Back then, it was to aid
in generating sounds. Who could have predicted exactly how suitable to DSP the ARM would be,
some fifteen years later?
In 1985, Acorn hit hard times which led to it being taken over by Olivetti. It took two years
from the arrival of the ARM to the launch of a computer based upon it...

...those were the days my friend, we thought they'd never end.
When the first ARM-based machines rolled out, Acorn could gladly announce to the world that they
offered the fastest RISC processor around. Indeed, the ARM processor kicked ass across the
computing league tables, and for a long time was right up there in the 'fastest processors'
listings. But Acorn faced numerous challenges. The computer market was in disarray, with some
people backing IBM's PC, some the Amiga, and all sorts of little itty-bitty things. Then Acorn
go and launch a machine offering Arthur (which was about as nice as the first release of Windows)
which had no user base, precious little software, and not much third party support. But they
succeeded.

The ARM 2 processor was the first to be 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. The ARM 2 is clocked at 8MHz, which translates to approximately four and a half million
instructions per second (0.56 MIPS/MHz).

No current image - can you help?

ARM 3 (v2as)

Launched in 1989, this processor built on the ARM 2 by offering 4K of cache memory and the SWP
instruction. The desktop computers based upon it were launched in 1990.
Internally, via the dedicated co-processor interface, CP15 was 'created' to provide processor
control and identification.
Several speeds of ARM 3 were produced. The A540 runs a 26MHz version, and the A4 laptop runs a
24MHz version. By far the most common is the 25MHz version used in the A5000, though those with
the 'alpha variant' have a 33MHz version.
At 25MHz, with 12MHz memory (a la A5000), you can expect around 14 MIPS (0.56 MIPS/MHz).
It is interesting to notice that the ARM3 doesn't 'perform' faster - both the ARM2 and the ARM3
average 0.56 MIPS/MHz. The speed boost comes from the higher clock speed, and the cache.

Oh, and just to correct a common misunderstanding, the A4 is not a squashed down version of the
A5000. The A4 actually came first, and some of the design choices were reflected in the later
A5000 design.

ARM3 with FPU(original picture downloaded from Arcade BBS, archive had no attribution)

ARM 250 (v2as)

The 'Electron' of ARM processors, this is basically a second level revision of the ARM 3 design
which removes the cache, and combines the primary chipset (VIDC, IOC, and MEMC) into the one
piece of silicon, making the creation of a cheap'n'cheerful RISC OS computer a simple thing
indeed. This was clocked at 12MHz (the same as the main memory), and offers approximately 7 MIPS
(0.58 MIPS/MHz).
This processor isn't as terrible as it might seem. That the A30x0 range was built with the ARM250
was probably more a cost-cutting exercise than intention. The ARM250 was designed for low power
consumption and low cost, both important factors in devices such as portables, PDAs, and
organisers - several of which were developed and, sadly, none of which actually made it to a
release.

No current image - can you help?

ARM 250 mezzanine

This is not actually a processor. It is included here for historical interest. It seems the
machines that would use the ARM250 were ready before the processor, so early releases of the
machine contained a 'mezzanine' board which held the ARM 2, IOC, MEMC, and VIDC.

ARM 4 and ARM 5

These processors do not exist.

More and more people began to be interested in the RISC concept, as at the same sort of time
common Intel (and clone) processors showed a definite trend towards higher power consumption and
greater need for heat dissipation, neither of which are friendly to devices that are supposed to
be running off batteries.
The ARM design was seen by several important players as being the epitome of sleek, powerful RISC
design.
It was at this time a deal was struck between Acorn, VLSI (long-time manufacturers of the ARM
chipset), and Apple. This lead to the death of the Acorn RISC Microprocessor, as Advanced RISC
Machines Ltd was born. This new company was committed to design and support specifically for the
processor, without the hassle and baggage of RISC OS (the main operating system for the processor
and the desktop machines). Both of those would be left to Acorn.

In the change from being a part of Acorn to being ARM Ltd in it's own right, the whole numbering
scheme for the processors was altered.

ARM 610 (v3)

This processor brought with it two important 'firsts'. The first 'first' was full 32 bit
addressing, and the second 'first' was the opening for a new generation of ARM based hardware.
Acorn responded by making the RiscPC. In the past, critics were none-too-keen on the idea of
slot-in cards for things like processors and memory (as used in the A540), and by this time many
people were getting extremely annoyed with the inherent memory limitations in the older hardware,
the MEMC can only address 4Mb of memory, and you can add more by daisy-chaining MEMCs - an idea
that not only sounds hairy, it is hairy!
The RiscPC brought back the slot-in processor with a vengeance. Future 'better' processors were
promised, and a second slot was provided for alien processors such as the 80486 to be plugged in.
As for memory, two SIMM slots were provided, and the memory was expandable to 256Mb. This does
not sound much as modern PCs come with half that as standard. However you can get a lot of milage
from a RiscPC fitted with a puny 16Mb of RAM.

But, always, we come back to the 32 bit. Because it has been with us and known about ever since
the first RiscPC rolled out, but few people noticed, or cared. Now as the new generation of ARM
processors drop the 26 bit 'emulation' modes, we RISC OS users are faced with the option of
getting ourselves sorted, or dying.
Ironically, the other mainstream operating systems for the RiscPC hardware - namely ARMLinux and
netbsd/arm32 are already fully 32 bit.

Several speeds were produced; 20MHz, 30Mhz, and the 33MHz part used in the RiscPC.
The ARM610 processor features an on-board MMU to handle memory, a 4K cache, and it can even
switch itseld from little-endian operation to big-endian operation. The 33MHz version offers
around 28MIPS (0.84 MIPS/MHz).

ARM 710 (v3)

As an enhancement of the ARM610, the ARM 710 offers an increased cache size (8K rather than 4K),
clock frequency increased to 40MHz, improved write buffer and larger TLB in the MMU.
Additionally, it supports CMOS/TTL inputs, Fastbus, and 3.3V power but these features are not
used in the RiscPC.
Clocked at 40MHz, it offers about 36MIPS (0.9 MIPS/MHz); which when combined with the additional
clock speed, it runs an appreciable amount faster than the ARM 610.

ARM 7500

The ARM7500 is a RISC based single-chip computer with memory and I/O control on-chip to minimise
external components. The ARM7500 can drive LCD panels/VDUs if required, and it features power
management. The video controller can output up to a 120MHz pixel rate, 32bit sound, and there are
four A/D convertors on-chip for connection of joysticks etc.
The processor core is basically an ARM710 with a smaller (4K) cache.
The video core is a VIDC2.
The IO core is based upon the IOMD.
The memory/clock system is very flexible, designed for maximum uses with minimum fuss. Setting up
a system based upon the ARM7500 should be fairly simple.

ARM 7500FE

StrongARM / SA110 (v4)

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. Also provided are instructions for multiplying two 32 bit values
(signed or unsigned) and replying with a 64 bit result. This is documented in the ARM assembler
user guide as only working in 32-bit mode, however experimentation will show you that they work
in 26-bit mode as well. Later documentation confirms this.
The cache has been split into separate instruction and data cache (Harvard architecture), with
both of these caches being 16K, and the pipeline is now five stages instead of three.
In terms of performance... at 100MHz, it offers 114MIPS which doubles to 228MIPS at 200MHz
(1.14 MIPS/MHz).

In order to squeeze the maximum from a RiscPC, the Kinetic includes fast RAM on the processor
card itself, as well as a version of RISC OS that installs itself on the card. Apparently it
flies due to removing the memory bottleneck, though this does cause 'issues' with DMA
expansion cards.

A Kinetic processor card.

SA1100 variant

This is a version of the SA110 designed primarily for portable applications. I mention it here
as I am reliably informed that the SA1100 is the processor inside the 'faster' Panasonic
satellite digibox. It contains the StrongARM core, MMU, cache, PCMCIA, general I/O controller
(including two serial ports), and a colour/greyscale LCD controller. It runs at 133MHz or 200MHz
and it consumes less than half a watt of power.

Thumb

The Thumb instruction set is a reworking of the ARM set, with a few things omitted. Thumb
instructions are 16 bits (instead of the usual 32 bit). This allows for greater code density in
places where memory is restricted. The Thumb set can only address the first eight registers, and
there are no conditional execution instructions. Also, the Thumb cannot do a number of things
required for low-level processor exceptions, so the Thumb instruction set will always come
alongside the full ARM instruction set. Exceptions and the like can be handled in ARM code, with
Thumb used for the more regular code.

Other versions

These versions are afforded less coverage due, mainly, to my not owning nor having access to any
of these versions.
While my site started as a way to learn to program the ARM under RISC OS, the future is in
embedded devices using these new systems, rather than the old 26 bit mode required by RISC OS...
...and so, these processors are something I would like to detail, in time.

M variants

This is an extension of the version three design (ARM 6 and ARM 7) that provides the extended
64 bit multiply instructions.
These instructions became a main part of the instruction set in the ARM version 4 (StrongARM,
etc).

T variants

These processors include the Thumb instruction set (and, hence, no 26 bit mode).

E variants

These processors include a number of additional instructions which provide improved performance
in typical DSP applications. The 'E' standing for "Enchanced DSP".

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.