A Multibus board just sold for over $2000

Eric Smith spacewar at gmail.com
Wed Nov 9 15:07:14 CST 2016


On Nov 9, 2016 4:39 AM, "Marc Howard" <cramcram at gmail.com> wrote:
> Just going from memory but I had all the 432 data books at the time and I
> seem to remember that they actually had a 432 to bubble memory interface
> chip as well.

I don't think so.

At an early stage of 432 development, there was to be a 432 I/O Processor
(IOP), which would have used normal peripheral chips commonly used othe
Intel microprocessors. The IOP had its own instruction set, and would have
needed its own compiler(s), etc.

However, the IOP was cancelled in favor of something better, the 43203
Interface Processor (IP). The IP provided a bridge between the
object-oriented environment of the 432, and a conventional microprocessor,
known as the Attached Processor (AP), typically an 8086. This allowed any
8086-compatible peripheral chips to be used with the 432, and allowed any
8086 development tools, including compilers, to be used for the AP. In
practice, AP software was written in PLM-86 and ran on the iRMX-86
operating system or iRMX-88 kernel.

The Interface Processor looked like a 432 processor on the 432 side, but it
looked like a memory device to the Attached Processor. It occupied 64KB of
the AP address space, and provided four windows by which the AP could read
and write the data portion of objects in 432 memory. A fifth memory window,
the control window, was dedicated to managing the functions of the
Interface Processor itself.

The Interface Processor had an instruction set (called functions) but it
didn't have a program counter and didn't fetch the instructions. Rather, it
executed a function when told to do so by the Attached Processor. The AP
would write the operands and function code into the control window. Writing
the function code would trigger the IP to execute the function, and write
any results into the control window. The IP would generate an interrupt to
the AP when the function completed.

Except for the serial port and timer on the iSBC 432/100 eval board, the
432 General Data Processor (GDP) never performs any I/O. On the 432/100,
the 8251A USART and 8253 timer are memory-mapped into the special
"Interconnect" address space of the GDP, where it can be accessed by
special instuctions, but that is not used for I/O in normal 432 systems.

The 432 GDP instruction set includes message Send and Receive instructions
which work on Communication Port objects, and the Interface Processor
provides those functions for the Attached Processor. The process running on
the 432 GDP Sends an I/O request message (e.g., read or write a disk
sector) to a Communication Port used for such requests, then (usually) does
a Receive on a second Communication Port for a reply. Since the reply isn't
yet there, the process will block waiting for it, and the GDP will dispatch
another runnable process.

The AP receives the request message from the request Communication Port
(via the IP) performs the I/O, and Sends a reply message to the reply
Communication Port. At that point it's entirely possible that the GDP is
running a different process, but if so the reply will be enqueued add the
waiting process will be unblocked and moved to the run queue.

The whole scheme of Send, Receive, Communication Ports, and process
scheduling and dispatch is implemented by hardware and microcode, which
Intel called the "Silicon OS". By use of the Interface Processor, Intel
avoided any need to build 432-specific peripheral chips.

A typical Attached Processor subsystem used an iSBC 86/12A Multibus 8086
processor board, an iSBC 215 Multibus Winchester controller, snd iSBX 218A
floppy controller (8272/uPD765 based), and possibly additional serial
ports. Since iRMX 86 had driver support for the iSBC 254 and iSBX 251
bubble memory boards (both based on the D7220-1 Bubble Memory Controller),
in principle those should work fine with the 432's iMAX-432 operating
system, although I haven't heard of it actually being done.


More information about the cctalk mailing list