🚀 go-pugleaf

In response to the query about how to run two iSBC 86/30 CPU
boards on one MULTIBUS, and have both use the iSBC 215G
disk controller:

Don't do it!

Try this instead.  Treat the second 86/30 as a peripheral
board and have the "Master" board load "slushware" to it.
The iSBC 188/56 is an example of this type of "slave" board.
(iSBC 188/56 HRM Order Number 148209-001).

On power-up or reset, the firmware on the "slave" board
loops watching a control location for a "magic pattern".
The 188/56 F/W uses "RIGHTNOWGOTO".  The master board
powers up, goes thru the system confidence test (assuming
you have the 310 system firmware), enters the firmware
bootloader and loads your iRMX for the master.  Once
up you can either write a CUSP (if you are using the Human
Interface) or integrate code into your application job that
loads the desired program for the slave from disk into
the slave's dual port RAM or a shared MULTIBUS space.
The master sets a pointer in a prearranged shared location
(just before the "magic pattern" is a good place) and
sets the "magic pattern".  This causes the slave firmware
to transfer control to the location indicated by the pointer.

If the RAM on the slave that you wish to load to is not
visible to the master, you will have to do the job in two
steps (1) master loads a slushware loader into the part of
RAM that *is* visible to the MULTIBUS and starts it with
the "magic pattern" (2) master and slushware loader
cooperate to load the slave iRMX (or program).

If you write a CUSP to do this job you will have the ability
to load various programs to the slave, on command.

Or, you can treat the slave 86/30 and A/D SBX board (I'm
assuming it's an SBX board) as one "intellegent A/D
peripheral with dual port memory" and write a device
driver for it.  The slushware would be loaded during the
device_init portion of the driver attachment.  You could
set up a file in /config that specifies the file that
contains the slushware.

You should also set up some mechanism to "soft reset" the
slave.  A command in a shared data structure would tell
the slave slushware to soft reset (branch to the firmware).
This would be needed if you wanted to reload slushware
without a hard system reset.

Intel makes 310 systems called "APEX" that have up to four
iSBC 286/12 CPUs on one MULTIBUS and runs Xenix (trademark
of Microsoft).  These boxes use a similar scheme, that is,
only one CPU "owns" and controls the iSBC 214 disk controller.

For the record, the bootstrap algorithm for a 310 system
goes like this: The firmware bootloader reads the first
block on the first track of the device and uses the information
formatted thereon to determine the device characteristics
(ie winnie, floppy, 5", 8", 48 or 96 tpi, etc).  It then
loads and transfers control to the second stage bootloader
which is a binary image that has been formatted in a fixed
location on the first track by iRMX.  This program is Position
Independant Code, which means it was compiled COMPACT and
can be relocated by the firmware loader simply by setting up
the segment registers.  The firmware loader will do a
memory scan prior to loading the second stage, and will relocate
the second stage to the top of RAM.  (Some of the old
firmware bootloaders you encounter may not do this relocation).
A pointer to the name of the file to be loaded, a pointer
to the firmware device driver to use, and a pointer to an error
reporting routine are passed in registers.
The second stage knows how to search and access the iRMX
file system and will proceed to load and transfer control to
the target file.

FYI, I am an engineer with the Intel Custom Systems group
in Hillsboro Oregon.