resurrecting the Intel iAPX-432 32-bit microprocessor

[Eric Smith]

On Wed, Jul 22, 2015 at 12:48 AM, Nigel Williams
<nw at retrocomputingtasmania.com> wrote:
>> The 43201 has 4K words of 16 bits of vertical microcode ROM, however
>
> Do you know if this was where the so-called “SiliconOS” was stored? was it simply mixed in with the regular instruction set? For others the SiliconOS provided quite high-level constructs like resource-scheduling (multi-tasking) and other operating system like functions, hence the name.

Depending on exactly what you consider to be included in the
"SiliconOS", it's implemented by the combination of dedicated hardware
and the microcode. The hardware aspect is the memory management, which
organizes memory into segments indexed by a two-level segment
directory, enforces access rights to the segments, and prohibits use
of access descriptors (capabilities) as data and vice versa.

The microcode contains the initialization code, fault handling, object
operations, and the more complex instructions, including floating
point instructions and all of the object instructions.

> I guess the other challenge with original iAPX 432 software, if I have this right, is how dependent it was on the iRMX-86 environment which was used to bootstrap iMAX?

iMAX could be bootstrapped either from a Series III MDS running
DEBUG-432 on the x86 under the RUN environment of ISIS-II, or from an
iRMX-86 system.

However, if you wanted any I/O other than just debug output (roughly
equivalent to printf), such as terminals or disk drives, you had to
have a peripheral subsystem with an 8086 ("Attached Processor")
running iRMX-86, interfaced to the main 432 system via a 43203
Interface Processor (IP).  iMAX-432 included the 8086 code that ran on
the peripheral subsystem.

If you're not using iMAX-432, e.g., because there isn't a copy, and
developing your own software, there is no specific dependency on the
8086; the Attached Processor could be just about anything you could
interface to an 8-bit or 16-bit bus.

What I have at hand is the Release 1.0 GDP ("General Data Processor"),
the 432 main processor.  There were three major releases of the 432
architecture, and software was *very* specific to a release. Intel had
an early version of minimal iMAX-432 running on Release 1.0, but I
don't think they shipped that to customers, because 1.0 was quickly
replaced by 2.0 and 2.1, which had architectural changes to fix
problems in fault handling, and other bug fixes. The Release 1.0 GDP
was only shipped to customers in the 432/100 evaluation board, which
did not run iMAX-432.  Instead the 432/100 shipped with Object
Programming Language (OPL-432), a dialect of Smalltalk, and Object
Builder, a set of OPL-432 classes to allow experimentation with native
432 objects.

Unfortunately I don't have a copy of OPL-432 or Object Builder either,
which is why I'm working on my own software from scratch.

Also I don't have a Release 1.0 Interface Processor, so I'll have to
do my own thing for I/O. The 432/100 didn't use an IP; instead
software on the 8080 or 8085 of the MDS directly accessed the 432 data
structures in the physical address space (similar to what DEBUG-432
does). I'll probably try to implement functionality roughly equivalent
to the Interface Processor largely in software running on the ARM core
in the Xilinx Zynq.

> On your website you mention you have some VAX VMS software that supported the iAPX 432? does this include any form of cross-compiler? have you tried to resurrect any of it?

I have a partial copy of the Cross Development System (CDS-432) for
VMS, and a partial copy for VAX BSD. Both have missing and corrupted
files, rendering them unusable. Also both are for different releases
of the 432 architecture.