Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!husc6!mit-eddie!genrad!decvax!decwrl!amdcad!cae780!tektronix!reed!omssw2!kwb From: kwb@omssw2.UUCP (Kurt Bailey) Newsgroups: comp.sys.intel Subject: Re: Multibus I, iRMX86 question Message-ID: <527@omssw2.UUCP> Date: Tue, 25-Nov-86 14:47:25 EST Article-I.D.: omssw2.527 Posted: Tue Nov 25 14:47:25 1986 Date-Received: Wed, 26-Nov-86 20:15:17 EST References: <5363@dartvax.UUCP> Reply-To: kwb@omssw2.UUCP (Kurt Bailey) Distribution: net Organization: Intel Corp., OMS Div., Systems Group, Hillsboro, OR Lines: 79 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.