Retirement Project - Fixing up the SWTPc 6809

Given that it is 50 years old, the SWTPc 6800 Computer System which I call my retirement project has been in need of some "fixes". 

Having made the BBUG ROM monitor changes to allow for extended address decoding, it was time to do some surgery on the motherboard. Might as well make some fixes.

Post close-up

Posts

The original SWTPc kit held the motherboard in place with seven plastic clips along the edge. They were designed to be pushed down from the top and clip in to the chassis bottom. A plastic arrow held the motherboard in place and could be easily unclipped. In theory.

The sad reality is the clips never engaged correctly with the chassis bottom, and often one whole end of the motherboard would be loose in the box.

Seven posts

Around 1979, just before heading to the ISEF, I replaced these clips with #6 screws, lock washers and multiple nuts. Four nuts supply the spacing, with a fifth nut holding the motherboard in place. The #6 screws are a tight fit through the holes in the motherboard, but everything is aligned. 

I took some pictures of these beauties in case someone needs to replicate them.

Feet

Chassis bottom with new feet,
and the adhesive of the original.

The original SWTPc 6800 Computer System kit supplied rubberized stick-on feet. Honestly, they held up pretty well nearly 50 years. Along the way, one of them had fallen off and gotten lost, and the replacement foot wasn't quite tall enough. I replaced them with rubber feet held in place with a #6 screw.

This meant drilling some additional holes in the pan of the chassis. Not a big deal, nor was the placement critical. One foot borrowed the #6 screw holding the clamp for the power cord. The other three used new hardware.

I eyeballed the placement of the other three screws, and the results were acceptable -- certainly compared to the old stick-on feet.

LM7805 Bypass Caps

Input and output 0.1 uF caps
lap-soldered across LM7805.

Because the SWTPc uses an unregulated 8 volt supply, every board has one or more LM7805 +5 volt regulators. Examining my bit rate generator board, I wondered the regulator was properly bypassed. I remembered an issue in a different project where an LM78xx regulator oscillated because it wasn't bypassed correctly. 

A search of the data sheet provided a concise answer:

• All LM7805 regulators should have 0.1 uF ceramics across the input and output.
• LM7805 regulators that supply 50 mA (or more) current should have 10 uF per 100 mA on the output.

These were simple rules to follow. A quick survey of the SWTPc schematics made it clear that the designers had never heard of the first rule. There were no input bypass caps at all. Output electrolytic bypass caps were present on those drawing more current, with an occasional 0.1 uF cap. The Tanner and Gimix boards were more heavily bypassed. My home-brew boards were no better than the SWTPc designs.

This problem was easy to solve. I have a bunch of 0.1 uF multi-layer ceramic caps. I added them to the boards:

• 0.1 uF on input of bit rate generators card
• 0.1 uF on input and output of MP-S cards
• 0.1 uF on input and output of MP-C (modified to MP-S) card
• 0.1 uF on input and output of MP-LA card
• 0.1 uF on input of MC68B09 V2 CPU card
• 0.1 uF on input of MP-B motherboard

For the MP-S, MP-C and MP-LA cards,  I lap-soldered the caps on the back-hand side of the board, rather than drill holes. Easily done in a few minutes.

I added some small-value electrolytic caps to the output of some LM7805's. Generally, boards that include these caps have a 100 uF unit, which is good enough for 1 A of current -- overkill for some boards.

• 22 uF on output of bit rate generator card (more than necessary, 15 uF would be enough)
• 10 uF on output of MP-B motherboard 

It could be that none of these bypass caps are required, but seems like they can't hurt.

Extended Decoder

Dec 1986 decoder circuit

December 1986, I added an extended address decoding circuit to the motherboard. The decoding avoided aliasing of the xExxx pages that prevented access to RAM or other devices. With the MC6809E V1 CPU card, this worked fine with BBUG, but the OS/9 ROMs had a different idea on how to program the DAT, so it didn't work with OS/9. I disabled the decoder and didn't figure out the problem until much later.

When I switched to the MC68B09 V2 CPU card the problem had reversed -- the decoder would work with OS/9, but not with BBUG. 

With BBUG updated to initialize the DAT in a compatible way, I could fix the decoder. The picture shows  the original decoder was a hastily improvised circuit using a 74LS21 4-input AND gate to detect all "1" values on S0-S3, connected to IC6 Pin 6 (Enable).

I sketched out some changes to decode several address lines, but I either never made those changes, or I removed them. The key to the MP-B motherboard is IC6 - a 74LS138 3 to 8 decoder. These other address changes messed with IC3 -- a different 74LS138. The MP-B I/O port data buffers are activated from IC6, so additional decoding against IC3 was an incorrect solution, as the data bus was active, even if no I/O slot was selected.

The new decoder board had simple requirements:

• Disable Extended decode entirely
• I/O accessible from FE000-FE07F (and FF780-FF7FF)
• I/O accessible only from FF780-FF7FF

The I/O ports are aliased over a 2KB block -- each 16 byte I/O slot appears 128 times. This meant decoding S0-S3, A15-A12, A11, A6-A4. A15-A13 is handled by IC6, A6-A4 by IC3. A3-A0 is done by each I/O card. A10-A7 are not decoded. The decoder circuit just deals with S0-S3, A12 and A11.

Decoder showing jumpers

Decoder operation is jumper-selectable. This allows me to test each change and back out changes if something didn't work. The first jumper selects between the FFxxx I/O address or the FExxx / FFxxx aliased I/O address. The second jumper enables/disables extended decoding entirely. 

The 74LS21 has the first AND gate connected across S0-S3. The second gate is wired as a two-input AND that uses the output of the first AND gate and jumper-selectable A12 or a pull-up. The output of the second AND goes another jumper selecting IC6 pin 6 (Enable) to the output of the AND or a pull-up. A11 goes to IC6 pin 4 (Enable*) to ensure the I/O data bus buffers activate only on the lower 2 KB of the 4 KB memory page.

Clean mount of decoder

Circuit uses a bit of perf board and a 3M Scotchflex socket I've used for other projects. Surprisingly, I did not have a 74LS21 in my junk box. I salvaged the soldered unit I had hastily assembled in 1986. That worked out. The board is cleanly mounted on a spacer to the motherboard and all of the connections are made with wire-wrap wire.

Testing

Testing, much to my surprise, went perfectly. The disable jumper worked as before. Enabling the aliased extended decoding allowed me to use the xE pages of memory, and a special burn of the BBUG ROM allowed me to test I/O at FF780-FF7FF. This worked as expected. I could enable and use the FExxx block of RAM on the MC68B09 V2 CPU board and access it using the DAT,

Not sure why I was afraid of all these "fixes". I suppose I was shy about changing the motherboard in a way that might break the computer entirely.

Retirement Project: SWTPc 6800 (with 6809) Resurrection

In 2022, I documented my ancient SWTPc 6800 Computer System, which I had upgraded with several home-brew cards. It had been 25 years since I had last used the computer, but this ancient machine fascinated me. I wanted to record what I had done, as I'd forgotten a lot.

