Acorn Archimedes: A dive into the late 80s

All of this wasn't easy to find, most home computers at that time were using planar graphics and some used many dedicated components to do stuff faster (eg: Amiga 500), this made them slightly harder to master and more complex on the hardware side although they were cheaper than the Archimedes.

On the development tools requirement most computers at that time were bundled with a BASIC environment but most were not that great (performances or features) and were not able to let the user go on lower level (assembly) as needed.

Of all the computers of that time the Archimedes stand out for checking all the points above and many more like compatibility of software up to this day due to the long standing and still being worked on RISC OS / ARM combinations: software written for the late 80s machines can still work nowadays on a Raspberry PI running RISC OS for example which is admirable considering how fast things get flushed out in computing history.

Id guess the Macintosh II was also attractive and matched some of the requirements but those were double the price so i do not consider them as home (affordable) computers although they were much better in term of graphics capabilities.

A rare alternative also is the Enterprise 128 released in 1985 which had a 256 colors chunky frame-buffer with a 3-3-2 bit RGB palette, a good BASIC and custom chips (which are somewhat linked to Acorn due to one of its designer), the main drawback of the Enterprise is that the 256 colors mode was very low resolution (80x256) and it was still a 8-bit machine. (Z80A CPU)

To digress further on 8-bit machine the early Atari XL/XE were also very interesting machines with powerful graphics capabilities for the time (due to dedicated components) as seen on all the wonderful demos, some display modes (GTIA) can get pretty close to a chunky frame-buffer!

In term of amount of colors the Commodore Plus/4 is also a great alternative for the time with its 121 colors palette (although playing on luminance) and 320x200 mode.

Back to the 16-bit / 32-bit a common alternative were PCs based on Intel 80286 or i386 CPU, i somewhat like the 80286 due to being 16-bit (although i dislike segmented memory), there is a wide choice also in video standards on PC such as 256 colors MCGA (roughly 2x the price of the Archimedes at the time though) or even VGA, some of the video modes are incredibly simple to program.

There is also powerful Japanese computers such as the FM Towns and X68000 but those were much more expensive than the Archimedes. (double if not more the price)

There is also all the non home computers which were used for industrial stuff such as the Aesthedes which had powerful graphics capabilities but this is another category...

Hardware

The Acorn Archimedes started in 1987 with the 400 series and its 8 MHz ARM2 RISC CPU with three custom chips dedicated to memory (MEMC), video / sound (VIDC) and I/O (IOC) controls.

It was declined in different models with different memory capacity. (up to 8Mb then up to 16Mb with the introduction of ARM3 in late 1990)

The ARM 2 had about 4 MIPS (7 MIPS on later models when clock frequency was increased to 12 MHz) with 27,000 transistors which was less transistors than late 70s 16-bits CPU such as Intel 8086, this show how efficient and ahead of its time RISC design was.

It was one of the fastest home computer in 1987 due to the simplicity and elegance of the newly built ARM / RISC architecture, most instructions takes as low as one clock cycle to execute.

As an example, there was no need of custom chips for memory load/copy because the CPU was already capable of loading or copying up to 15 words efficiently (32 bits data) with a single instruction (stm*, ldm*) and with a ~4x speedup (maybe even more !) compared to similar instructions on Motorola 68000 CPU. It could also beat PCs with Intel 286 / early 386. There was no custom chips to draw graphics such as sprites, these were all handled in software.

In 256 colors modes with one instruction you can fetch / copy up to 52 pixels at a time, with one instruction you can also clear the screen 56 pixels blocks at a time in few clock cycles. (note: this is not a full replacement of a Bit blit custom chip such as in Amiga which do way more than just a fast load/copy but the CPU / hardware is so fast that it will be on par in the end although it is more limited for some tricks)

The ARM instruction set is also packed with smart features such as reusing its barrel shifter for immediate value encoding which is a bit confusing at first. There is a total of nine basic instruction types.

