In 1984, I was working at Hayes Microcomputer Products. They were the premiere modem manufacturer for small computers, back in the days when modems over telephone lines were a primary means of computer to computer and user to computer communications.
In my job, I created communications software to talk to the modems. The software dialed the modem, established connection, provided terminal emulation (my specialty), allowed for the capture of the data stream to files, printing, file transfer with the remote computer (using protocols like XMODEM and YMODEM), and other features.
These were the early days of personal computing. IBM introduced the PC in 1981, and it had rapidly evolved into a defacto standard computer, shoving out various CP/M designs from the previous decade. Personal computers were so new, people were trying to figure out what to do with them. Word processing, spreadsheets and other office applications had just been introduced.
Hayes was trying to stay at the forefront. We had a laboratory filled with pretty much one of every personal computer, and when new ones came out, we would buy one. In late 1983, we got an Apple Lisa. It was a very different kind of computing experience. It was a curiosity to us, and as there was no programming environment available, we didn't see how we could build software to talk to a modem. Plus, at the price point, there were few buyers.
The Macintosh
Though the Macintosh was introduced in January of 1984, I didn't get hands on one until the late spring of 1984. Yes, we brought one into the lab, and it immediately garnered a lot of attention.
While there were similarities to the Apple Lisa, the small screen with square pixels just seemed sharper and more distinct. The whole interface was friendly and approachable. We messed with MacWrite, MacPaint, and MacDraw. We printed on an ImageWriter, making appreciably decent images unlike anything we could do on another type of computer. There were several of us hooked and enthusiastic.
It's hard to describe those days. At this point, everyone has had decades to become familiar with computers that use a graphical user interface and a mouse or other pointing device to interact. Back then, it was a revelation. It was much more approachable than the command-line interfaces of the day.
As I described it to someone in the early 90s -- other computer interfaces required one to reach toward the computer. You had to learn the special language and commands of that computer. The Macintosh was the first computer that reached back toward you -- the user.
The Machine
The Macintosh was based on a 16-bit Motorola MC68000 processor, running at 8 MHz. This was more than competitive with the Intel-based IBM clones circulating at the time. This processor was a great choices by Apple. It had many registers and powerful instructions for manipulating the bit-mapped screen.
Biggest constraint was memory. The 128 KB in the Macintosh was shared with 24 KB used for the screen, several more KB for operating system usage, leaving about 90 KB to run your program. Most of the critical operating system routines were in the Macintosh ROMs, which saved space. Building a program of any sophistication was difficult -- It was very tight to work with.
The single 400 KB floppy disk drive was also a limitation. Trying to save a file to another diskette could produce an endless amount of swapping. It was the lack of addition storage that kept me from buying a Mac until the Mac SE/20 was introduced in 1987.
Next Steps
By summer, Hayes hired some consultants to look into the feasibility of developing communications software for the Macintosh. In just a few weeks, they had some rudimentary software going and concluded that it was quite feasible.
We were soon green lighted to create a product for the Macintosh.
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.
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.
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.
By August 1983, I had a working MC6809 computer with no storage. My BBUG monitor eschewed audio cassette tape. Floppy disk drives were expected -- BBUG included a Disk Boot command. Any disk controller needed to be compatible with that code.
In 1983, a friend of mine gave me an Icom Peripherals FD360 Dual Floppy drive box. A client of his had purchased the Icom, but opted to use another disk system instead. His client couldn't use the Icom box, but perhaps I could.
Icom was one of the first floppy disk suppliers with their "frugal floppy" system. The FD360 contained two Pertec FD400 8" disk drives, a couple of interface boards, and a large power supply. It is huge and heavy, larger than the SWTPc 6800 Computer System, and weighed about 70 lbs.
Pertec FD400
The Pertec drives differ from the popular Shugart SA800/801 of the same era. They have a 44-pin edge connector, as opposed to Shugart's 50-pin edge connector. The signals and power supply requirements are different. Icom's interface boards translated those connections into a 34-pin IDE connection, quite similar to what was later used with 5 1/4" floppy disks. There were a few important differences:
Data plate from the Icom FD360
- Step In and Step Out signals, instead of Step and Direction.
- Erase Enable in addition to Write Enable.
- 8" media data rates (250 kHz), instead of 5 1/4" data rates (128 kHz)
- Head Load signal (not present on 5 1/4" disks)
The FD400 has a single metal head, designed for single-density recording.
Western Digital FD1771
The FD1771 was the first in a series of LSI floppy disk controllers from Western Digital. It simplified the interface and operation of floppy disk drives. Designed for Shugart-style drive signals, it could accommodate the signals from the Icom with a bit of logic.
I had schematics for the SWTPc DC-2 controller, and borrowed from that design. The FC1771 data sheet convinced me that the data bus hold times meant data bus latching was required, so I had an extra layer of buffering on the data bus using a 74LS373 matched with a 74LS244 (for reads). These were on top of the pair of 74LS242s that buffered the data bus to the card.
Following the FD1771 data sheet recommendations, I used an external hardware clock/data separator. (The SWTPc DC-1,-2 and -3 all used the inadequate internal clock/data separator) I used the circuit from Figure 6 of the FD1771 application note. It has a 4 MHz clock, 74LS175, 74LS161 and a few other gates. Dividing the clock oscillator by two fed the FD1771 with 2 MHz necessary for 8" drives. A 74LS221 one-shot multivibrator supplied the head-load timing (HLT) signal after about 40 ms. A 74LS175 captures data bus D0 and D1 to a two-to-four decoder to allow drive selection -- up to four drives, but I only have two.
I built this controller using wire-wrap techniques on a piece of perfboard, with 30 pin Molex connectors glued to the edge. The same construction as I had used on the MC6809E V1 board. A 34-pin dual pin connector provided the connection to the Icom drives.
In my schematics, I included a 74LS221 one-shot to trigger the M.RDY line on the SS-50 bus when accessing the FD1771. But this pin is not available on the SS-30 bus. So I omitted the circuit during construction. The FD1771 did not need this additional delay.
The I/O slot memory map is simple:
01xx - Drive select latch (bits D0 and D1)
1000 - Command / Status Register (FD1771)
1001 - Track Register (FD1771)
1010 - Sector Register (FD1771)
1011 - Data Register (FD1771)
After building, I tested the controller by writing a few commands to the FD1771 by hand using the BBUG monitor. I could select each drive, move and load/unload the head. It seemed to work. Using the drives required a disk operating system.
Disk Operating System
At that time, 6809 systems generally ran TSC's Flex09 or Microware's OS-9. BBUG's disk boot command was designed for Flex09. OS-9 required a completely different set of ROMs. My friend Carl was already using Flex09, so that was my choice.
Upgrading from using cassette tape, a disk operating would seem like a bit step upwards. But Flex09 was very primitive, especially compared to the work I was doing with MS-DOS at the time.
Bootstrapping
SWTPc DC-2 Controller
Carl had Flex09 on 5 1/4" disks. As my disks were 8", bringing up Flex09 took some doing.
Carl gave me a SWTPc DC-2 disk controller, and loaned me his 5 1/4" drives for a couple of weeks. The DC-2 was surplus to his needs. He'd upgraded to double-sided, double-density controller, and the old controller was useless to him.
With the controller and disk drives, Flex09 booted up easily from the floppies Carl supplied. I just needed to get them on the 8" drive. The motherboard gave each controller a separate address, as they plugged into different slots. Some configuration changes let Flex09 know about the additional drives. Before anything could be copied to an 8" diskette, it had to be initialized. The 5 1/4" NEWDISK program didn't work for 8" disks as their formats were different.
I wrote my own version of NEWDISK. This required understanding the FD1771 Write Track command. NEWDISK generated all of the data for each track, with the proper address marks, gaps and codes that permitted the FD1771 to properly read and write the disk. Then it would issue a Write Track command to the FD1771 and the track data delivered. This process repeated for each track on the disk.
At the time, there was no defined format for 8" disks. Flex09 required 256 byte sectors. The 5 1/4" format used ten sectors per track in single-density. 8" disks had room for more. With very generous gap sizes, fifteen sectors per track fit easily.
After track initialization, NEWDISK would write the volume information, and then the boot loader into the first sector. A disk was made bootable simply by copying the Flex09 system files to the disk.
Experimentation
Reaching the point where I could boot Flex09 from my 8" disks, I reconfigured the system and gave 5 1/4" disks back to Carl. The work done on NEWDISK led me to experiment. With 77 tracks of fifteen sectors per track, my 8" drives held a little more than 288 KB each.
Reducing the gap sizes, seventeen sectors would fit on each track. This increased the storage capacity to 327 KB for a 77 track disk.
Doing some tests, I found that the Pertec drives were mechanically capable of 78 tracks. Trying to step out to the 79th track resulting in a very alarming klunk as the head reached its mechanical limit.
While I confirmed that diskettes formatted for 78 tracks were valid and reliable, I decided this was not recommended. Such diskettes might be unreadable on other disk drives. My final version of NEWDISK formatted 77 tracks, with either fifteen or seventeen sectors per track.
Success
By the fall of 1983, I had a working 6809 system, complete with 8" floppy disks drives running Flex09.
Login