During this process, I plugged in one of the I/O cards incorrectly -- off by one pin. Normally, there's an index pin that prevents this, but some of my cards don't have the plug that blocks the pin. 

Sadly, when I powered it on, smoke was immediately released from one of the chips. After correcting that board, I found the system completely inoperable. This computer was 45 years old at the time, and I had many other projects that needed more attention. I decided that fixing it would be something I could do in my retirement. 

And, it remained broken until this year. You see, I've retired, so it was time debug this monstrosity.

When I originally built the CPU boards for this machine, I borrowed a 32-channel HP Logic analyzer. That allowed me to fix the bugs in the hardware and the software alike. But I long-ago lost access to such equipment. I had little more than the original kit manuals, schematics and notes, plus a digital voltmeter and an oscilloscope.

Symptoms

After the smoke let out, the machine crashed on reset. I could see from the front-panel LEDs that the CPU had gotten completely lost -- with every 4 KB block LED illuminating dimly. This is characteristic of a crash. 

Debugging

Initial step established what was working on the machine. I removed all the cards from the motherboard. I checked the power supply voltages on the motherboard:

• +8v: +8.3v
• +12v: +14.15v
• -12v: -14.06

These unregulated voltages were nominally good. I verified that several of the bus signals were pulled high on the motherboard, such as RESET*. Everything seemed good.

I added the Bit Rate Generator board. It supplies all the serial bit rates on the SS-30 bus. I couldn't find any clock rates using the oscilloscope. Looking at the original schematic and the MC14411 data sheet, I found one thing missing. The data sheet recommends a 15 M Ω feedback resistor across the crystal. My circuit had none. Other designs used a 1 M Ω resistor. So I added one. Now I found all of the bit rate clocks present. Funny that it worked before. 

Next was the 6809 V2 CPU board. The LEDs would light up on reset, then go into the characteristic crash. Examining the important signals on the bus:

• RESET* - goes low for 0.1-0.3s, then high
• HALT*, BREQ*, MRDY, NMI*, IRQ*, FIRQ* -- all staying high. 
• BA, BS - both low -- this means that the CPU is actively controlling the bus
• E* and Q* - these clocks running at 2 MHz, as expected, this mean the CPU was alive at least
• VMA* - cycling, meaning the CPU was attempting to access the bus
• R/W* - cycling as expected
• D0*-D7* - each data bus pin showed signs of normal activity
• A0-A15 - the Address bus had problems on two pins
• A3 - activity limited to 0v to 1v
• A14 - activity stuck around 0v

This was good news. The CPU was working and attempting to process instructions, as evidence by the clocks, the BA/BS status pins, and the data bus activity. 

The address bus seemed to be the source of difficulty. When the I/O board was plugged in incorrectly, one of the chips received -12v, and that same chip was also connected to A3. As there are no buffers on A2 or A3 between the SS-30 and SS-50 bus, it is possible the 74LS244 address bus buffers could have been damaged. That didn't explain A14, but it made sense.

I swapped out both 74LS244 chips, and the CPU board now acted correctly -- polling the E block of memory, where the I/O resides. The E LED was brightly lit.

An MP-S board was added next. Since it was not connected to the A3 line, it was unlikely to be damaged. I needed something to function as a terminal to connect to the MP-S. I fashioned a DB-25 to DB-9 cable and hooked it to a USB serial port on my MacBook Pro. Pressing RESET brought up the "BBUG v1.91" prompt. YES! After nearly four years of being non-functional, my old computer was able to run the ROM monitor. 

Using the capabilities of the BBUG monitor, I set about diagnosing the other parts of the system. Since the last time it was operation, I expanded the CPU board memory from 64 KB (really 56-60 KB) to 256 KB (really 248-252 KB). I set about testing to make sure all of this additional RAM was functional. Because the MC6809 processor can't access more than 64 KB of memory at once, I had to do this in steps. I manually re-programmed the DAT to use different blocks, leaving the D, E and F blocks alone. The additional memory worked great.

With the CPU card functional, I set about to determine what else was working. 

Working on the I/O slots, something was amiss with the MC6840 on the bit rate generator board. A 74LS04 inverter connected to the A3 bus line had apparently been damaged. Swapping it out restored operation to the MC6840.

The 5 1/4" Floppy Disk Controller (FDC) board was the one that had been plugged in wrong. A 74LS139 that let the smoke out had been replaced, and everything seemed to be working. Similarly for the 8" FDC board. Both boards would respond properly to basic commands, even with no disk drives connected.

The Tanner/Digital Research 64KB RAM board was next. It took some experimentation to discover how to address its extended memory address. I found that the BBUG "Q" command, which does a memory test, can be fooled by bus capacitance. That's a bug that needs to be fixed. While the memory appears to be present, at least some of the time, there appear to be some address or data convergence problems. I haven't quite sorted that out yet. 

Next Steps

There are still issues that need resolution. I've attempted to boot FLEX/09, but it fails rather quickly. It appears to be properly loading the boot loader off the first sector of the disk, but for some reason does not appear to be able to load FLEX.SYS. I think my problem is that I don't have 5 1/4" boot disks set up for these 80-track drives. Most of my use of FLEX was limited to 8" disks, and those drives aren't yet connected.

An attempt to boot into OS-9 Level I also failed, even though I have several 5 1/4" boot disks. That's going to take more time to diagnose. It could be there's other damage to the 5 1/4" FDC board that I haven't isolated yet.

Beverage Controller

Remote and controller boxes laid 
out for wiring.

With these Beverage antennas, I needed a way to switch between them quickly and easily. 

Taking a cue from the K9AY Controller, I didn't want to just hook up a rotary switch. I wanted a push-button controller. Plus, a lot of the time I'm remotely operating my station on FT8 from the house, I wanted that capability as well. 

Design

I planned for at least three Beverages, maybe more. Plus I had the K9AY loops. That's at least four antennas, having a fifth would give me a spare.

The buttons and indicators needed to be convenient to operate, up front in the station without being intrusive. 

The receiving antenna feed lines also needed to terminate at the Single Point Ground (SPG). Best option was a remote relay box to do the switching, and a small controller box containing the buttons and indicators.

Test positioning the Controller

Adding a serial port to the controller allowed the antenna selection to be interrogated and selected. I already the PIC16F18426 chips on hand. This 14-pin device has a built-in EUSART. A MAX232 would handle the RS-232 level conversion.

Construction

I found a small Bud box in my junk box for the remote. I ordered a die-cast aluminum box for the controller. It was small, but it fit very nicely up under the shelf supporting the P3. Convenient and unobtrusive.

Remote mounted on SPG

The remote has six RF connectors - four F-connectors for the Beverages, one BNC for the K9AY, and another BNC to connect to the K3. SPDT relays are used. When selected, the relay connects the antenna port to the K3 port. When unselected, an appropriate resistor connects across the antenna port. ( I used 82-ohm resistors for the F-connectors, 51-ohm for the BNC -- closest I had to 75 and 50 ohms, respectively )

