Intel System 320 Multibus System

Most recent revision of this page Sept 17 2023(C) Herb JOhnson.

This is a description of my 2012 work on three Intel-designed 80386 terminal servers, Multibus based. My thanks to David Comley who provided these systems to me in Sept 2008; and to Northwest Technical for providing a Xenix on a hard drive. In 2012 I worked with Bill Beech who had System 310 systems.

In 2016-18 I was in discussion with Bill Beech, Richard Main, Eric Smith and others about 310/320 Intel systems and Intel Multibus hardware running ISIS. There's a Web page among my "restore" Web pages, about their work with ISIS and Multibus.

In 2018, Bill Beech and I compared notes on our 320 backplanes and power supplies, see the linked Web page for details, including schematics for the 320 chassis/backplane. In 2023, I made a disk-image backup of the Xenix system. - Herb JOhnson

The Intel System 320

Here's the Intel 320 front and Here's the rear from above and the rear showing some of the installed cards.
Here's a lable showing the System 320 board manifest (list). It lists, in order as installed from the topmost slot:
SBC 214, Peripheral Controller
SBC 386/22 2MB CPU, 16MHz (Multibus card) with two iSBC MM03 memory modules
SBC 547, 8 channel serial comm card
The peripherals connected to the 214 are:
HH 5.25" Floppy 320K
Archive Scorpion cartridge drive 5945C, 60MB Streaming tape drive
Archive Scorpion SAC (stand alone controller) SASI board (for tape drive)
Quantum 540 40MB Full-height MFM hard drive

the boards

As of mid-2011 I had THREE 320 chassis, THREE CPU boards, THREE controllers, and three comm cards. I got one running. In Oct 2011 I sold one 320 chassis and one CPU board. Below are the magic numbers for the active and working system in discussion here and its cards.

CPU board: 386/12 PBA 149129-007, AA 149644-016, PB 149693-001
ROM set 452112-001 452112-002
two RAM boards: PBA 454073-002, SCB MM02; PBA 148332-010 SCB MM02
The jumper areas for this board are here and also here.

controller board SBC 214: PBA 135837-008 SNP 356325
PB 148298-001 N 885414-C-1B
ROM set 455467-001, 455468-001; 8742 455466-001

SBC 547: 8-port serial card with local processor. Two boards in current active system.

Archive Corp SASI board: 20574-0141A, ROM 80182-018
Archive cartridge drive 5945C

the ROMS

386/20

There are two 128Kbyte ROMS with the 386/20 CPU board, Intel numbers 452112-001 and 452112-002. These are "high-byte" and "low-byte" ROMS, as the processor reads both ROMS at once as a 16-bit word. here's the hex -001 and the hex -002 , and the binary -001 and binary -002 .

I looked at the ROM contents in November 2008. When I dumped the ROMS on a reader, I was left with these two high and low files. I wrote a C program to merge the two; a copy is at this link. The program reads two Intel hex format files, and produces a merged hex file result.

Having the merged ROM image, a disassembler and a hex dump/inspection tool can be used to examine the binary. (There are many hex/binary programs around.) Inspection shows that the ROMS occupy the upper-most part of memory space, where the 80386 looks for reset and other vectors. HEre's a disasembly file in progress, showing portions of ROM memory. An ASCII dump of ROM also shows some useful commands and descriptions buried in the ROM. Here's some exerpts of text from the ROMs.

Mentioned in the ROMS are "V6.2", "iRMX86 Bootstrap loader", file dates for 19 Jan 1987, and various test commands. From three CPU cards, I found one of them would try to boot and then come up to a command prompt. In this mode, I could run "wh" for help, "wt" for tests, "wu" for utilities. These tests allowed me to verify the other cards. I could not "verify" the two Quantum MFM hard drives which came with the systems (see below); a MFM drive I had on hand seemed to respond.

iSBC 214 (2018)

The working '214 PDA 135837-008, has two Intel 27128 PROMs and one Intel 8742 programmable controller. The part numbers for the ROMS are 455467-001 U45 and 455468-001 U64. The 8742 is 455466-001. Here's the Intel hex record dump of those ROMs and controller. Note the '214 has an intel 80186 CPU as local controller, and presumbably reads the two 27128 PROMs.

