Seattle Computer Gazelle

 

 

Seattle Computer Products was located on Industrial Drive in Seattle and was founded by Rod Brock to sell S-100 boards. At one point, they were having problems with a 16K memory board design. Rod knew a guy at a local computer store, Tim Paterson, and he asked Tim to help fix the design. Based on that success, ultimately, SCP hired Tim to do the board designs for the Company. In early 1979, Tim convinced Rod to let him do a design for a CPU board based on the recently-released 8086, and SCP released this board with a version of BASIC. By early 1980, Tim was working on a disk operating system for SCP, initially called Q-DOS (for "Quick and Dirty Operating System"); Q-DOS eventually turned into the DOS that Microsoft purchased for use on the IBM-PC (although SCP retained the right to use it on their own systems, like the Gazelle).

If you put these pieces together (CPU card, floppy controller, memory, and an I/O card, all made by SCP) you get a Gazelle. It was actually a well-configured base system - an 8MHz 8086 CPU with 128k of RAM (and up to 896k), two 8" floppy drives, serial console and I/O ports, and an 18-slot motherboard, all powered by switching power supplies (not common on the S-100 buss at the time). I believe the original price was $5,995.

Here's a picture of what an original Gazelle would have looked like. It was a rather sizable enclosure -- I don't have the dimensions, but it's probably 16" wide, maybe 18" deep and 22" high.

 

 

(picture from s100computers.com)

 

I'm not 100% sure when it was introduced, but mid-to-late 1980 seems logical. I've seen it mentioned that it was discontinued by 1983, and SCP as a company was gone by the mid-1980's.

 

October 20, 2017

This past summer, I offered to restore the Gazelle that is in the Vintage Computer Federation's collection. There were several goals for this project, including imaging the disks, creating high-quality scans of the manuals, restoring the system to working order, and for my purposes, creating a working replica system. For the replica, I had all of the parts but no disks to create/test/verify that it worked.

What's interesting about the VCF system is that it's not in the original enclosure as shown above. Rather, it's in a TEi (Texas Electronic Instruments) 22-slot case with a separate dual-drive floppy enclosure. The version in the VCF collection has a light cream color top (it's hard to tell from the below picture if it's the same color).

 

(picture from 100bit.it)

 

The system was rescued by Jim Scheef in 1989 from a gentleman in Nashua, NH. The system consisted of the TEi mainframe, dual-disk drives and an ADM-3A terminal. The original owner assembled this system in 1981 or 1982 -- he was a developer of Pascal software (not sure what he developed or for what target platform but that explains the many versions of Pascal that came with the system). He wanted the fastest system possible and with static RAM, a 16-bit buss and an 8MHz CPU clock, it was measurably faster than the IBM-PC was at the time (4.77MHz 8088 8-bit buss).

The configuration was a bit unique as well -- SCP 8086 card, SCP CPU Support card, 256K of SCP memory (four, 64K boards), a Tarbell double-density floppy controller (an option for the system), an SCP Multiport serial card, and finally, a Morrow HDC_DMA ST506 Winchester controller. Floppy drives were Qume QT-8 DSDD drives. Software included two versions of SCP 86-DOS, BASIC-86, MS-DOS 1.25, MS-DOS 2.0 and several versions of Pascal. Given this configuration, Jim suspects that the original owner may have bought the cards and chassis from vendors who probably advertised in BYTE magazine. I remember when I built my first PC in 1990, I trolled around the pages of The Computer Shopper looking for the lowest price on parts. So, I can easily see the original owner doing the same in order to build a very fast PC-comparable (but NOT fully-compatible) system. I would liken it to the Tandy 2000 vis the IBM/PC in this regard -- since the Gazelle had no PC-compatible BIOS and no character-oriented video card, it could run only console-based programs that called the MS-DOS Int21H interface. Further, the hardware wasn't at compatible port addresses.