I used 12 V relays. Unlike the KK1L 2x6 Antenna Switch, I didn't want to activate each relay with a separate line for +12 V. Instead, I sent +12 V to the remote box on a common conductor and then returned a signal for each relay to be grounded by the open drain pins on the PIC. 

This lead to a design problem. The PIC doesn't support true open drain outputs. Each pin is clamped to Vdd, which in this case is +5 V. That left about 6 or so volts across each relay, pulling them all in. 

To solve this, I added 2N3904 NPN transistors to the relay box as open collector drivers for each relay. A 3 K resistor connects the base of each transistor back to the PIC. Instead of a logic 0 activating the relay, a logic 1 does the same job.

The controller box is really tight. I borrowed five switches from the K1EL Keyer. The LEDs and switches barely fit. The controller itself is simple. Five RA port pins connect to the pushbuttons. Five RC port pins drive the LED indicators and NPN relay driver. One RA pin and one RC pin communicate with the serial port. 

Changing the sense of the relay switching required re-wiring of the LEDs. Before, they were tied to +12 with the cathode of each LED brought to ground by the PIC. Except that didn't work due to the design problem. Instead the cathodes went through a common 330 ohm resistor to ground, and the anodes were connected across the activation lines for each relay.

Debugging

I debugged this design in parts, starting with the controller box, then the relay box separately. Once I connected them together, I found the design problem that required much re-wiring. 

The button selection worked great. The serial port has been more of a problem. While the PIC receives commands correctly, it doesn't appear to transmit anything at all. It is a puzzlement. 

New Modes for the Auto Antenna Selector

Automatic Antenna Selector in use

I wrote previously about debugging selection modes for the Auto Antenna Selector. With that working, I wondered if I could do more. 

Originally, I thought that modes should swap the selections on the A and B ports. With Standard Mode, I was missing that. But how to allow more modes?

Flip-Flop Mode

I don't need Test Mode that often. Holding down the mode button could be divided into a short and long hold. A long hold -- 1 second or more -- would invoke Test Mode. A short hold -- 1/4 of a second, could invoke something else. 

Flip-Flop mode was born. With a short hold, the selections for Port A and B are swapped. This works both in single-radio and two-radio configurations.

The selector signals Flip-Flop mode by blinking the mode LED on and off over 1/2 second. As coded, it actually pulses for 1/2 second, then is off for 1/2 second. Not what I intended, but distinctive. I decided I didn't need to "fix" it.

Testing

Unlike the last code changes, these worked the first time. I found Flip-Flop mode helpful with the single radio when trying to use a different antenna with the AL-80A amplifier. Since it is only connected to the antenna on Port A, this mode makes this possible.

At the moment, tapping the mode button in Flip-Flop Mode doesn't do anything, still thinking about that.

Debugging the Automatic Antenna Selector

When I last wrote about the Automatic Antenna Selector, I mentioned adding modes to select more antenna options. Getting that to work took some doing.

Test Mode

Holding down the mode button invokes test mode. When entered, it selects port A0. Tapping the mode button advances to port A1, A2, to A5, then it goes to B0, B1, to B5, then back to A0. In this way, all antenna / port combinations can be selected. This allows new antennas or conducting tests or experiments before a new configuration can be programmed. 

The unit signals Test Mode with the mode LED being on continuously. Holding down the mode button again goes back to Standard Mode. 

Standard Mode

Standard mode determines antenna selections according to the connected K3 BAND0-3 signals. When only one radio is connected, both ports are based on the current band for that radio. The first port is the primary, the second part gets the secondary selection. Tapping the mode button cycles through the secondary port selections, the primary port being unchanged. 

When two radios are connected, port selections are based on the K3 BAND0-3 signal for both radios. Radio A gets the primary selection. Radio B gets its primary selection, unless that port conflicts with Radio A. It then gets the secondary selection (unless that also conflicts). Tapping the mode button cycles through the Radio B selections. 

The unit signal Standard Mode with a mostly dark LED. Off completely for the primary selection, pulsing twice for secondary, three times for tertiary. At the moment, there are only three stages. Adding a fourth would be easy.

Easy in concept, but after the code changes, it didn't all work.

Test mode worked great. Entering and exiting were reliable, and each tap selected the correct port.

Standard mode, however, didn't seem to do anything. The LED indication showed the mode selected, but the port selection did not change. I had only implemented the single radio logic, since I couldn't find a second cable to connect a K3.

Debugging

Debugging this over the last couple of weeks was driving me mad. No matter what changes I made to the code, the behavior did not change. Further, I noticed that when the K3 was on 6m, port B was also selecting a dipole antenna. That was unexpected, as it wasn't a valid antenna for 6m.

Eventually, it dawned on me that this was not single-radio mode. For some reason, the selector believed there were two radios connected.

That was a revelation. I knew there was a problem when the K3 powered down. When no K3s are connected, the selector was supposed to deselect all relays. Instead, it had two dipoles selected. 

This was connected with how Elecraft encoded the bands on the BAND0-3 pins. 60m is represented as all zeros. Even with the weak pull-ups enabled on the PIC, it wasn't enough to overcome the loading of the connected but powered-down K3.

The same problem was evident on the disconnected port -- it was registering 60m, which selected the dipole. 

Fixing

The first fix was hardware. I added 2.2k pull-up resistors to the BAND0-3 pins on both ports. After that, the relays deactivated when the K3 was powered down. But, I still saw the dipole selecting coming up on 6m when switching models. 

This was a software problem. One of the internal variables was initialized incorrect, which was the source of the 60m selection. When initialized correctly, single-radio Standard Mode selections worked as they should. 

With that working, I'm full of new ideas for improving mode selections. Once I figure out which ideas are best, hopefully it will be a small matter of code changes....

Automatic Antenna Selector Project

Auto Antenna Selector under test.

Some projects are years in the making. October 2020, I ordered the KK1L 2x6 Antenna Switch board. I assembled it and by December I rigged up a manual antenna selection switch. Two years later, I mounted the KK1L to an aluminum panel to create a Single Point Ground (SPG). While all that work was beneficial from a bonding and grounding standpoint, antennas were selected manually. If I changed bands and forgot to change the antenna selection, trouble could ensue.

The purpose in buying the KK1L 2x6 Antenna Switch was fully automatic antenna selection. I needed a controller that could communicate with the Elecraft K3 and select the right antenna. 

A PIC microcontroller seemed suitable. I'd had success using one of these chips to build a K9AY Controller. For that project I had used a PIC16F1503. After that, I picked up the PIC16F18426 and PIC16F18446 chips -- these offered more features than the '1503, including a serial port and way more program memory. The Microchip tools were free, and I had a PICkit3 programmer.

I sketched out three designs.

Design A - 1 radio, 1 set of relays