Jumper settings on this board are: E19, E22, E2 E4 E97 E101 E103 E126 E105 E111 E113 E115 E117 E119 E121 E75 E57 E77 E29 E36 E31 E144 E38 E11 E17 E15 E79 E82 E135 E137 E142 E86 E90 E92 E94. I've tried to refer to the LOWEST number of a pair of jumpers; so "E17" means jumper E17 to E18. I hope....

iSBC 214 (2016)

Previously , I read off the same chips on one of the other three '214's I have - NOT the board in use on the working 320 system. This one and the others, did not work when swapped with the working '214. Why? It seems the two other '214's are PDA 135837-007. Here's the ROMS and 8742 code for iSBC214 s/n 178105 PDA 135837-007. The ROMS are labled 450737-001 U45, 450738-001 U64. The 8742 is 450736-001.

IN discussions noted at the end of this Web page, Al Kossow noted he has ROM images for many Intel Multibus cards at this link on bitsavers. HIs '214 ROM images are the same as on my -007 model, ROM and CPU 450736/7/8.

Quantum drives with this system

The two Quantum 540 (?) drives with these systems look physically the same, and they turn out to have the same problem. Neither drive would enable, one would spin up but not the other. In handling one of the drives I heard a wrattle in the HDA (head-disk assembly, where the platters and head are encased). That suggested to me a broken head - the drive would be useless, so I decided to open it up.

This photo shows the drive's HDA open to the world. See any problems? The scale that is used to mark the location of each track is fallen off the head assembly. HEre's a closeup of where the scale mounts.. It's shocking to see that it is glued on, with no mechanical registration marks or holes! A closer look at the mounting area confirms this. And, here's a closeup of the scale, with the Quantum copyright. Not seen in the photo is the "smudge" where some residue of glue remains. I'll try to photograph that another day.

Archive tape drive with this system

as identified above the System 320 has an Archive Scorpion cartridge drive 5945C, 60MB Streaming tape drive; controlled by an Archive Scorpion SAC (stand alone controller) SASI board. The SAC apparently has numbers 80182-010 and (PAL?) 20467-001, and dates from about 1982 or 1983. On that SAC is an Archive IC of some sort.

Over time I've acquired other Archive tape cartridge drives and controllers. Here's a Web page with photos and descriptions of those other items. Later below, I use the tape drive to create a TAR backup.

My friend Bill Beech acquired an Intel Multibus System 310 some years ago. On that 80286 based system there's also an Archive tape drive and Archive controller, which look very close to mine. He appears to have a 214 hard/floppy controller like mine too. His Archive controller also has a number 80182-010 and the same IC layout as mine. In 2018-19 Bill will look at other Archive tape drives and controllers.

Operating Systems

the Intel OEM systems like the System 320, ran Intel's iRMX operating system. iRMX system was sold with 8086, 80186, and 80286 systems. About the time of the 80386, Intel offered iRMX and Xenix, a Microsoft Unix licenced from AT&T and only sold to OEM'S (Original Equipment Manufacturers) such as Radio Shack and IBM and other system producers. Xenix was derived from Unix System 6 and had some BSD-related features. The following is from discussions I've had with Patrick Wong of Northwest Technical about the System 320, in Feb 2009. - Herb Johnson

As far as the documentation we have shows, the version of RMX-86 that we are familiar with, only supports builds for the 86, 186 and 286 series boards--not the 386 boards. Are you certain that the 386-based SYP320 systems you acquired actually successfully ran a standard iRMX86 version on the Q540 drives? So far we have not been able to get the 386/2x to boot any RMX-86 or RMX286 disks. RMX-III, that is supposed to run on the 386/2x platform, requires a minimum of 75MB disk space and at least 4MB of RAM memory. I think you have 2MB on you CPU board.

(I have two 2MB memory boards on the running 386/22 CPU board. My guess about running iRMX was based on a text string in the ROM. My 1987 Intel OEM Systems Handbook discusses System 310 with the 286, the 386/20 board, and barely mentions 386 products which "address up to 16MB of memory". iRMX286 apparently will run in as low as 700KB of memory. - Herb)

Intel's Xenix 3.5 for the SYP320 Systems (latest version) would probably be a better choice, depending on your need. It is FAR MORE hardware tolerant and supports multi-users. There are several good downloadable Xenix manuals at tenox.tc. Using a Xenix 3.5 Q540 disk, we have successfully booted 286/14, 386/21 & 386/24 boards....[Otherwise] you will need to find RMX-III (for your 386/2x boards), a larger HD and more RAM memory.

