Strange Medieval Devices

In the late 1970s and the 1980s, the best choice for high-performance, high-capacity storage was so-called SMD disks. The SMD interface was only normalized as ANSI X3.91M-1982 in, well, 1982, after five years of work, and was later revised in 1987; this revision can be found on Bitsavers. Although other storage technologies appeared during the 1980s, such as ESDI (standardized in 1984) or SCSI (standardized in 1986), the highest capacity disks were all using the SMD interface. SMD disks were first using 11" platters, later 8"; and with a nominal speed of 3600 rpm, thus 60 rotations per second (although Fujitsu later deviated from the norm and had a few drives spinning even faster, at 3961rpm), it took a noticeable amount of power to spin these disks up (and a smaller one to keep them spinning, which one would notice when receiving the bill from the electricity company). These disks would also, of course, weigh as much as a dead donkey, if not two. While 8" models could be carried carefully by one person, moving 11" disks around usually required the use of some form of carriage. SCSI standard documents (click for a larger picture). It was thus no surprise that Sun Microsystems would ship its high-end servers and workstations with SMD disks, using Xylogics controllers. Xylogics 451 Multibus controller board, in the middle, plugged into a Multibus-to-VME converter at the bottom (click for a larger picture). Similarly to ESDI but unlike SCSI and more modern storage interfaces, the SMD interface has separate command and data cables. Depending on the controller, the command cable is either routed through all disks, daisy-chained, or there is one dedicated command cable per disk, directly connected to the controller. The data cables are independent and always directly connect the controller to a disk. Note the 451 can drive four disks, but the Sun flavour only routes the command cable (in the center) and two of the four data cables, thus only allowing two disks to be used. Sun's connector choice also splits the command into two smaller cables. By the time these systems made their way to hobbyist's basements, high-capacity SCSI drives had appeared; I remember using a 2GB Micropolis 1924 5"1/4 SCSI disk on my Sun-3/260, in the early 2000s; to the best of my knowledge, the largest SMD disk drive capacity ever was about 1.25GB, less than two thirds of that SCSI disk capacity. When I started working on OpenBSD/sun3, in the year 2000, I did not have any SMD drives anyway, and could not test the Xylogics drivers. This changed in the summer of 2001. I had stumbled upon a decommissioned Sun-4/260 cabinet in a corner of a room somewhere the previous summer, next to a SMD disk cabinet of matching form factor. After recognizing the machine for what it was, I inquired of its state, and it took me one full year to convince the right persons to let me park my car close to that room and move both enclosures to its trunk. What's in a Sun-4/260, you may ask. The 4/200 series were the first SPARC systems sold by Sun; depending on the actual size of the VME enclosure, they were either the 4/260, in a large 12-slot deskside cabinet on wheels, or the rackable 4/280 which would fill half a 19" rack, allowing for 16 VME slots in this configuration. The motherboard was however the same, a large (9U) square board with a 16.67MHz SPARC processor and its Floating-Point Unit. It sported two serial ports, a combined keyboard and mouse port for a Sun Type 3 keyboard, a monochrome high-resolution (1600x1200) frame buffer, and an Ethernet interface. Sun-4/200 board (click for a larger picture). Note the ZIF sockets for the CPU chips on the left. But no on-board memory. Memory was installed as VME boards which also communicated with the CPU board on Sun's private "P2" bus to speed up memory access and not have to share bus bandwidth with the rest of the VME bus. Up to four memory boards could be installed, and since they came in 8, 16 or 32MB flavours, this allowed for up to 128MB of physical memory. Storage controllers would also be added as VME boards. Most systems had at least a SCSI controller, in slot 7, to handle the internal drive bay - either the very limited homemade "Sun-2" sc controller, unable to correctly handle parity signals and requiring it to be disabled on all connected devices, or a slightly better, NCR5380-based "Sun-3" si controller, with no such limitation. Usually, another controller was added in slot 8: either another SCSI controller with an external connector, to be able to, well, connect external SCSI devices, or an SMD controller (sometimes even two). Higher-end Xylogics 7053 VME (9U) controller board (click for a larger picture). This controller can drive four disks, but uses different connectors on the backplate, than the Xylogics 451, hence require different cables (which I unfortunately don't have). Model 7053 also exists as a smaller (6U) VME board, for use with other VME systems, such as older Silicon Graphics systems or Motorola's. In this smaller size, it is known as model 753, and uses shielded high-density connectors (for which I don't have the appropriate cables either) instead of Sub-D. All the subtle differences between the various VME slots in the chassis led to Sun writing a specific manual on the preferred location to put every board and how to configure the VME backplane jumpers for proper interrupt delivery, called cardcage slot assigment and backplane configuration procedures (link to Bitsavers). This, in its heyday, grew over 100 pages of tables and footnotes. The abovementioned manual (click for a larger picture). When I setup that machine at home, the selftests reported one of the memory boards as defective. This might have been one of the reasons this machine had been removed from service (that, and maybe also the electricity bill and limited horsepower). But, as it had been fitted with four 16MB memory boards, I could remove it and still work with 48MB. Of the two SMD disks in the storage cabinet, both with a raw (non-formatted) capacity of about 368MB but a formatted capacity of only 280MB, only one appeared to be working. After getting rid of the faulty memory board, and moving another two of them to my Sun-3/260 which was more important to me at that time, I could finally setup the machine. Date: Sun, 15 Jul 2001 05:05:25 +0000 From: Miod Vallat To: dmesg@openbsd.org Subject: sun 4/260 Wow, I added SMD and scsi disks to the diskless 4/260. Still slow as hell, but I don't care, I have a reputation to preserve. Kernel is SUN4 from 07/13/2001 with my dmesg fix that mickey commited later. Miod OpenBSD 2.9-current (SUN4) #2: Sun Jul 15 04:32:56 GMT 2001 root@tekumel:/src/current/src/sys/arch/sparc/compile/SUN4 real mem = 16752640 avail mem = 13221888 using 102 buffers containing 835584 bytes of memory bootpath: /vmes0/xyc0/xy@0,0 mainbus0 (root): SUN-4/200 series cpu0 at mainbus0: MB86900/1A or L64801 @ 16.670 MHz, MB86910 or WTL1164/5 FPU cpu0: 128K byte write-back, 16 bytes/line, sw flush cache enabled obio0 at mainbus0 oclock0 at obio0 addr 0xf3000000 delay constant 6 eeprom0 at obio0 addr 0xf2000000 memreg0 at obio0 addr 0xf4000000 zs0 at obio0 addr 0xf1000000 pri 12, softpri 6 zs0a: console i/o zs1 at obio0 addr 0xf0000000 pri 12, softpri 6 bwtwo0 at obio0 addr 0xfd000000: bwtwo, 1152 x 900 bwtwo0: attached to /dev/fb ie0 at obio0 addr 0xf6000000 pri 6 address 08:00:20:00:c8:78, type onboard vmel0 at mainbus0 vmes0 at mainbus0 xyc0 at vmes0 addr 0xffffee40 vec 0x48 pri 3: Xylogics 450/451 xy0 at xyc0 drive 0: ready (drive type 1) xy0: <CDC EMD 9720 cyl 1147 alt 2 hd 10 sec 48>, pcyl 1149 xy0: 268MB, 1147 cyl, 10 head, 48 sec, 512 bytes/sec xy1 at xyc0 drive 1: off-line si0 at vmes0 addr 0xff200000 vec 0x40 pri 3 si0: options=1<DMA> scsibus0 at si0: 8 targets sd0 at scsibus0 targ 0 lun 0: <EMULEX, MD21/S2 ESDI, A00> SCSI0 0/direct fixed sd0: 312MB, 1224 cyl, 15 head, 34 sec, 512 bytes/sec, 640500 sec total sd1 at scsibus0 targ 0 lun 1: <EMULEX, MD21/S2 ESDI, A00> SCSI0 0/direct fixed sd1: drive offline st0 at scsibus0 targ 4 lun 0: <, , > SCSI1 1/sequential removable st0: rogue, drive empty led0 at mainbus0 root on xy0a rootdev=0x300 rrootdev=0x900 rawdev=0x902 ie0: TDR detected an open 9472 clocks away Given the limited horsepower of that machine, and the noise of the huge chassis fans when powered on, I did not use it very often. Only when I needed to test something on that particular motherboard would I power it up again, upgrade to the latest OpenBSD version, and test a new kernel which had been compiled on another machine. Tests which needed a ``sun4'' class machine would usually be performed on my Sun-4/330 running at 25MHz, which would also draw less power, and for which I had bought a memory expansion board to reach a comfortable 80MB (32MB onboard in 8x4MB SIMMs, and a VME expansion board with 48x1MB SIMMs). The abovementioned memory board with its 48 SIMMs (click for a larger picture). Unfortunately, it doesn't accept 4MB SIMMs. Since the Sun-4/200 and Sun-4/100 motherboards are special, compared to the other SPARC systems, in that they use an Intersil EEPROM chip as non-volatile memory (as found on Sun-3 systems) unlike all other SPARC systems which use the infamous Mostek battery-backed SRAM chip, I could also test such kernel changes on a once again less power hungry Sun-4/110, to confirm there were no regressions with the Intersil driver. So, apart from some time working on the VME cg2 frame buffer as part of the sparc console overhaul work, this machine would only get a chance to run for a few hours about every two years. At some point, its onboard Ethernet interface broke, no longer able to receive or transmit anything; there was no obvious damage on the motherboard from visual inspection, and the Ethernet fuse was not blown, so this was likely one of the soldered IC misbehaving, either the Intel 82586 Ethernet controller, or (more likely) some related signal converter, such as