The most basic design - it does little more than replace the manual switch. A single DE-15 jack brings the BAND0-3 information from the K3 into the PIC. Three outputs drive a 74LS145 BCD decoder to select one of the six relays through a 2N3906 driver transistor. Two other outputs allow selection of the 160 or 80/75m shunt matching networks.

Total I/O required nine pins, which any of the three chips could provide.

Design B - 1 radio, 2 sets of relays

A limitation with Design A is that a K3 with the KAT3 has two antenna jacks, but the selector only chooses one antenna. Design B reads BAND0-3 from one radio, and selects the best antenna on port A of the switch, which is connected to ANT1, and the second best antenna on port B, which is connected to ANT2. The operator can then use the ANT button on the K3 to switch between the two antennas. 

This design retained the four inputs for the BAND0-3 information, plus six outputs feeding two separate 74LS145 BCD decoders, and two additional outputs for the 160 or 80/75m shunt matching network. 

That's exactly 12 pins -- still possible using any three of the chips.

Design C - 2 radios, 2 sets of relays

I liked Design B, but along the way I purchased a second Elecraft K3. If I were trying to use both radios, what would I need to switch the antennas?

Two DE-15 jacks facilitate the BAND0-3 data from each radio, requiring eight inputs. The selector could then choose the best antenna for both Radio A and Radio B, unless that choice caused a conflict, in which case Radio B would get the second-best choice.  Outputs were the same as in Design B. 

This required the 20-pin '18446, because the 14-pin controllers don't have enough I/O available. 

It occurred to me I might want to switch the antenna selection priority sometimes, so Radio B gets the best antenna in a conflict and Radio A gets second best. That required an input pin for a pushbutton and an output to light an LED. This used all the 18 pins available on the '18446. 

Design Choice - B/C - 1 or 2 radios, 2 sets of relays

First look with front panel assembled

The end design combines Design B and C features. Two DE-15 jacks are used, and the PIC software decides if a K3 is connected or not based on the pattern of BAND0-3. Unconnected pins are pulled up, so a value of all ones indicates no connection. If only one radio is connected, the software acts like Design B, if both radios are connected, it acts like Design C. 

The front panel has LEDs for the six relays on port A and B, so you can visually see which antenna is selected for each radio. An LED each for the 160 and 80/75m shunt selection, and a pushbutton and LED for the mode selection rounds out the front panel. A power switch and a switch to choose between the 80 and 75m shunt network round things out.

Power requirements are simple. A port relays take 88 mA, and B port relays require 44 mA. Selecting one relay for both ports is less than 140 mA. The 160m shunt relay requires 120 mA and 80m relay requires less. The power requirements of the PIC, 74LS145 and LEDs are negligible by comparison -- 300 mA covers everything. 

Construction

A look at the guts of the box. The relay
drive transistors dominate the board

I searched for a smart-looking cabinet for this project fitting the dimensions of the station. I found a reasonably priced enclosure on Amazon.com. I took lot of care drilling the front panel so that everything lined up correctly. I figured I might be staring at it for years. In retrospect, the rear panel doesn't look so pretty.

With the cabinet in hand, how to construct the hardware? I considered developing a PC board, but I was eager to build. I ended up using a bit of perfboard and some 3M Scotchflex prototyping sockets. The Scotchflex system is now obsolete, mainly because everything is surface mount, but I had most of this in the junk box. I had to engineer a 20-pin 0.3 inch socket -- which I accomplished with two 14-pin sockets back to back.

The downside to this approach is all the wiring required for the relay and LED driver transistors -- there are fourteen 2N3906s, three 2N3904s and a bunch of related resistors. A PC board would have taken more design work ahead of time, but the construction would have gone quickly and taken less space.

I worked on this project off and on in six different locations - Gwinnett county, Fulton county, Warren county, two locations in Gordon county and finally from Floyd county. For a while, I carried the whole project with me in a small cardboard box wherever I was.

Software

Like the K9AY controller, everything is interrupt-driven. The '18466 CPU is configured with a 500 kHz clock speed, and a timer interrupt occurring every 5 ms. 

During the interrupt, we sample the A and B ports from the radios, plus the mode button. All of these values go through debounce logic - the value must hold for 10 interrupts (50 ms) before taking action.

If either the A or B values change, or the mode selection changes, then the antenna selection logic is followed. If either port is all ones, it indicates a radio isn't connected, so the Design B rules are used to select the antenna. If neither port is all ones, we assume two radios are connected, and Design C rules are used to make the selection. 

Debugging

Unlike the K9AY controller, I had a bit of trouble getting the software working. Part of the struggle was knowing if a problem was a wiring problem or a software issue.

At first, nothing seemed to work. In the end, I wrote really simple firmware that just blinks the mode LED based on the timer. Nothing. Setting up the chip on a solderless protoboard, still nothing. After some experiments, I got the timer interrupt straightened out and had a blinking LED on the protoboard. 

Then came the wiring issues on mode LED. One issue was the transistor drivers for the LED didn't have proper pull-ups. Eventually, I settled on a one second startup routine that would blink the mode LED briefly once, then twice. After that, the chip would be looking at the input ports and selecting antennas.

In the next phase, I wrote an additional startup routine that selected the antenna for ports A and B. Every second or so, it selected a different relay, and hence light the LED. I coded it to go in a pattern so I could verify that each relay driver and LED worked correctly. Of course, it didn't work.

Several wiring problems became apparent. First, the 74LS145 chips weren't getting any +5 volt power, so they weren't doing anything. They had been wired, but one of the wires broke. Once fixed, the LEDs lit. Then it was apparent they were going in the wrong order. 

The wiring between the PIC16F18466 and the 74LS145 chips had two problems. First, the pins for the A port and B port had been reversed. Second, outputs from the 74LS145 were reversed. Putting out a value of 001 into the 74LS145 selected antenna 5, and a value of 110 selected antenna 0. Rather than doing a massive amount of re-wiring, it was easier to change the software and re-draw that part of the schematic. 

Then we finally come to the business end -- hooking up the K3 BAND0-3 inputs. That's when I found my last wiring error. Turns out, I had swapped the pins between rig A and rig B. Another problem solved with a software change.

It Works! Now What?

Even with the basic software running, I felt the need for change. I've disassembled my station in Gwinnett county, and the antenna configuration I programmed, even designed this Automatic Antenna Selector for no longer exists.

The antenna selection logic originally was a bunch of switch statements embedded inside if / else statements -- not very easy to change. I re-coded to use a short table of eleven rows and four columns. The rows represent each band, 160 through 10m, including 60m. The columns are the first, second, third and fourth choices of antennas. Much easier to understand and update.

I expanded on the idea about the Mode button. Originally, it was just primary / secondary. To allow for up to four antenna choices, perhaps there are more than two modes. How does one tell which mode you are in? The mode LED was programmed as just on or off. I could have it be off for primary, blink once for secondary, twice for tertiary, and three times for quaternary.