The barrel shifter can be used at the same time as other instructions (you can do a MOV with a bit shift in a single cycle) this allow fast single-instruction operations.

Instructions can also 'embed a condition' (eg. execute instruction if some flag is set) so you can sometimes group instructions as a single instruction, this help code density and performances.

The ARM2 had no cache yet (also no branch predictor) because RAM/CPU speed were roughly on par (cache came later with the ARM3 in 1990 machines), the absence of cache and the overall simplicity of the CPU make it a bliss to program for, there is very few hidden abstraction layer when it come to optimize code, it also had plenty registers (16 with more available by switching processor mode), all except the last one were general purpose registers.

The few 'hidden abstraction' are due to the custom chips / ram, for example alignment may matter.

Higher level languages were also able to generate effective code due to its RISC nature.

One of the downside of the ARM CPU was code density due to all instructions being encoded as 4 bytes so a program took more memory than if it was using x86 instructions for example, even worse if the program used aggressive optimization like loop unrolling, this may have been improved with the ARM3 and its cache though.

The early ARM CPU have a multiply instruction which was quite fast which took 2 cycles at best and 17 cycles at worst, it doesn't have a divide instruction though and has no hardware support for floating-point arithmetic as standard, floating-point arithmetic is available through emulation by RISC OS or with additional hardware.

* 32-bit data bus
* 26-bit address bus giving a 64-MByte uniform address space
* Support for virtual memory systems
* Simple but powerful instruction set
* Co-Processor interface for instruction set extension
* Good high-level language compiler support
* Peak execution rate of 10 million instructions per second (MIPS)
* Fast interrupt response for real-time applications
* Low power consumption (0.1 W typical) with a single +5 V supply
* 84-pin JEDEC B leadless chip carrier or plastic leaded chip carrier

As for the low power VIDC (Video Controller), it is highly programmable with 8, 12, 16 or 24MHz pixels rate and plenty modes. This combined with highly programmable screen parameters allow it to reach very high resolutions in monochrome mode, this wasn't common in 1987 in home computers, it is a very flexible controller albeit with an odd 256 colors palette choice. (see graphics capabilities below)

There is plenty more to the hardware side of the Archimedes like podules (additional modules which were handy to add SCSI drives, MIDI, video capture cards etc.) which will be not talked here because i simply didn't explored them yet. There is also FPU like the Acorn AKA20 We32206 Floating Point Co-Processor and FPA10 for the ARM3.

Of historical significance the ARM250 (starting with the A3010 in 1992) was also the worlds first System on a Chip (SoCs) a single-chip design including the functionality of an ARM2 / ARM3 (still without cache), the IOC1, VIDC1a and MEMC1a chips all integrated into a single chip. The ARM250 was in-between ARM 2 and ARM 3 and was running at a clock frequency of 12 MHz, it was also used in conjunction with slightly faster memory chips.

So what about the hardware downsides of the Archimedes ? If taken as-is the hardware was great but of course there is always shortcoming due to making compromises, some downside which can be cited are the 4 MB RAM limit on the early Archimedes, shared video memory and not that quick Podule bus which made some things impossible like a real graphics card. Most of those issues are not that big and were handled later on but they still exist on early Archimedes. As for the durability some of the early Archimedes now suffer from battery leakage. The early memory controllers also had some issues.

To conclude on the hardware side of the Archimedes, we can say that this computer was mostly relying on the usage of its fast CPU for everything with the help of a few elegantly built custom chips for memory / video / IO.

Software (RISC OS 2 and 3)

I actually do all my Archimedes programming under RISC OS 3 running on a ARM3 35MHz Archimedes (with Arculator), i have built my own dedicated macro assembler which can be seen as a simple wrapper to the BBC BASIC V inline assembler (but more focused on writing low-level machine code), all of that from scratch with bundled stock software, nothing else was ever needed.