The same SBC386/2x firmware EPROMs run both the RMX and Xenix OS, so you shouldn't automatically assume that because you saw "iRMX86" in the firmware listing you created, that the Q540 HD's had RMX on them.

In fact, by far, most of the hundreds of SYP310 and dozens of SYP320 sytems that have come across our test benches, have had various releases of Intel's Xenix on them. Some had Unix and relatively few had RMX-I and RMX-II. In fact, many of the Xenix-based systems were identical to your configuration.

Intel's software and hardware evolved separately. Roughly ...
RMX-I (RMX86) supported 86, 186 & 286 - Multibus I
RMX-II (RMX286) supported 286 & 386 - Multibus I & II
RMX-III (RMX386) supported 386 & 486 - Multibus I & II

The comments in the RMX forum seem to support this. Considering the fact that your systems are 386-based, and that your HDs are only 40MB, chances are, your Q540 HDs had Xenix on them. - Northwest Technical

In 2012 I got some OS comments from Bill Beech: > Under OS's, Intel sold Xenix on the government contracts handled by SMS. We could NOT buy iRMX. It was NOT just their OEMs they sold to. I don't believe SMS was an OEM in this case - Intel was an active partner in this contract.Also, Xenix for the 310 with the 286/10 or 12 was full multiuser.

Xenix from Northwest Technical

In late March, Northwest Technical provided a formatted Quantum hard drive with Xenix for a similar System 320. On April 1st, we installed the drive, and reinstalled a tape drive, onto the system. Here's an inside view of the chassis with tape drive, floppy drive and hard drive in place. Then we attached our Wyse 30 terminal and powered up.

With not much fuss, we booted into the diagnostic monitor (that's on ROM). It ran the usual diagnostics for the drives and boards. With the hard drive in place, it passed all of them. For the first time, the ROM monitor asked me about iMON-386 or iSDM, two ROM monitors for further tests and utilities. Saying no to both, it entered the "bootloader".

Then we loaded Xenix R3.5!. It found the 214 card and its UART. There was a choice to run single-user or multiuser mode. Simply waiting without entering "return", Xenix came up in multiuser mode. I entered the date, logged in as root, did a few simple commmands, looked around the file system. Then I entered "shutdown 0", to sync the hard drive and shut down the OS.

backup to tape utility diskette

On Nov 9 2018 (some time later!) I "imaged" the floppy/tape backup program diskette, using an MS-DOS system, a disk image using ANADISK (Sydex product) as XENIX1.ANA and with imagedsk (Dave Dunfield utility) as XENIX1.IMD. Consider the following. 1) track 0 side 0 was reported on my equipment to be *unformatted* and skipped on the IMD file. 2) the IMD file is in imagedisk IMD format. 3)The ANA file is in Anadisk "binary" format, whatever that is. 4) both report the disk as 40 tracks, double-sided double-density, four 1024 byte sectors, 1:1 interleave. However, on subsequent examination in late Dec 2018, it's likely the diskette's first track is single-density with 128 byte sectors, possibly with boot-time code to load the rest of the diskette. More on that single-density track is below.

A hex-dump comparison of the two recovered files, shows consistent results. Apparently the Xenix program which formatted the diskette, formats blank sectors as "DEADDEADDEAD.." The first useful sector (track 1 side 1 sector 1) has the string "XENIX_R3-5 $ $Date: 86/05/30 12:59:45 $". In late Nov 2018, Bill Beech did an automated disassembly of the two programs he found on my Xenix images. This ZIP file contains those disassemblies. An extacted string is "iBR Standalone Utility ($State: XENIX_R3-5_U2)".

In Jan 2019 my good friend Mark Thomas, imaged my iBR diskette with his MS-DOS system which is capable of reading single-density diskettes. He produced an ANADISK image, with a single-desnity track 0 side 0 data (128 bytes 16 sectors) followed by the double-density 1024 byte 4 sector information I previously recovered. Here's the Anadisk image file IBRDMPNS which should be a pure "binary" image of the disk, both single and double density in sector order. Consequently, the first 128 X 16 bytes (or so) "should" be the single-density bootable code, loaded when the Intel system "boots" the iBR diskette.

I subsequently had discussion with Mark Ogden, who extracted Xenix files from a Xenix distribution diskette set, from imaged diskettes. Mark identified a file which is used by the Xenix system to write a single-density boot when formatting single/double density diskettes. Here's the "ogden boot file" binary provided by Mark.