The last issue was how to test the relay action without having to program a new antenna configuration.  Currently, there's nothing programmed for relay position 4. If one wanted to hook an antenna there to test it, how do we do that without burning a new chip? 

Holding down the mode button could select a special mode that selects ports A0 ad B5. Then, each time you tap the mode button, it would switch: A1 and B4, A2 and B3, etc. In this way, each port can connect to each antenna. And the mode LED would indicate this with a solid on condition. Hiding the mode button again would switch back to the to the normal program.

How about using a radio other than the K3? Maybe I want to use the Novice Transmitter, or perhaps my trusty Elecraft K2/100. Perhaps we re-purpose the seven-position manual selection switch to encode K3 band values. A simple diode matrix would work, and I have a bunch of 1N270 diodes, 

This project is now working, but it is far from done.

Forty Years of Personal Computing - 16/32-bit Dreams

Back in the days when we were fooling with 8-bit computers, we dreamed about 16 or 32-bit processors. Digging through my notes and records, I found a couple of items. These projects were contemplated, but never built. 

MC68008

When Motorola introduced the MC68008 in 1982, I toyed with the idea of putting one on the SS-50 bus. In my notes, I mapped out the signals required. It might have worked, but it was an awkward fit. The MC6800/MC8609 had synchronous memory access, but the MC68008 was asynchronous. Plus, the MC68000 family really wanted a 16-bit bus.

While I never built anything -- it was more of a thought experiment -- it might have been one of the first applications of a 32-bit processor running on a bus designed solely for an 8-bit processor.

A couple of years later, I spent a lot of time programming the 68000 processor when I started doing Mac development in August of 1984.

NS16032 / NS32016

NS32016 chip set samples, plus a couple
of Dynamic RAM and Refresh Controllers

National Semiconductor (NS) got left behind in the microprocessor chip races even though they were an early entrant. In 1974, they produced a single-chip processor known as the PACE -- a 16-bit design inspired by the DataGeneral Nova. This early pMOS implementation required three power supply voltages, and the bus requirements made designs complex.

By 1976, NS introduced an 8-bit processor, the SC/MP. Compared to the Intel 8080 or the Motorola 6800, it was underpowered. While it may have been a good choice as a micro-controller, the second-generation designs such as the MC6811, MC6805, Intel 8051 and Z-8 choked the SC/MP out of that space.

In 1982, National Semiconductor introduced the NS16032 -- later re-branded as the NS32016. NS32xxx refers to the 32-bit nature of the processor, and the trailing 16 refers to the bus width. It was clearly a competitor to the Motorola 68000, which was introduced in 1979. The NS32016 family was actually a collection of five devices:

• NS32016 CPU - Central Processing Unit
• NS32081 FPU - Floating Point Unit
• NS32082 MMU - Memory Management Unit
• NS32202 ICU - Interrupt Control Unit
• NS32201 TCU - Timing Control Unit

Together, they form the processing core. Depending on the type of system, you might not need much more than the CPU and TCU, provided you didn't need floating point, memory management, or prioritized interrupts. This made for an extensible system based on a common processor core

National Semiconductor also offered a Direct Memory Access Controller -- the NS32203.

Clock speeds of 6, 8 and 10 MHz don't seem fast by today's standards, but where competitive back in 1982. This chip needed a minimum of four clock cycles to access memory -- the same as the Motorola 68000.

Architecture

National Semiconductor devoted a lot of their design work to producing a Complex Instruction Set Computer (CISC) specifically to support high-level languages. The NS32016 has a rich set of addressing modes including direct register, register relative (including the Frame Pointer, Stack Pointer or Static Base registers to which an additional displacement may be added), immediate, absolute, external (using a link table entry). Indexing by a register allowed easy access to local and global variables of high level languages. 

The NS32xxx architecture sported eight registers, a program counter, two stack registers (user and supervisor), a frame pointer and a static base register. The design specified module and interrupt tables in memory. 

Design Ideas

In late 1983, The NS32016 process inspired me to write a 20-odd page article about a "personal minicomputer" -- since I considered this design to be more of minicomputer power level that a microcomputer. It certainly was a lot more powerful than the 8-bit microcomputers of the day.

Sometime in 1984, I obtained a couple of engineering samples of this chip set. From this, I started creating hardware designs. Drawing out the basic core from the five chip set was easy. But a real computer needs memory and peripherals.

At some point, I obtained a second-hand S-100 chassis -- a BYT-8 system. Just a motherboard, power supply and front panel. The S-100 bus had a lot of interconnections and could serve as the backbone of an NS32xxx system, but it wouldn't use the same signals. I ended up scrapping the front panel and painting the cabinet flat black.

For memory, I decided to make use of other members of National's line up:

• DP8419 - Dynamic RAM Controller
• DP84300 - Programmable Refresh timer
• DP84412 - Dynamic RAM Interface

These chips made it very easy to construct a memory array with dynamic memory chips. The designs involved 64K bit dynamic memory totaling 256 to 512 KB. It all depended what I could fit on an S-100 board.

The presence of a memory management controller made virtual memory a possibility. The rest was a small matter of software. In my initial designs, I planned to use the Pertec 8" floppies for virtual memory. Perhaps slow, but possible. In mid-1985, I mapped out the Pertec FD400 internal interface boards as part of this effort.

Other than a bunch of schematics and a painted chassis, I never built anything. A good thought experiment, perhaps. Even with working hardware, the operating system software would have taken years to get going.

And the NS32xxx series wasn't without problems. Part of the reason this chip set never caught up is it was full of defects. National went through several iterations over years to resolve the defects, missing their window to catch the MC68000 family or the Intel 8086 family.

RTTY Contest Operation and Messages

In 1985, I built a home-brew decoder and experimented with RTTY, but I never got it to work. I've since decided that I didn't know how to tune RTTY properly. Things changed in 2005 when I downloaded CocoaModem made my first RTTY contacts. 

Since I was involved in contesting, I naturally turned to RTTY contesting. Today, it is unusual to hear RTTY signals on the bands except during contests. Thirty or more years ago, RTTY was commonly heard on 80 and 20m. 

Characteristics

Several characteristics of RTTY must be understood in order to communicate effectively: 

• RTTY has no error correction or detection -- unlike AMTOR, Packet, FT4 or FT8. This means whatever that prints might be wrong. And if it is wrong, you will not know. 
• RTTY prints garbage. Without a signal, random characters print. This further complicates determining what is correct and what is not. 
• RTTY does not handle multiple signals well. When two or more stations call at the same time, RTTY will not print reliably. Certain decoders may print the strongest signal, if you are lucky.
• RTTY text comes in a continuous stream. Long lines wrap to the next, or one can force a new line by sending a carriage return / line feed combination. Wrapped lines are often difficult to read.
• RTTY has two shift states, LETTERS and FIGURES in the Baudot encoding. RTTY rests in the LETTERS state. An unprinted FIGURES character is transmitted to shift to the FIGURES state. A similar LETTERS unprinted character can be sent to shift back, or one can automatically unshift on a space character. 

