“Every end implies a beginning.”

This post started out as a special Helios article, but given the rarity and historical importance of the used hardware, it’s now somewhere between the worlds of OS and Hardware – and the combination marks the end of an operating system and the launch of an incredibly successful processor family.

Helios is most likely already one of the loneliest OSes on the planet… I estimate about 10-20 active Helios installations of the Transputer version currently running. But the Helios ARM version supposed to run on my VLSI ARM eval boards is probably the only one on planet Earth.

Quick history digression

Talking about lonely… The  eval boards we’re discussing here, the VY86PID family, was what you could buy from VLSI. VLSI  founded  ARM Ltd. together with Acorn and Apple.
So you’re actually looking at the birthplace of your mobile phones processor right now. This is, where it all started!

When you’ve planned to build a computer based on VLSIs range of ARM CPUs back in the days – most notable the ARM6xx, 7xx and ARM7500 series – you got a VY86PID board . And because not many did – mind the Acorn RiscPC and Apple Newton – those boards are rare as hens teeth today. Googling for it will most likely bring you back here 😉
There’s just one good, original source of information left: The page of Art Sobel himself, Hardware Applications Manager for Embedded products at VLSI Technology, father of the boards discussed here.

Last question: “Why VY86PID? That sounds Intel’ish, like the x86 family.”
Well, VLSIs official name for their ARM IC range always started with VL or VY86… so  for example the fist mass-produced CPU, the ARM2, was officially called VL86C010. It’s memory controller was VL86C110 and they used  VY86C610 for the ARM610.  Only with the introduction of their last ARM CPU, they changed it and called the ARM7500 VY27073B…

Hardware

But now, let’s have a look at the eval boards first…

VY86PID 2

This is the earliest implementation of a PID I ever saw and own. Its components are:

• ARM600 CPU at 30MHz – soldered onto the board
• 4 SIMM slots for 1-16MB RAM
• MEMC3 memory controller on a 12MHz bus
• ‘INTWT’ INTerrupt (With Timer) controller (Maybe a VL86C410 derivative)
• VL16C552 Serial/Parallel controller serving an on-board connector each
• 128KB-1MB ROM (jumpers used for setting the size)
• one ISA compatible expansion slot
• 4 status LEDs, Reset- and Panic-buttons
• an empty PLCC68 socket for the FPA10 FPU from GECPlessey
• edge-connector to connect a ‘logic analyzer probe board’

It’s worth mentioning that both controllers, the MEMC as well as the INTWT were implemented in QuickLogic ‘pASIC’ QL8X12B 1st generation FPGA. That’s about 1000 gate arrays – tiny in today’s measures. That’s interesting as the MEMC was available as commercial ASIC already – but it that could only support 4MB explaining the appended version number “3”.
Also, take note that the PID2 uses an ARM600, not the later widely used 610 (RiscPC, Newton 1xx series). The 600 features support for a floating point co-processor, ARM Ltd. usually used the term floating point accelerator – this was only supported with the ARM600 & 700 and later integrated in the ARM7500FE.

VY86PID3

This is the PID3, sometimes also written PID III – this time it’s processor-independent for ARM610, 710, and 810 CPUs, featuring a connector for a CPU module which is 100% compatible to the ones used in the Acorn RiscPC.
Most parts are similar to the previous PID – even the FPGAs – so these are the notable differences:

• No CPU on-board – instead it offers a slot
• 10BaseT Ethernet port (SMC 91C94) with 4 status LEDs
• the empty PLCC socket was removed

Luckily I got an extensive manual with it, even containing all the schematics. Boy, those were the days, when manuals were real manuals!

The PID3 with (dis)connected CPU board (it’s an ARM710 card from Acorn RiscPC)

So far for the hardware. Both run a rudimentary monitor program from ROM – so let’s have a look into that…

Software

Out of the box the PIDs run a monitor program called “DEMON”, short for DEbug MONitor.
As with most single board computers (eg. Motorola VME boards) those monitors are more or less command-line BIOSes with some debugging features (read/write memory & registers) and are mainly used to load binaries and start them.

 

The toolchain which came with the eval boards is available here. It even includes a (cross)C-compiler and libs in source!

Helios (so far…)

This was the reason why I bought the boards – getting Helios run on ARM. The original Helios sources which I’m hosting on github also came with a kernel for ARM, specifically the Acorn Archimedes and, well, the PID2…

Historical side note: Why Helios on ARM? Well,  at the time this port was done it became obvious that the INMOS Transputer wasn’t developing as fast as other CPU families did and so Perihelion, like other INMOS customers,  turned towards alternative architectures. Also they looked for more profitable market: “The emphasis by this time was to make an embedded real-time system rather than an interactive Unix clone” [Nick Garnett, designer of Helios] Set-top boxes come to my mind… and later SGS-Thomson was quite successful in that area with their Transputer based ST20 family.

There are 2 supposed ways on getting Helios onto a PID – both using an RS232 connection:

1. load the kernel through the Helios server (that’s the DOS/Unix terminal tool) which then talks to the DEMON or
2. Have Helios burned into EPROMs instead of DEMON.

I wasn’t able to get the EPROMs work (binary image here) – or more precisely, connect to the system. It didn’t accept connections from the server, even the readme says so. The LEDs a showing a heartbeat pattern, so I assume the kernel is running – but without a shell connection I can’t tell more.

The alternative way by uploading through the server looked more promising… I got it stable at 38400 baud and using the debug flag (ctrl-shift-c) I could see the bytes flying upwards…

…but then it looses the connection, misses an ACK and then  fails to send the system config.  The server – while successfully initialized – then sits and waits forever  😥

To be continued…