Please follow this argument carefully. With use of a hex editor, I can align the binary data from the imaged diskette, with the binary data in Ogden's boot-file. What I see, is that data in bytes 0080H of the boot-file, correspond to bytes in 0000H of the imaged diskette; except for a number of bytes which consistently look like address bytes in a program. OK? That correspondence ends at 017F of the imaged disk (and 01FFH of the boot-file). The imaged-disk has a block (128d or 100H) of nulls with text strings "xenixbdisk" and "Xenix 286". The next block in the imaged disk at 200H, corresponsed (again except for likely address-bytes) with the block 200H in the boot-file. That correspondence however does not persist; the two apparent programs vary. The boot-file ends with data at 0858H, then nulls with a few bytes at the end at 08FFH. The imaged-diskette continues of course, but likewise ends its data at 0842H, has a null gap until 08D0H where it has the string "/boot", null, "$State..", and more data; until 0980H where the imaged-diskette show continuous "DEADDEADDEAD" text for some period. I've copied the binary from the imaged-disk, into a binary file iBR_single.bin

What do I conclude? I conjecture, the imaged-diskette represents the binary single-density data from 0000H to 0843H. Somehow that represents what I'd otherwise expect to be in 800H bytes of single density sectors. Then the rest of the imaged diskette represent the double-density content of the Xenix file system, containing the programs booted from the single-density content. And so, disassembly of the single-density "boot" binary iBR_single.bin, should yield information about the booting of that diskette. whew! In case these binary files get corrupted during downloads or transfers, here's a ZIP of the imaged diskette and the extracted binary and the Xenix boot-file.

Disk-image of the Xenix file system

On Saturday Jan 15 2023, I assisted Dave Gesswein, in his successful recovery of my Intel Multibus System 320 hard drive's contents. He operated his MFM drive emulator & reader, to read my Quantum MFM hard drive, sector by sector, as a single large image file. David gave me the image file on a USB stick, formated for Windows. The file is too big to offer on my Web site. I've passed along a copy to one of my Multibus colleagues. I'll report any results here.

The disk image file is 35MB. For file space reasons this is not on my Web site. Keep reading...

Thanks to David Gesswein for his MFM recovery and replacement services. It's an outstanding contribution to vintage computing restoration. here's his WEb page on his MFM emulator-reader.

Notes on the disk image

To review: Quantum 540 40MB Full-height MFM hard drive
8 heads 17 sectors 1024 bytes per sector.
so each track is 17 X 1024 = 17K decimal bytes Some documentation on Intel's Microsoft Xenix can be found on bitsaver's computer manuals for Intel's System 3XX. That archive includes a document "Overview_of_the_XENIX_Operating_System_Jan86.pdf" that shows some kind of Xenix file system structure. [In retrospect it may not be the same structure as my disk-image."