Principles

For effective RTTY contest communication, several principles apply. 

• Brevity - every character sent must have a purpose. There should be no wasted characters.
• Duplication - every important element should be sent twice. This contradicts the brevity principle. Because RTTY prints incorrect characters, sending important elements twice helps ensure correct reception.
• Scrolling - each message starts a new line, but ends with a space. This technique keeps lines from wrapping, and avoids the end of message being confused by garbage characters when the signal drops. 
• Shifts - avoid needless shifts. Any sequence involving the unprinted FIGURES or LETTERS characters takes longer to send. 

Messages

(I'm using N1MM messages for my examples. Other software may have different macro names and techniques, but the same principles apply)

Every message starts with a {TX} and ends with {RX}. This transitions the software to transmit and back to receive. 

S & P

Let's say you want to answer someone's CQ. This means you need to send your call. For that, you'd use a macro like this:

{TX}{ENTERLF}{MYCALL} {MYCALL} {RX}

or

{TX}{ENTERLF}* * {RX}

(For N1MM, the asterisk and {MYCALL} macros are the same)

Notice the message starts with {TX}, performs a carriage return / line feed with {ENTERLF}, sends the call twice, ends with a space and then {RX} to go back to receive. Sending the call twice helps to ensure the recipient receives it correctly.

If you are lucky enough to get a response, you'll have to send the exchange. The exchange will vary by contest, but it could be a message like this:

{TX}{ENTERLF}! 599 GA GA DE {MYCALL} {RX}

This is what I send in the RTTY Roundup. First is the recipient's call (!). Then 599 -- don't use 5NN, because that actually takes longer to send in RTTY -- and send it only once, because it isn't important. Then the exchange is sent twice, followed by the prosign DE and my call, followed by a space. 

N1MM's authors recommend you use the ! character rather than the {CALL} macro. The reason is that {CALL} isn't subject to correction -- it sends the contents of the Call field at the start of the message. The ! character will send the Call field as it is being corrected in real time. As a practical matter, most RTTY contest contacts involve pointing and clicking on callsigns, so there's less typing, and therefore fewer corrections involved.

A couple of things here. Notice I did not use the {EXCH} macro above. When there are multiple elements to the exchange, I put the repetitions together. So, I tend put the exchange information into the macro directly. For example, here's an S & P exchange for CQWW RTTY:

{TX}{ENTERLF}! 599 GA GA 5 5 DE {MYCALL} {RX}

GA for Georgia, and 5 for zone 5. For NAQP RTTY, it would be:

{TX}{ENTERLF}! 599 BILL BILL GA GA DE {MYCALL} {RX}

Some might balk at the use of the DE prosign, particularly for exchanges that involve a state or section, since DE might be confused with Delaware. However, I think this prosign is useful, as it establishes the callsign is of the answering station, and not the CQing station.

CQing

Calling CQ in a contest is the most-used message:

{TX}{ENTERLF}CQ RU {MYCALL} {MYCALL} CQ {RX}

Note that the important information -- the callsign -- is repeated. The other curious thing is the "CQ" at the end. This indicates I finished a CQ message. This is important because one cannot tell when potential callers tune in to your signal. If they do so during the first callsign, the can't tell if you are calling or answering a CQ. Putting "CQ" at the end establishes you are calling CQ. And it is shorter than "QRZ?".

Naturally, one indicates the contest in the CQ message. Here it is "RU" for Round Up. Use whatever is appropriate for the contest, or simply "TEST".

When someone answers your call, you send an exchange message:

{TX}{ENTERLF}! 599 GA GA ! {RX}

Note that the exchange is sent twice, and if there were more than one element to the exchange, I'd send those twice as well:

{TX}{ENTERLF}! 599 BILL BILL GA GA ! {RX}

Another item to notice is there is no {MYCALL} macro in this message. Instead, the caller's callsign (!) is sent twice, once at the beginning and once at the end. There are two reasons for this. First, it follows the principle of sending important information twice. It could be the caller's callsign printed incorrectly to me, or perhaps it will print incorrectly when I send the message back. If I only send the callsign once, the caller might or might not correct it if is wrong, or they may correct it if it printed incorrectly to them. 

Unnecessary corrections are a waste of time, but necessary corrections are desired. 

Second, it may be that during the response with the exchange, other stations may also be calling. This, creates a good chance that the initial callsign in the response will print incorrectly. If you don't send the callsign again at the end, it could be unclear who you responded to. 

Once you've received the exchange from the caller, one sends an acknowledgement:

{TX}{ENTERLF}! TU DE {MYCALL} CQ {RX}

Short and simple. Two features here. One is the DE prosign, to indicate this is the transmitting station's call, and ending with "CQ" to invite new callers.

Turnaround

Occasionally, multiple callsigns will print in response to a CQ. You can only respond to one at time.  Since you can only respond to one at a time, this leaves someone waiting. Rather than have them call again, you can use a turnaround message which acknowledges a completed contact and starts a new one:

{TX}{ENTERLF}! TU {LOGTHENGRAB}NOW..{ENTERLF}{F5} 599 GA GA {F5} {RX}

This message omits {MYCALL}, and uses the {LOGTHENGRAB} macro to first log, then grab the callsign off the automatic decode stack, then it follows with the normal exchange. If you use Single Operator Call Stacking, you can use {LOGTHENPOP} instead. See the N1MM manual.

Note that instead of using the exclamation point (!), we use the {F5} macro. Both the exclamation point and the {CALL} macro won't be updated by the {LOGTHENGRAB} macro, but {F5} will.

Short

When signals are strong, and the bands are quiet, perhaps the principle of sending information twice doesn't apply. Most RTTY contests allows contacts on multiple bands, and the exchange doesn't change. In these cases, you may want to have short messages handy. Here are some examples:

{TX}{ENTERLF}! 599 BILL GA DE {MYCALL} {RX} -- short S & P exchange

{TX}{ENTERLF}! 599 BILL GA {RX} -- short exchange for S & P or CQing

{TX}{ENTERLF}599 BILL BILL GA GA {RX} -- repeat of just the exchange 

{TX}{ENTERLF}CQ RU {MYCALL} CQ {RX} -- short CQ

{TX}{ENTERLF}TU DE {MYCALL} CQ {RX} -- short acknowledgement

All these should be used when you have solid copy, want to get back to other callers quickly, or you are fairly certain the other operator already has your exchange information from a previous contact.

Tips

Some tips I've picked up over the last decade that are helpful.

• Use Slow AGC - Fast AGC can confuse decoders and introduce print errors
• Use TX Filtering on AFSK - If you are using MMTTY or similar software, use the 512 tap TX Filter. It helps transmit a cleaner signal.
• Listen with Headphones - sometimes you can hear signals that don't always print, if you listen with headphones, you can hear the stations calling you. It also helps you improve your timing in a pile.

On that last tip, turn the volume on the headphones way down. You just have to sense when signals are there, you aren't decoding them. (I believe it was the late Irv Hoff, W6FFC (SK) -- a RTTY pioneer -- who suffered hearing loss at 2125 and 2295 Hz from listening to RTTY signals)

Practical Messages 

There are a handful of other messages you may wish to have handy. Here's one I use often, when you didn't copy anything sent:

{TX}{ENTERLF}AGN AGN {RX}

Or perhaps you need a fill of one element:

{TX}{ENTERLF}STATE? STATE? {RX}

{TX}{ENTERLF}NR? NR? {RX}

{TX}{ENTERLF}NAME? NAME? {RX} 

 Before you open up with a CQ on a frequency,  this is good one:

{TX}{ENTERLF}QRL? DE {MYCALL} {RX}

 Maybe if you are not sure someone is calling you:

{TX}{ENTERLF}QRZ DE {MYCALL} {MYCALL} {RX}

Or the short version:

{TX}{ENTERLF}QRZ DE {MYCALL} {RX}

Every once and a while, directed call is useful, especially when two stations are calling CQ on top of each other:

{TX}{ENTERLF}! DE {MYCALL} {MYCALL} {RX} 

Conclusion

RTTY contests are a ton of fun. Program a set of messages and try it. You'll like it.

The Great LoTW Outage - Continues.

Update July 1, 2024. LoTW is back up! It is running slow, but it is available. Thank goodness.

--

When I wrote the article back in May, I hardly thought that LoTW would be down a month later.

Sadly, the outage continues. 

My suspicions were correct, however, that this was something more than a simple networking problem. The ARRL has since admitted their network was viciously and uniquely hacked. I can certainly understand their caution to make sure that every system linked to LoTW is given a clean bill of health before turning the system back on.

Earlier this week, on Tuesday there was apparently a brief period of time when LoTW was accessible. A couple of my ham buddies managed to upload some contacts. They'll have to wait for confirmations when the rest of us can get in.

I do hope it is soon. I'm really missing this service.

RealVNC Changes Terms, without Notice.

Just over three years ago, I figured out how to Remotely operate FT8 using a product called RealVNC. 

RealVNC had a Home plan that allowed up to 3 users and up to 5 devices for non-commercial use. Perfect for remotely controlled computers in a ham radio shack.

Today, without any notice, RealVNC disabled my Home plan, and I had to choose between paying each month for a plan, or adopting their Lite plan, which allows 1 user and up to 3 devices for non-commercial use.

That's fine. They allow me to use their secure remote access software without fees. I can understand they might want to change the terms.

The Lite plan fits my usage. I've only ever had two devices active anyway, and it's just me as the user. 

But, without notice - that is just damned inconvenient. Since I switched plans, I need to visit each device and re-configure them to be part of the new plan. Which means I can't remote into those computers until that is completed. 

And, of course, since I'm remote, I'm not there.

Quite inconvenient.

The Great LoTW Outage

May 16th, there was an issue with Logbook of The World (LoTW). I could not load the main page at all -- receiving an error indicating the server wasn't responding.

That's pretty normal stuff, actually. There are dozens of problems that can result in this kind of error, so I wasn't surprised. I figured the ARRL staff would address it quickly. But, after much of the day, I was still getting the error. 

So, I sent a message to lotw-help@arrl.org, informing them that the web site wasn't responding, kindly asking when they expected it to be back up. I mentioned I was surprised there was no notice of the outage on the ARRL.org web site.

Later that day, the ARRL put up a notice that there was a service disruption involving access to the network, and that it affected LoTW and the ARRL Learning Center. They even updated it the next day, addressing concerns users had over information privacy.

But then, nothing happened. Not until May 22nd, when they updated the notice without really adding any information. 

Now, part of this delay may be due to the fact that much of the ARRL staff were all out at the Xenia Hamvention. But, that was a week ago.

What gives? Sure, networking problems. Honestly, though, as a computer professional, networking problems generally don't take more than a week to solve. I'm beginning to suspect there's something more than the ARRL hasn't told us, but I can't be sure.

I'm really missing access to LoTW. In the last 20 years, it has really become central in my enjoyment of the hobby. I do hope I'm wrong, and that ARRL manages to fix this problem soon.

How 1984 wasn't like "1984."

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.

Forty Years of Personal Computing - Gimix 256 KB Static RAM

256 KB Gimix Static RAM board, sans battery.

In 1991, my employer moved to a new building. Before the move, we cleaned out storage closets containing old equipment. Much of this was obsolete gear. Things like pairs of "twiggy" disk drives removed from early Apple Lisa systems upgraded to 3 1/2" disks in 1985.

In one closet, we discovered something unusual. It was a complete Gimix III "Ghost" system. This was a  2 MHz 6809 system sporting a fifteen-slot SS-50 motherboard and eight SS-30 slots and floppy disks: a top-of-the-line 6809 system from the early 1980s. 

By 1991, the company had no use for this equipment. I had the impulse to take the entire system home, but I didn't have room. My wife and I were living in a small house and the garage was already packed. She would not have been happy if I brought home a bunch of equipment. 

Instead, I salvaged exactly one board -- a Gimix 256K CMOS Static RAM board. It sported 256 KB of memory, with several options, including battery backup. The rest was scrapped by an electronics recycler. 

Obtaining the board, I tried it out in my system. I was able to map in 4 KB blocks of memory and test them. They all worked. I might use the additional memory as part of a virtual disk drive. 

In 1994, I moved, and the entire system was stored away for over 25 years. Looking at it recently, I found it needed repair. Over the years, the backup battery failed and leaked electrolyte on the board and motherboard. Several Molex connectors are damaged, and need to be replaced. Some of the components show signs of corrosion from the battery electrolyte. 

I removed the failed battery. I do hope the rest of the board still works once the repairs are complete. Perhaps I'll fix it in my retirement.

Forty Years of Personal Computing - MC6809 V2

MC6809 CPU card, version 2.

By March 1988, the MC6809E V1 card I designed in 1983 needed updates. I built an entirely new card with new features intended to run OS-9 more effectively. 

CPU

A MC6809 chip simplified things with the on-chip clock oscillator. The chip handled M.RDY without extra logic, and the rising edge of the Q clock did not need delay.

Memory

The MC6809E V1 card had no on-board RAM. There wasn't room. By 1988, a number of manufacturers had 32 KB static RAMs in 28-pin packages. 64 KB of memory is realized with a couple of chips. 

For the V2 board, I allowed for eight chips, totaling 256 KB of memory. This was a good compromise between cost and the space available. The memory is logically separate from the rest of the card -- decoding from the physical address and data bus, using appropriate buffers. In this way, the memory can be accessed by a bus master other than the CPU. It responds to physical addresses C0000-FDFFF or FEFFF, jumper selectable. For years, it held two chips -- 64 KB on the board -- with only 56 KB accessible. The six remaining chips were added recently, making 248 KB or 252 KB accessible. 

Buffering

20-pin bus driver chips reduced the chip count, even with two sets of bus drivers, one for the CPU, and one for the memory array.

Program ROM

The design allows for a much larger ROM. The MC6809E V1 card originally had two 2KB 2716-compatible sockets -- one for a ROM and another for ROM or RAM. To make swapping OS-9 and BBUG easier, I changed this to a single 4 KB 2732-compatible ROM socket

For the MC6809 V2 board, the ROM can be a 27128 or 27256-compatible device, holding 16 KB or 32 KB, respectively. The larger ROM permitted more OS-9 modules to reside there, if desired. 

As built, a 27256-compatible EPROM is used, containing a BBUG image in the top 4 KB of the lower 16 KB and the OS-9 ROM image in the upper 4 KB of upper 16 KB half. A jumper selects which half is active. This is much easier than swapping chips to go between BBUG and OS-9.

Accessing the correct amount of the ROM requires clever decoding. 

Decoder

A hard-wired decoder would limit the flexibility of the system, and it would be complex and difficult to change. Rather than discrete logic, the decoder consists of a Cypress Semiconductor CY7C291 2Kx8 EPROM. This is a fast device with a 70ns access time. The CPU address lines A5 to A15 are connected directly to A0 to A10 on the chip. The decoder is enabled with the logical OR of E and Q, which asserts during three quarters of the memory cycle. This way, the eight data output pins can be used as decoder selects programmable on every 32-byte segment of memory.

Three select lines are used: one for bus access (including the on-board memory array), one for the program ROM, and one for the DAT. Each select line is pulled up to +5v. Placing a 0 bit in the decoder ROM data array makes the select line active for that 32-byte memory segment. 

Modifying the memory map becomes a simple matter of programming the decoder ROM. I programmed the following logical memory map:

• 0000-EFFF - Bus
• F000-F77F - Program ROM
• F780-F7FF - Bus
• F800-FFFF - Program ROM
• FFE0-FFFF - DAT (writes only)

This configuration is compatible with the existing ROMs for BBUG and OS-9, which require I/O at E000-E07F. It has 4KB of program ROM, except for the hole at F780-F7FF. This hole deserves a bit of explanation. 

I/O Port Address Migration

BBUG occupies the top 2 KB of ROM. The OS-9 ROMs take up nearly 4KB. However OS9p2 doesn't use the last 128 bytes of that space. This unused space became an alternate location for the I/O ports. If the I/O ports moved from E000-E07F to F780-F7FF, the MC6809 could use RAM in the logical E block (E000-EFFF), for a total of 60 KB of RAM, up from 56 KB. 

Moving the I/O address requires motherboard decoder changes and software changes to the BBUG and OS-9 ROMs, as well as revision to Flex09 and OS-9 I/O configurations. The V2 board decoder ROM would work with the existing motherboard, or with the motherboard and ROMs altered for the new I/O addresses.

Larger ROM

Once the I/O addresses are moved, the decoder can be reprogrammed to allow for more ROM space. This opens the option of moving OS-9 modules into ROM. The decoder allows the lower limit of the ROM to be changed in 32-byte increments. This allows an OS-9 system to be entirely in ROM. OS-9 would start from the reset button without requiring a boot disk.

DAT

Back side of MC6809 V2 card.

The DAT configuration is similar to the MC6809E V1 board, with one important difference. In the SWTPc MP-09 board, as well as my V1 board, the outputs of the DAT are inverted on the lower four bits (A12-A15), but non-inverted on the higher four bits (S0-S3). 

This means that values programmed into the DAT must be one's complemented on the lower four bits (A12-A15), with the higher four bits (S0-S3) not complemented. 

For the V2 board, all eight bits of the DAT are inverted on the bus. Thus, the value programmed into the DAT is the one's compliment of the highest eight physical address bits (A12-A15, S0-S3). 

Which makes programming correct DAT values simpler, since the entire byte is complemented.

I introduced a hardware bug in the DAT decoder. More on this later.

Building

Rather than wirewrap, I opted to try something new. A technician from work gave me a couple of 3M Scotchflex Breadboarding kits. This breadboarding system was brilliant. Chip sockets connected to IDC pins. Wiring is accomplished by forcing wire-wrap wire between the IDC pins with a special tool. 

It is way  easier than wire-wrap, because there's no tedious cutting, stripping, threading and winding of wire. One lays the wire down and pushes it on to the pins. Wiring several connections in succession, such as with a bus, is a breeze. The results also look great. The IDC pins are low profile, so there's less chance of shorting a connection than with wire-wrap.

It's sad 3M discontinued this product. It was great. 3M has since re-used the Scotchflex brand on three other products.

Fixing the Bug

The MC6809 V2 board worked great. There were no wiring errors. I did find a problem with the DAT.

In the default BBUG and OS-9 configuration, the DAT is written once during reset and never touched. And that seemed to work just fine.

Then I started playing with an OS-9 driver called VDisk. It created a virtual disk from selected extended memory blocks. At the time, I had 56 KB of memory from the MC6809 V2 card, plus another 60 KB from the Digital Research Computers / Tanner card. That made possible a 60 KB virtual disk.

Every time I tried to access the virtual disk, the computer would crash. This took a while to track down. 

I eventually realized the new decoder did not take into account the clock cycle when accessing the DAT. Transients on the R/W* line early in the clock cycle could cause bad data to be written to the DAT. After I added the missing gate, the VDisk driver worked perfectly. 

Usage

Like the MC6809E V1 board, this V2 board was exactly how I wanted it. There are only two jumpers. 

The jumper at the top edge of the board selects the 4 KB portion of the EPROM. This makes it easy to switch between OS-9 and BBUG. No more hassle of changing out chips - just move a jumper.

The jumper in the middle of the board, just above the decoder ROM enables the FE000-FEFFF block of on-board memory. This would be installed once the motherboard I/O addresses are moved out of the E-block of memory and would allow 60 KB of RAM to be used.

Future

Moving the I/O addresses out of the E-block gains 4 KB more usable memory for OS-9. Perhaps I'll try that in my retirement.

Another fun project would be to put a full OS-9 Level I system into ROM. Unfortunately, all of the essential modules take up just over 16 KB of memory, so the division doesn't fall on a natural 4 KB boundary. This might cause a conflict accessing extended memory with the DAT.  I'd also have to figure out how to program the decoder ROM. There are not many EPROM programmers that can program the Cypress Semiconductor CY7C291 devices, and I no longer have access to the ones I originally used. 

OS-9 Level II

This design works well for OS-9 Level I. To run OS-9 Level II, which allows each process to have a full 64 KB address space, requires more hardware. First, a second set of DAT memory chips allows the user and supervisors states to have separate memory maps. Second, a means of switching between those maps automatically -- like when servicing and returning from interrupts. Third, would require ROM to be accessible from an extended memory address, and then mapped into the supervisor space. 

Those requirements go beyond the scope of this design. Perhaps there's room for a V3 board. All of this assumes access to a copy of OS-9 Level II, which may be difficult to find. 

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.