Forty Years of Personal Computing - 5 1/4" WD2797 Disk Controller

WD2797 controller card for 5 1/4" drives

To work on OS-9, I borrowed some 5 1/4" drives, and used the SWTPc DC-2 controller. This allowed me to boot up OS-9. Single-sided, single-density, 40-track diskettes hold about 100 KB -- they were quite limited on space.

Running OS-9 on single-sided, single-density 8" disks, the situation was a little better, as each drive has about 300 KB of storage. But my two-drive system was limited. Plus, I was something of an island. None of my friends using OS-9 had 8" disks, so I couldn't exchange data with them. It was time to consider 5 1/4" drives.

5 1/4" disk drives went through considerable evolution since their 1976 introduction. The early drives were single-sided, single-density with only 35 tracks. By 1987, double-sided, double-density drives sporting 80 tracks were common. These disks could hold about 640 KB, more than twice what my single-sided, single-density 8" drives held. (And more than single-sided, double-density 8" drives could as well)

Disk Controller

In August 1987, I designed a 5 1/4" floppy disk controller. The 5 1/4" controller is very similar to the 8" design, with appropriate changes for the disk interface. 

A MOTOR ON* signal is generated any time the WD2797 is accessed, with a one-shot multivibrator holding that signal for 10 seconds. Another one-shot asserts the READY signal on the WD2797 after a second of MOTOR ON*. 5 1/4" disks always have the heads loaded, so HLD is tied to HLT.

Back side of 5 1/4" controller

Double-density is jumper-selectable to either follow drive select bit 7, or the SSO output. Side selection is controlled by drive select bit 6. Write pre-compensation isn't used, as it was unnecessary for 5 1/4" disks. 

I built the controller the same piece of 0.1" perfboard that originally held the FD1771 disk controller for 8" disks. The board is a little bit smaller than the WD2797 controller for 8" disks, so it appears more densely packed. Wire-wrap techniques are used for the wiring, and a handful of connectors and discrete parts are soldered.

Drives

For initial troubleshooting, I borrowed the two drives and power supply from a Sage II computer from work, which I had to return. I needed my own drives.

How many drives did I need?  I decided three drives would be sufficient -- one boot disk, and two working disks. This would allow me to copy disk to disk, while still having the boot disk with commands in place. (and no crazy disk-swapping for copies like the original Macintosh that had one disk drive!)

I bought two Tandon TM100-4 drives at a local hamfest. These were common surplus from Lanier word processing units at that time. When I went to buy a third drive, I could no longer find any. I ended up with a Mitsubishi M4853 drive. The specs of the drives are virtually identical, except the Mitsubishi is a half-height drive.  

Drive Cabinet

5 1/4" Drive Cabinet

Finding a cabinet to house three drives was a problem. New metal cabinets are very expensive, particularly in larger sizes, and I couldn't find anything suitable on the surplus market. 

September 1987, I built a wooden cabinet to proper dimensions for three TM100-4 drives. I used 1/4" plywood, reinforced at the corners with 1x1/2 strips. The bottom, back, sides and one quarter front panel are all glued together as one unit. The top screws on to the four corner posts. The finished unit is quite sturdy. 

As originally built, the cabinet was plain unfinished plywood. I recently sanded and finished it with a couple of coats of polyurethane.

Inside the box, plenty of room.

Power comes from a 12 volt, 5 amp supply. 5 volts is provided from a single LM7805 regulator mounted to that supply. In retrospect, the LM7805 might be a bit over-taxed. I suspect the drives draw less power than their maximum specifications. Heat is removed from the cabinet by a small (but noisy) muffin fan on the back panel.

A power switch and neon pilot light round out the front panel, giving a clear indication the unit is on.

The controller and drives work great, easily formatting  double-side, double-density disks using 80 tracks. 

Drives & Software

In April of 1989, I revised all the disk drivers to handle double-density, double-sided drives. The BBUG monitor "D" command code was updated to look for double-density sectors, and the boot loader for Flex09 updated to read double-density, double-sided disks.

For OS-9, I modified an existing driver (FD2) for the Processor Technology PT69 to work with my disk controller and created a new boot disk with several drive descriptors. The drivers and descriptors allowed for 40-track disks (which required double-stepping of tracks, and adjusting the track register), and SWTPc format, where track 0 is formatted single-density -- as well as the standard, double-density, double-sided, 80-track format.

I updated the Boot module to handle double-density, double-sided disks and burned a new OS-9 ROM. 

The result is a smart, efficient unit roughly the same size as the SWTPc 6800 Computer System cabinet. The fan is a little noisy, but was typical for the day. 

Future

The Tandon and Mitsubishi drives only require 250 ms to get up to speed after MOTOR ON*. I can shorten the timing on the one-shot driving the READY signal.

If I can manage to find a second Mitsubishi M4853 drive, four drives would fit into the cabinet. I'd need to add a second LM7805 regulator for the 5-volt supply, and split the 5-volt output across two drives for each.

One limitation of the WD2797 is the track to track and head settling time. These drives can move track to track in 3 ms and need 15 ms for the head to settle. The WD2797, using a 1 MHz clock for 5 1/4" drives, can only do 6 ms and 30 ms, respectively.

Western Digital did manufacture another device, the WD1772-00. This was a 28-pin floppy disk controller for 5 1/4" drives that is software compatible with the WD179x and WD279x devices. The WD1772-00 allows faster track to track and head settling times -- up to 2 ms and 15 ms. 

The biggest problem is finding one, as the WD1772-00 wasn't used in a lot of designs, and Western Digital stopped manufacturing them over a decade ago. Might be interesting for a V3 floppy disk controller card.

Halfway through the DXCC Challenge

Twenty years ago, when I first started uploading my logs to Logbook of the World, I began to pursue the DXCC Challenge award. I created lists of confirmations that I had, and began to try to fill in the band / countries I was missing. This has continued for years. 

In April of 2016, I gathered sufficient confirmations to earn the DXCC Challenge award. Since then, I've continued to pursue new band / countries practically every time I am on the air.

This month, I passed another milestone. Currently, there are 340 entities on the DXCC list. And the DXCC Challenge counts on ten bands, from 160m through 6m. That makes 3400 total items for DXCC Challenge. 

I recently collected confirmations over 1700 items on the DXCC Challenge. That's the half-way point. It's only going to get harder after this.

Forty Years of Personal Computing - OS-9 Level I

I learned about OS-9 in early 1983, when it was new. What I heard mainly concerned BASIC09 and at that time BASIC didn't interest me. That was unfortunate. OS-9 is a miniature Unix clone, optimized for the 6809.

Baud rate generator and
counter/timer board

Requirements

By fall of 1986, I tired of the limitations of Flex09, and started looking at OS-9. Bringing up an OS-9 system didn't have the same challenges as Flex09,  since OS-9 can format 8" diskettes. OS-9 does have additional hardware requirements. It needs a periodic source of interrupts. 

Interrupt Logic

The OS-9 CLOCK module has logic for several interrupt sources, using chips available at the time. The MC6840 programmable counter/timer chip, with three 16-bit programmable counter/timers, was one option. The MC6840 fit nicely on the bit rate generator board. The driver allowed two circuit variations.

The circuit I chose exercises all three counter/timers.  Timer 1 counts 50,000 cycles, then trips Timer 2 and 3. Timer 2 counts twice and signals an interrupt. Timer 3 counts down from 90. In this way, Timer 2 provides regular interrupts every 50 ms on a 2 MHz system. Timer 3 counts interrupts and adjusts the system clock whether or not the Timer 2 interrupt is serviced every 50 ms.

ROMs

The OS-9 kernel has two modules burned into ROM: OS9p1 and OS9p2. I obtained two 2KB ROMs and programmed them with the images. OS9p1 resides at F800. OS9p1 initializes the kernel, then searches for installed modules, which are position-independent. The second ROM contains OS9p2, Init and Boot. Once OS9p1 finds the OS9p2 module, it initializes it. OS9p2 looks for certain key modules, like IOMan. If they cannot be found, it uses the Boot module to load the rest of OS-9 from a floppy disk.

Once initialized, OS9p2 uses the information in the Init module to start executing. During a soft reset, OS-9 does not always load from disk. If the modules are not altered, OS9p2 can find them and bypass the boot process. 

The modular structure of OS-9 allows great flexibility. Modules can be in ROM or loaded from storage devices. The Init module provides the configuration to execute the first module.

Bootstrapping

With a little help from a working OS-9 system, bootstrapping was straightforward. The ROMs I started with were pretty generic SWTPc system ROMs. The MC6840 occupied the bit rate generator board. I borrowed a 5 1/2" disk drive and plugged the DC-2 controller into I/O slot 1, with the 8" controller in I/O slot 2. Armed with a single-sided, single-density 5 1/4" boot disk, I successfully booted OS-9. That was the hard part.

From there, I created a new 5 1/4" boot disk with drivers and configuration for my 8" drives. Booting from this new disk, I formatted 8" disks and moved the OS-9 files to them. I then created an 8" OS-9 boot disk with a new I/O configuration and drivers for both 8" and  5 1/4" drives. At that point, I swapped the floppy disk controller slots, with the 8" controller in I/O slot 1, and the DC-2 in I/O slot 2. (The Boot module is configured to find a WDC-compatible floppy disk controller at the address for slot 1)

At that point, I could boot OS-9 from my 8" drives, and was able to copy files from the 5 1/4" disks. Compared with bringing up Flex09, this was easy.

I tailored my configuration to suit my hardware, and updated the ROMs with customized modules.

Swapping BBUG/Flex09 and OS-9

While I was using OS-9, I would swap back to BBUG and Flex09 on occasion. This was a pain. I would swap out the two 2 KB ROMs and use a different boot disk. 

In late October of 1986, I modified the MC6809E V1 board to use a single 4 KB 2732 ROM. This put all of the OS-9 kernel on one chip, and allowed room to expand BBUG. With this modification, only one chip was swapped.

Extended Memory

Working with OS-9 uncovered an issue with extended memory addressing. December 1986, I installed a 74LS21 4-input NAND gate on the SWTPc motherboard to decode the top address bits S0-S3. This placed the I/O addresses at FE000. With the MC6809E V1 board, this worked great with BBUG and Flex09. BBUG initialized the E-block of the DAT with a value F1 -- which the board would interpret as physical address FE000. 

However, I found I could not boot into OS-9 any more. Turns out, OS-9 initializes the E-block of the DAT using a value 01, which the board interpreted as physical address 0E000. With the extended addressing decoder on the motherboard, the OS-9 Boot module could not communicate to the I/O devices. This forced me to disable the 74LS21 decoder.

User Experience

OS-9 Level I uses a single 64 KB memory space for the operating system, programs and data. That's not a lot of memory. Many OS-9 programs are small, being written in assembly language. Larger programs, like a compiler, load in as multiple passes, to conserve memory use.

Using OS-9 is cool. It is a real-time, multi-tasking operating system, first available in 1982. Windows wouldn't have comparable functionality until 1989 (Windows NT), and the Mac in 1999 (MacOS X). Like Unix, you can spawn off programs to run concurrently in the background.

Using a second serial port, I ran two users simultaneously, one from the main terminal, and one from the second serial port. I used a Wyse-85 terminal on the main port, and the old CT-64 on the second port. Amazing on an 8-bit machine with 56 KB of memory! 

At some point, I hung a modem on the second port. I could leave the machine running at home and dial into it from work. 

Forty Years of Personal Computing - Wyse-85 Terminal

By the summer of 1985, my original CT-64 terminal felt limited. Sixteen rows of 64 characters didn't seem like enough. Especially when at work I regularly used screens with at least 25 rows of 80 characters. In 1977, terminals with such capabilities were around $1000 -- way beyond my modest budget. By 1985, much more capable terminals were available for about half that price. It was time to upgrade.

August of 1985, I purchased a Wyse-85 terminal for about $700 -- a good price for the time. The terminal offed a DEC VT-220, VT-100 and VT-52 emulator, so it was plenty capable. It sported 24 or 25 rows of 80 or 132 columns on the screen. I purchased the green phosphor screen.

The most important thing, however, about the Wyse-85 compared to the CT-64 was speed. The CT-64 was limited to a paltry 1200 bps. The Wyse-85 had a top speed of 38400 bps. Thirty-two times faster. The CT-64 would take more than eight seconds to write every character on the 16 x 64 screen. The Wyse-85 could write an entire 25 x 132 screen in less than a second. 

The Wyse-85 was such a joy to use compared to the CT-64, I couldn't believe I hadn't done this sooner. 

I did have trouble with this terminal when I tried to use it in the shack back in the late 1980s. The keyboard scan generated a fair amount of RFI. Putting several ferrite toroids on the keyboard cable helped a little, but did not eliminate the problem. 

I still have this terminal. It's been stored in the original box since November of 1994. I hope it still works.

Demise of one 80/40/20m Dipole

I was QRV in Gordon county briefly - only a couple of weeks. I managed to erect the 80/40/20m dipole I had up in Warren county, which previously flew over Fulton county. It was a cobbled-together mess, made from wire left over from the original 80/40m dipole, newer traps, and old insulators and rope.

Using the Mark III Antenna Launcher, I did a good job casting over a tree in the front yard. Weight sailed up over the tree and came right down beside the trunk. The 1/16" guide line went back out to the antenna launcher, and then the 1/4" nylon halyard came back over. Perfect.

At the far end, I had more trouble. Not wanting to crawl over a fence, I cast sideways to branches overhanging the edge of the yard. The first toss wasn't great, so I pulled it down. Second toss got stuck in the tree, and I lost the weight. I was down to my last antenna weight. I confidently tied it on, pulled back, let it fly, only to watch it sail off the end of the fishing line and into oblivion. Nuts. 

With no weights handy, I couldn't use the antenna launcher. I opted to use a small hammer and toss the halyard over a branch about 20 feet up in the tree. At least I didn't lose the hammer. 

The resulting installation sloped the dipole from about 25 feet on the south end, to about 60 feet on the north end. No matter - it would work. At least, until I could make more weights and get it higher in the air. 

I used it to make about 100 contacts for the NAQP Phone in August, plus a little casual operating. Then I found most of it lying on the ground after a few windy days. Inspecting the remains showed that the wire between the 20 and 40 meter traps had broken. That particular segment was pretty old, being part of the original 80/40m dipole, and might have used wire from the ancient untuned doublet before it.

This meant that one of the 40m traps was still up in the tree. Looking carefully, I could see it about 50 feet up. Untying the rope, I could not get it to drop, and instead pulled the halyard to recover the rope. The wire ended up coming off the insulator, leaving wire and one trap stuck in the tree. Drat.

The rest of the antenna lay across the yard and lower driveway. I don't use that driveway, so I didn't think about it. However, some folks came to visit the parsonage and apparently didn't see the traps laying there. Two of the trap forms got crushed in the process. Doggone it.

I guess I have to rebuild this antenna from scratch, using new wire and traps. That will take some doing, as most of the parts are back in Gwinnett county. Plus, I have to make more antenna weights to put it back up. 

In the meantime, I'm off the air in Gordon county.

Forty Years of Personal Computing - V2 Floppy Disk Controller

WD2797 controller card for 8" Pertec drives in
the Icom Peripherals FD360

The FD1771 disk controller works well with the Pertec 8" drives. The single-density drives each hold around 300 KB of data. 

Single-density encoding is FM, which has regular clock pulses, with a data pulse placed between. A data pulse indicates a "1", a missing pulse is a "0".

Double-density uses Modified FM (MFM) encoding. It eliminates the clock pulses entirely, leaving only the data pulses. To keep synchronization during runs of zeros, extra pulses are inserted between each pair of zeros. Encoded in this way, the clock can be recovered from the data pulses alone.

Western Digital followed the FD1771 with the WD179x chips, which support double-density with a two device solution. The later WD279x chips offer the same features on a single device. Double-density allows 500 KB on the same disks, with the data transfer rate also doubled.

WD2797 8" Controller

Back side of the 8" controller

September 1986, I built a new controller using the WD2797 to support the Pertec FD400 drives. While the drives were designed for single-density, I hoped they would work using double-density.

In keeping with my other home brew cards, it's built on a piece of 0.1" perfboard with the Molex connectors epoxied to the bottom edge. Wire wrap sockets are used.

Naturally, I broke out the WWARP program I used years before to build the MC6809E V1 card. 

The WD2797 design borrows from the FD1771 design. I kept the latching data bus buffer, but eliminated the redundant data bus buffers in front of them. The WD2797 performs the clock/data separation, which eliminates several gates. Fourteen total chips on this board, whereas the FD1771 board used more like eighteen. 

Double-density is enabled through an option jumper. The SWTPc DC-4 controller used the SSO output to drive the DDEN* pin through an inverter. (SWTPc offered double-density before double-sided disks) One side effect of using SSO is the sector address markers will have side 0 for single-density sectors and side 1 for double density sectors.

Other designs used bit 7 of the drive select latch, controlled through software. SSO isn't connected to anything, as the Pertec drives only have one side.

A jumper at the top of the card chooses the DDEN* signal source: the SSO pin, or bit 7 of the drive select latch. Both paths go through an inverter, so double-density is selected with a 1 on either the SSO pin or bit 7. 

Bit 3 of the drive select latch controls ENP - the pin for write pre-compensation. Generally, ENP would connect to the TG43 output of the floppy drive interface. Using a separate bit allows write pre-compensation to be enabled or disabled at any time, through software. I didn't know if write pre-compensation would be required or desired. It seemed like a good plan to allow write pre-compensation on any track, since the Pertec drives weren't designed for double-density.

Reading the drive select latch address returns the state of the INTRQ* and DRQ* pins, on bits 7 and 6, respectively. Using these separate bits allows more efficient loops than reading and interpreting the status bits of the WD2797. The SWTPc DC-4 introduced this feature, and is common to controllers of that era.

The WD2797 calibration starts by grounding the TEST* pin and checking three signals with a scope.  A set of four pins at the base of the WD2797 chip bring these signals out making calibration easier. 

To support the new controller, I re-wrote the Flex09 disk drivers to allow double-density operation. 

Do the Pertec drives work at double-density? I don't know. Supporting double-density meant re-writing NEWDISK to initialize in double-density format. Before I figured that out, my interest shifted from Flex09 to OS-9, and I did not complete that project. But the card works great with single-density.

Forty Years of Personal Computing - RTTY Receiving Program

September 1985, I purchased a Kenwood TS-430S and became more active in amateur radio. In the apartment where I was living, I snuck wires out of a second floor window and began to make contacts. 

In October, I got the notion to try some Radio Teletype (RTTY). I built a demodulator using a circuit I've forgotten. Perhaps it used a couple of NE567 chips. Having a demodulator, I needed to translate the five-level Baudot characters into ASCII that I could display on the terminal.

(I purchased a Wyse 85 VT-220 emulator terminal in August of 1985, so I was no longer constrained by the 64x16 screen and 1200 bps limitations of the CT-64)

RTTY Decoder

I wrote a program for Flex09 to decode 45 Baud RTTY by bit-banging a PIA pin. I couldn't use the MC6850 ACIA, because it does not support 5 bit characters.

A delay loop established character timing: 

LOOP    LEAX -1,X
              BNE LOOP

Each pass through the loop consumes 8 clock cycles. With the right value loaded in X, fairly precise timings could be accomplished. A value close to 250 would be 1 ms on a 2 MHz machine. By calling this loop repeatedly, timings of 11 and 22 ms are measured. 

I connected the demodulator output to PIA Port B, pin 0. The program looks at this pin, waiting for a zero. Finding one, it calls the delay loop for 1 ms and checks again. If the pin is still zero, it waits 10 ms and checks Port B pin 0. A continued zero at this point indicates a start bit. The 11 ms total delay places us right in the middle of the start bit.

The next sequence waits 22 ms and then samples of value of Port B, pin 0. It does this five times. These samples are shifted into a byte value, which used to look up an ASCII character in one of two tables -- one for letters, and one for figures -- according to the shift mode. This character is then sent to the terminal, and we go back to waiting for a start bit.

The resulting program is about 300 bytes long. Despite the simplicity,  I had little success decoding RTTY signals. 

In hindsight, there are several reasons for this. 

• Decoding signals off the air that might have been noisy.
• Demodulator circuit was completely untested and might not have worked.
• No experience with RTTY, so signals might not have been properly tuned.
• Precise value of the 1 ms time delay not known. I used values of 230 and 240, allowing cycles for other program logic. 

At some point, I distinctly copied "RY RY RY RY RY RY RY" from someone, but not much else. Later, I figured out this meant my program, at least, was working. 

Hardware Solution

In November 1986, I decided to use serial chip that could do five-level Baudot. The MC6850 only allows 7 and 8 bit characters, so I needed a different chip. The NS8250 could do 5, 6, 7 and 8 bit characters, and sports a programmable bit rate generator for all the common RTTY rates. Hence, I added an NS8250 UART to the baud-rate generator board. 

Funny, though -- I never wrote software to use the NS8250. In February 1989, I removed the NS8250 and its associated circuitry. 

I didn't become active in RTTY on the air until 2005, using Cocoamodem.