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.

Forty Years of Personal Computing - The Big Toss Out

Some time in 1985, I had one of those moments I regretted. 

I'd gotten my MC6809 system running in late 1983, running the Flex09 operating system on 8" floppy disks. I had a full set of documentation for several pieces of hardware and software. My new job kept me busy, so I didn't have much time to work with my system at home.

August of 1984, I began programming the Macintosh at work. We published our first product in March of 1985. The Macintosh was a revelation -- it completely changed the metaphor for computing. I saw early on that it was the future. But, I couldn't afford one right away. I wouldn't buy my first Mac until the summer of 1987 -- a Macintosh SE. I've only purchased Macintosh computers since that time. 

In the late spring of 1985, I prepared to move to a new apartment. I had bulky boxes of documentation in my closet. I figured that I'd never do anything more with that MC6809 system -- the Macintosh was the future. 

I threw nearly all of the documentation away. 

Two months later, in the new apartment, I regretted my decision. There were things I could do with my MC6809 computer. I had to replace the missing documentation. 

To this day, I'm not sure I found replacements for everything I had.

Forty Years of Personal Computing - Tanner/Digital Research 64KB Memory Board

Digital Research Computers 64 KB SS-50 Board

I graduated from Georgia Tech in the fall of 1983 and got a full-time job. By 1984, 20 KB of memory didn't seem like enough for the MC6809E V1 board. My attempt to expand the  8 KB MP-8M to 16 KB didn't work. And I never built the dynamic RAM circuits I designed. I wanted more memory.

Digital Research Computers marketed an SS-50 card designed by Tanner Computers in the early 80s. It sported thirty-two sockets for 2 KB RAM or ROM chips. These 2716-compatible chips were quite popular at the time.

I bought a kit for about $225 with a full 64 KB of RAM in June 1984.

Assembling the kit was straightforward, along the lines of the SWTPc kits. The board worked right away, with no soldering issues -- largely due to the excellent solder mask on the board.

For SS-50 systems, this board has several flexible options. The first 48 KB presents as three 16 KB banks that are enabled individually. Each 2 KB segment in the top 16 KB is enabled individually, allowing one to navigate conflicts in the C, D, E and F blocks of memory. This allowed for I/O on the motherboard, or perhaps RAM or ROM on the CPU board.

The board supports extended addressing on the S0-S3 pins. When enabled, the entire board responds as one 64 KB block. Each socket can contain either RAM or ROM chips, selectable by the jumper next to each chip.

Initially, I used this board without extended addressing as a 56 KB board. I later enabled extended addressing to access the full 64 KB, after modifying the MP-B motherboard to decode the 20-bit address for the I/O slots. This allowed me to use that 8 KB of RAM for a virtual disk drive, briefly.

I discovered some  extended memory issues between BBUG/Flex09 and OS-9, so I disabled the MP-B decoding.

As pictured, the board has the E000 and E800 blocks disabled, with F000 enabled, and F800 disabled. This configuration was appropriate for the MC6809E V1 CPU board and MP-B motherboard without the 20-bit address decoding, although, technically, the E800 block could be enabled, and the F000 block would not be accessible after I modified the MC6809E V1 CPU board for a 4K ROM.

Forty Years of Personal Computing - MC6809 Meets Floppy Disks

The massive ICOM "Frugal Floppy" FD360

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.