Overall, the physical condition of the system is excellent but it had not been powered-on since the 1990's. So, the first part of the process involved confirming that the power supply regulated properly and that the primary filter capacitors were stable. After a day or two, the power supply was confirmed working and the rest of the restoration process could continue.

There were only a handful of things to fix and clean, which was good. The bulk of the remaining time was spent building a PC-based system capable of imaging the disks -- a mix of SSSD (128x26x77x1) and DSDD (8x1024x77x2) formats (with the DSDD being MS-DOS 2.0 compatible but with a 1024-byte sector size).

To provide maximum disk imaging flexibility with Dave Dunfield's IMD utility or Teledisk from Sydex Systems, I located an Adaptec AHA-1522A ISA SCSI controller to be used with an IBM PC/AT I set aside for imaging. The chip used on this Adaptec card -- a National DP8473 -- is capable of handling all required disk densities and sector sizes, including 128-byte single-density sectors.

On the floppy drive side of things, I did not take the disk drives from VCF, instead opting to use the drives I had at home (Qume QT-242 half-height 8" DSDD). After not having any success with these drives, I located two Shugart SA-851 drives, which worked quite well. You can still locate the Shugart drives for about $200 each on eBay. I'm sure other drives will work if jumpered properly.

Regarding the images, I found if difficult to create images of the DSDD disks that could be reproduced consistently using IMD. I'm not 100% sure why, but ultimately I used Teledisk to make a copy of the original SCP disk onto a new 8" blank, and then imaged that with Teledisk. Fortunately the only disk of importance was the MS-DOS 2.0 OEM Adaptation Kit Master, and I was able to recover the individual files from the disks. Bitsavers also includes a two-disk version of the OAK, but I haven't yet compared the included source files to see how different the SCP-specific files might be.

For convenience, all of the manuals, disk images, and ROM images are located on Bitsavers. The system binder included the following manuals:

 

Replica System - Intro

As mentioned above, part of this project was also to create a working replica of the system for my own use. My system consists of the SCP CPU86 card, three CompuPro RAM22 boards, one RAM21 board and one RAM16 (for a total of 832K of memory), a Tarbell DD card, an SCP-400 quad serial card (all ports populated), the CPU Support Card and, as noted below, the Morrow HDC_DMA MFM hard drive controller card.

 

File Movement

Another challenge is being able to efficiently move files in and out of the system without resorting to using three different systems with drives of various sizes to get files onto 8" disks.

I found a utility on the old MS-DOS Simtel archive called Bin2DBG (file) which takes a binary file and converts it to an MS-DOS DEBUG script. It's kind of like UUENCODE/UUDECODE and allows you to get programs into the MS-DOS environment. I have versions of UUENCODE/UUDECODE (file) but it only works on MS-DOS version 2.0 and greater.

The input file to Bin2DBG is the executable (.COM or .EXE) and the output file is a text file with the extension of DBG. Start MS-DOS, execute DEBUG and then upload the script using "send text file". You can use HyperTerm PE or other terminal emulator program to upload the file to MS-DOS. Its a bit clunky and probably has a file size limit of 64k, but can help with bootstrapping a system.

I was able to locate a version of XMODEM that I adapted for use with the Gazelle. It was based on MODEM3 by Ward Christensen, modified by others for CP/M-86 and then PC/DOS. I made changes to the source to accommodate the serial ports on the Multi-port Serial Card (MPSC) and the system speed. I was able to get XMODEM onto a disk using the method above.

I would note that the file transfers are sensitive to which program is used on the "remote" side. I have a second laptop connected to Port 1 of the MPSC and I've tried the following:

It's not clear to me why only certain programs work and others don't, but I suspect there may have been subtle changes to the protocol over time or variances in implementing the protocol which causes the random incompatibilities.

 

Enclosure

I didn't have a real mainframe enclosure available to me, so I cobbled something together with a CompuPro 12-slot motherboard and cage and three Mean-Well switching power supplies (S-150-7.5 for the 8V and two RS-75-15 for the +/- 16v). The cage has no fans, so I concocted a fan system from a DECServer-200 fan bracket and two 12v NMB 80mm fans. Works great. The black plastic on the top and on the sides at the bottom (not visible) are to control airflow through the cage. The cards, particularly the CPU and RAM, generate a fair amount of heat from the regulators.

 

       

 

In the right-hand picture, from front-to-back are the following cards: RAM22 #1, RAM22 #2, RAM21 #1, RAM21 #2, RAM16, SCP-200 CPU, SCP-400 serial card, Tarbell DD card, and finally the SCP-300 CPU Support card.

 

UPDATE 6/13/2018: I was able to locate a TEi enclosure similar to the one shown above. It's the 12-slot variant in a shorter enclosure. The color is a dove gray (like auto body primer) rather than a beige, but it's in perfect condition. I purchased it on eBay from a former telecom engineer in Jackson, NJ who used it for various projects and packed it away in a plastic bag and left it in a closet. There isn't a scrap of dust or dirt -- its virtually new. Only 11 slots are usable -- the 12th is between the front dress panel and the chassis. Here are two pictures:

 

       

 

Tarbell DD and a rant on DIP sockets

Regarding the Tarbell DD controller, the IC sockets used on my board are low-profile, single wipe TI sockets. They are prone to either sticking/binding and/or not making proper contact with the chips. An interim solution I have found is to remove the chips, lubricate/clean the socket with DeOxit D5 spray using a cotton or foam swab to get the solution into the contact area, and then re-seating the chips.

I have also found that the single-wipe sockets are prone to bending the chip pins, causing them to fold under the chip. Further, the Texas Instruments chips of the period occasionally develop a black oxide on the pins. I'm not sure, chemically, what this "oxide" is, but it can be removed with a pencil eraser.

If you are experiencing trouble with your board, I would clean the legs of the chips or replace the chips and use DeOxit on the sockets. Best practices is to replace the sockets with good quality dual-wipe sockets -- my board exhibited the most problems with the 20-pin sockets (which are the buss interface chips) so I replaced only those. The board is now stable and works well.

 

A Hard Drive!

The original system came with a Morrow HDC_DMA ST506/MFM hard drive interface. It uses an 8X300 CPU to manage the whole drive interface process so that the host CPU only has to issue a single command to an I/O port and pass a packet of data to the controller. Based on the schematics and talking with others, the HDC_DMA may be based on the Western Digital WD1002 reference design.

I was able to locate on eBay a board for myself and I already had a Quantum Q540 MFM drive (from a DEC system as it was marked "RD-54"). I also bought a DTC 5150XL 8-bit ISA MFM interface for my PC/AT so that I could low-level format the drive and check it out. I also located a copy of SuperStor (zip) so that I could perform drive diagnostics and related activities.

The native size/geometry of the Q540 (512/8/17/512, 43MB) is too large for MS-DOS 2.0 (16MB), but I was able to low-level format it to something that the Gazelle version of MS-DOS liked (480/4/17) Luckily, the drive formatted fine, with only minor hard errors (maybe 45k in total).

The Gazelle version of MS-DOS formats hard drives with 1,024-byte sector sizes rather than the normal 512-byte sector sizes. So, it's not possible to format the drive on a PC and use it on the Gazelle without re-writing the hard drive driver, which I may do -- the source was included. This configuration yields a usable, but non-bootable, hard drive of 16MB.

Now I'm searching for programs to put on the drive. I copied Pascal 2.05, Adventure, BASIC86 and PerfectWriter, but I'm on the hunt for more.

I'm also looking for a Lomas graphics/video board which supposedly is "PC-compatible".

 

A Printer!

The MS-DOS versions provided were configured with the printer device as the parallel output port on the CPU Support Board. The manual notes that the implementation is not really compatible with the Centronics standard (relating to the timing, length and phase of the *STROBE and *ACK signals) but that it should work. Bah! It didn't work with any Centronics-based printer that I had.

A quick note on devices and MS-DOS on the Gazelle. The only MS-DOS devices available are the standard 4: CON, AUX, PRN, and CLOCK. There are no COMx or LPT devices, and no apparent way to redirect ports (i.e., no "MODE" command). So, to support other hardware, you have to recompile the I/O subsystem and write it to a diskette.

The MS-DOS 2.0 disks that came with the system looked to be a "OEM Adaptation Kit" (OAK) distribution, although the label doesn't indicate as such. All sources and build tools were included, but interestingly, no object code for MS-DOS itself. There is a utility called "INSTAL.COM" which, together with the build scripts, writes a modified IO.SYS to the floppy drive and updates FORMAT.COM and HDISK.DRV (the fixed disk driver).

This result of this setup is that you can modify the I/O drivers for the hardware configuration but the modifications have to result in compiled code that's less than about 4k in size or it won't fit (this is due to several limitations, including maximum system file size of about 20k, files had to be continuous, and since MS-DOS object code was not provided, the whole system couldn't be re-written). I'm guessing that this limitation was handled differently for PC-compatible OEMs or fixed later since MS-DOS 2.0 object code was distributed -- look at the object code archive on the Computer History Museum web site. I have the OAK for MS-DOS 3.1 and the object code for MSDOS.SYS was provided.

One of the source files (IODEF.ASM) has a few compilation switches for defining which hardware ports map to the AUX and PRN logical devices. Once those are set, all you need to do is run the MAKIOSYS batch file and when completed, the PUTIO batch file, to write the modified files to a diskette. Definitely do this on an extra disk and not the distribution master.

The second thing to tackle is the lack of serial dot-matrix printers. The quick-and-dirty way to handle this for demonstration purposes is to connect the serial port to another computer or USB-to-serial adapter and use the logging function of HyperTerminal to capture the output. Alternatively, you can use a serial-to-parallel converter (like the Practical Peripherals Microbuffer), which is what I used to connect it to a Tandy DMP-120 that I had handy. Works like a charm!

 

Files

The MS-DOS disks come with only the typical DOS utilities, but do include development tools (MASM, LINK, EXE2BIN), but no BASIC. As I collect and locate various programs for the Gazelle, I'll share them here, with the DOS version noted.

 

UPDATE 4/28/2019: Last week I picked-up another Gazelle off of eBay. Its former (and original) owner was a researcher at Johns Hopkins (Baltimore, MD) and used it in his research into protein structures.

This unit was more similar to the one in the VCFE collection -- all SCP cards, including the CPU, CPU Support, Multiport Serial and two 64K SRAM boards, again in a 22-slot TEi chassis (SN #008925). The seller claims that he sold the Tarbell controller and disk drives separately.

This unit came with all of the manuals, plus one I didn't have previously (the Monitor 1.5A manual). It also came with a Q-DOS 1.0 diskette dated in early 1981. Overall it is in very good condition, with the same socket oxidation on the CPU Support and one bad tantalum capacitor. After some cleaning and minor repairs, the system works and the diskette booted just fine.

I guess I now need to decide if I swap the enclosures and put mine in the larger box (allowing for some expansion room) or keep the 12-slot case. Something to ponder.

 

 

 

 

Copyright (c) 1998-2019 by Richard A. Cini, Jr. (rcini at msn dot com) All Rights Reserved. All copyrights of any third parties referred to herein are hereby acknowledged. There is no warranty, either express or implied, relating to any of the content contained herein. The site maintainer shall in no event be liable to anyone for damages, including any loss of profits, lost savings, or other incidental or consequential damages arising out of the use or misuse of the information contained on this Web site. Batteries not included. You may use the information contained herein for NON-COMMERCIAL purposes only and AT YOUR OWN RISK.

Last updated 2019-04-28 12:06 -0400