The apparent structure of the xenix image by my {herb's] inspection seems to be:

0000-084F some kind of boot code
08D0-097F says /boot $State...., probably continuation of boot
0980-27FF "DEAD" (actual Xenix data) so unused disk area
2800-up   sparse information [details found later]
3000-     vaguely orderly information
   3000-303F
   3040-307F
   3080-30AF
   30B0-30FF
    .... goes on at some length to A17FF
1A800  a series of text strings "Badblock ... lost+found ..xenix .. usr .. tmp
        and so on. These fill 16 decimal bytes, preceeded by two bytes
        which seem to be in some orderly pattern.
1A940  zeros
1B000 --- similar scheme to 1A800
1B400 --- maybe similar?
1C000 --- looks like 4-byte tables to me
1C800 --- more crowded binary information seems more likely 80286 code?

File recovery from the disk image

In early Sept 2023 it was suggested to me by a customer, that Dmitry Brant could recover the TAR image from my System 320 TAR tape backup. Brant recovered files for my customer from a similar tape cartridge.

When I contacted Dmitry, and referenced my image-file of the 320's hard drive Dmitry suggested he may be able to recover the file system from that hard-drive image. We corresponded about the image file scheme. I referenced that Intel Xenix documentation, and my binary review as above. Brant was able to recover the file system and move it into a 4.9MB ZIP file thanks to some proprietary tools he's developed. It's a two-partitioned file system, the system tree is preserved in the ZIP file.

Dmitry said "I'm hoping to open-source my code for dealing with this version of the Xenix filesystem as soon as I clean it up a bit more, and will also integrate it into my FileSystemAnalyzer tool."

About the Xenix file system as found: "In the second partition of the recovered files, there are actually #include files called /include/sys/filsys.h and /include/sys/ino.h that contain the actual structures used in this very version of the filesystem, including the inode structure and the superblock and cylinder-group structure. These structures are very different from the "xenix" filesystem support that's part of modern Linux. I'm not seeing these structures documented anywhere on the web." [I also noted inode.h - Herb]

"The two partitions start at absolute offsets 0x2400 and 0xD04400. The superblocks (which actually exist, they just weren't recognizable as anything I've seen before) appear at the second block relative to the beginning of the partition, so 0x2800 and 0xD04800 respectively. (The block size is 0x400 bytes.) A superblock is followed by a cylinder-group structure, then followed by inodes, and then the actual file data.

"You are correct [Herb] that the "boot" content at the very beginning (offset 0 to 0x2400) is not part of either partition, and it's not clear how the boot process actually works. I'm not able to get it to boot up in an emulator." - Dmitry Brant

I've copied the first (booting) sectors to 2800H, to this file. As my notes say, above 0980H is marked "DEAD" (in hexadecimal, not ASCII).

Other System 320 help & interest

In July 2009 I was contacted by Bill Beech. We traded some Intel manuals relevant to the System 310 and 320. I now have a manual for the SBC 547 serial comm card. We corresponded at length over the next two years: Here's a Web page that links to our discussions and his work on 8080, ISIS, some Multibus systems he has, his prior System 310 and 320 work, and various software tools he's come up with. As of 2011, he may have some disassembled ROM code for the 310 or 320.

Over the summer of 2009, I acquired another Archive tape drive (with a mushy capstan) and an Archive Scorpion SASI board to match mine. Manuals for these are available on Web archives of Archive brand tape drives.

Al Koskow of bitsavers.org says he has a System 310 he needs to power up, sometime. "The DSD 5215 controller is program compatible with the Intel 214/15, FWIW."

In 2016 I was in discussions about System 310/320 as noted below.

related System 320 and 310 information

Much of this is from Sept-Oct 2016 discussions with Bill Beech, Richard Main, Eric Smith, Mark Fisher, Al Kossow (bitsavers.org) and others about system 310 and system 320 Intel systems and Multibus hardware. Also they are active in recovering Intel 8 and 16-bit development tools and software. They are working hard and fast, I'm trying to keep up! There's a Web page among my "restore" Web pages, which references this work with ISIS and Multibus.

Intel controllers: "iSBC 220 was for SMD, and appears to be based on the iSBC 215 hardware design. One would hope that it would use the same IOPBs as the normal iSBC 215 firmware. The iSBC 221 controller was for ESDI and ST506/412, not SMD. the iSBC 221S was for SCSI, not SASI." - Bill Beech et al

iSBC 214 brochure says "the iSBC 214 combines the functionality of the iSBC 216 and the iSBC 213 data seperators, iSBX 217C tape drive interface..and emulates the iSBC 215G command set..." The '214 is what I have in my System 320; it uses an 80188 processor. The iSBC 215 is an 8089-based I/O card, in the system 310.

There's many versions of the iSBC 215 as follows, compiled by Eric Smith Oct 2016:

iSBC 215A supports drives with open-loop control

iSBC 215B supports drives with closed-loop control, incl. the non-ANSI Priam 3450, and can support 5.25" ST-506 drives with an iSBC 213 data separator board. The 215B hardware is identical to 215A, but has different firmware.

iSBC 215C supports ANSI standard 1226 drives, which are less common

iSBC 215D is apparently a cost-reduced 215B with the data separator for ST-506 drives

iSBC 215G is the "generic" controller, which is a redesign to merge the 215A/B and 215C features into a single controller than can handle open-loop, closed-loop, and ANSI drives. 215G also adds support for the iSBX 217 tape controller.

Caution: these iSBC 215's can be factory-modified to different versions or drive support. Don't just rely on board markings or layouts. - Herb

The OEM/Service manual for the Priam DISKOS 3450 and 7050, available on Bitsavers, describes both the Priam and SMD interfaces, and mentions but does not describe the ANSI interface. The SMD and ANSI interfaces were provided by an adapter from those interfaces to the Priam interface; the spare parts list includes the SMD interface adapter, P/N 200178, and the ANSI interface adapter, P/N 200198. Intel used the Priam interface with neither adapter.

The iMDX 750 Winchester subsystem for MDS/Series II/III/IV deveopment systems uses an iMDX 704 controller, which is an iSBC 215B or iSBC 215G with non-standard firmware, though the nature of the firmware differences is not yet known; from limited reverse-engineering, it appears to use basically the same memory structures (including IOPB) and commands as the normal iSBC 215B or 215G.

If I understand correctly, the Series IV uses the ISBC 215D for the internal ST-506 drive(s), but the firmware appears to have a different feature set from the 215B and 215G, though I don't know the details.

I just published an Intel 8089 disassembler in Python as open source on Github, specifically to work on reverse-engineering the firmware of the various iSBC 215 variants, and the iSBC 220, if one ever shows up...- Eric Smith. There's some firmware on Eric's site too. - Herb

I have a Priam 7050 with ANSI interface, by the way. - Herb

HErb noted: "Quantum 540 hard drive, or an maxtor XT-1085 hard drive, were used with the System 320.. The maxtor XT-1085 magic numbers are 1024 cyl, 8 heads, 17 sectors/track, precomp 65535, 512 bytes/sector (85MB). The Q540 hard drive numbers are: 512 cyl, 8 heads, 17 sec/track, precomp 256, 512 bytes, sector (40MB). So any MFM drive that has 8 heads or more and 512 cylinders or more would likely work."

Bill Beech replies: "[Quantum 540 and Maxtor XT-1085] were both used in the 310 and 320. We used a lot of XT-1140 140 MB drives in the 320's along with large SMD drives with 220 boards."

Bill told me, from Eric, "iSBC 220 was [the controller] for SMD, and appears to be based on the iSBC 215 hardware design. One would hope that it would use the same IOPBs as the normal iSBC 215 firmware. The iSBC 221 [controller] was for ESDI and ST506/412, not SMD. and the iSBC 221S [controller] was for SCSI, not SASI. "

Al Kossow noted, he has ROM images for many Intel Multibus cards at this link on bitsavers.

Web Resources

My Web page for Multibus stuff in general is at this Web link.
My Web page for other's Multibus stuff in general is at this Web link.
There's a Web page among my "restore" Web pages, about 2016-18 work with ISIS and Multibus. by the people previously noted.

this SLAC Web site for some Intel iRMX manuals; they mention one or two of the cards of this system. To search the SLAC system for old documents, , follow this link.

tenox.tc seems to be a private site of Antoni Sawicki. He has a variety of vintage computing interests.

I have not found many Web links about Xenix. In fact, Wikipedia points to THIS Web page. But this Web site by Dr. Nikolai Bezroukov has a curious but detailed document about Xenix history. You can check "Wikipedia" also. The short story is that Microsoft got "in bed" with Santa Cruz Operation (SCO) and licensed a System 7 Unix and they turned it into Xenix. Microsoft sold to manufacturers only - Intel, Tandy, etc. - and was serious about Xenix for some years, through their development of MS-DOS. By the late 1980's, the time of the 80286 and just before the 80386, Microsoft got OUT, sold their interests to SCO. Today, we know about SCO as a company who went after license fees to anyone who once owned Unix.

Since 2002, US Technologies is the current owner of Multibus intellectual property. Probably owns Intel's last stock of cards, plus their development stuff. They bought it from Radisys, who bought it and the iRMX rights from Intel back in Feb 1996. Inbus opened a Multibus-specific Web site in 2009. But Radisys still has some Multibus info on their Web site.

There is a Yahoo! discussion group on iRMX, at this Web link. It has posts about the Intel "System 320", and mentions it runs or ran iRMX Release IV (release 4); and there may be some current resources (2008) to help with that OS.

Some of the Web archives of manuals include iRMX or Multibus manuals include:
Here is the bitsavers.org iRMX archive. Check for Intel manuals as well.
Here is the Harte Technologies Intel archive.
an iRMX archive as part of Yahoo group irmsxstuff
Intel manuals accumulated by Bill Beech, 2012 and later
Richard Main's Intel 80XXX and Multibus development Web site is not available in 2018.
Other iRMX resources on the Web may be found by specific Web searches.

Copyright © 2023 Herb Johnson