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 4KB 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.

Claude Helps with the Automatic Antenna Selector

Automatic Antenna Selector

I thought I was nearly finished with the Auto Antenna Selector. During my first week of retirement, I finally managed to locate something I had been looking for months -- A male-to-male DE15 cable. 

This cable connects the Auto Antenna Selector to the AUX port of a K3. I bought two of these a couple of years ago, and I easily found one. But the second one eluded me. Without it, I couldn't test the Selector in Design C (Dual Radio) mode. I had done all my testing in Design B (Single Radio) mode. 

Having the proper cables, I did my testing and found several bugs. Some of them were going to be difficult to fix. Part of the problem was my approach. I had organized my antenna selection table by the selections, then by band. This made it difficult to determine the choices available per band. So, I organized the table by band, then listed the choices. From this, I could determine which choices were available for a given band, skipping over those that would conflict with an existing port. 

This greatly simplified the code for making the mode selections, which are very different in Design B (Single Radio) and Design C (Dual Radios). In Design B, the first selection is assigned to the first port, so there can only be three additional choices. In Design C, only one port is selected per radio, so we can potentially use all four selections (so long as there's no conflict with the other radio).

Design C bugs were all addressed, and Design B worked better than ever.

Before I retired, I'd been messing around with Anthropic's Claude Code. I was curious what Claude might think of the firmware, so I requested an in-depth code review.

Claude Code came up with a number of good suggestions. It found some dead code, made several type suggestions, a minor code re-organization, and way better comments.

What impressed me, though, was that Claude Code had a deeper understanding of the particular PIC processor that I did. It suggested I turn on the Watch-Dog Timer (WDT). That I change how Timer 0 (TMR0) was used. And, that I use the PMD register to power-down the modules that I wasn't using in the device. 

I thought I was using TMR0 correctly. And I knew about the WDT, I just didn't think it was necessary. But the PMD register I knew nothing about. All of these suggestions seemed like a good idea to me, so I made them.

All in all, Claude Code did eight rounds of review of this code. It made a couple of suggestions that I knew were wrong, and it took corrections well. 

The next day, I burned a chip and plugged it in the unit for testing.

It bricked, Nothing. Not even a single flash of the LEDs on startup.

Somewhere in the midst of Claude's suggestions, we had changed the software in a way that it no longer worked at all. 

I made a new branch of the code and backed out some suggestions. I determined it had nothing to do with the WDT or PMD register. That left something amiss with TMR0. This could be a problem with Microchip Code Configurator (MCC).

I had switched TMR0 to use the HFINTOSC. It was programmed to generate an interrupt every 5 ms. Except it didn't work. I switched it back to us the LFINTOSC, also programmed for every 5 ms, and it worked as expected. I'm not sure why it didn't work with the HFINTOSC, but having several oscillators gives one options. I'm happy it works.

Once it was working again, I walked through all of the Design B and Design C test scenarios. Everything worked with flying colors. 

AI is certainly useful, even for amateur radio projects. Just don't blindly trust it. Remain in the loop for all changes.

Polishing Up the Rx Antenna Controller

Many software projects are never fully complete, as there's always something to add with a small change to the software. The Rx Antenna Controller isn't any different. 

The initial version of this project was basically done. But pressing the antenna selection buttons resulted in a response on the serial port. This could cause problems with computer control if the response was not anticipated.

I added a new command: &AI; and &AIn;. This gets and sets the Auto-Info mode, respectively. With &AI1;, pressing an antenna button results in an &ARn; response on the serial port. &AI0; turns off Auto-Info mode -- button presses do not result in a serial port response. The default is &AI0;.

I"m very happy with the way this project has turned out. While I have ideas for a Version 2, it mostly involves hardware changes to the remote switching box to allow selection of the AUX antenna for diversity reception.

Rx Antenna Controller

Rx Antenna Controller is QRV.

I started building this unit a couple of months ago. I called it the Beverage Controller, because my motivation was to select amoung the three Beverage antennas I had erected. Yes, I've managed to erect three 500 foot Beverages, one to the NE, SE and NW.

Performance of these antennas is convincing -- 1-2 S-units lower noise than the inverted-L or dipole antennas I use on 160 and 80m, respectively, plus a directional signal boost if the beverage is pointed in the right direction.

I discussed my design issues with this unit in the previous article. Debugging the serial port took another month.

Serial Port Debugging

The reason I had chosen the PIC16F18426 for this design was because of the built-in EUSART. Receiving worked just fine. I could send commands to the controller and it would act on the commands. But it sent no response. 

I had configured the PIC to use RC5 (pin 5) for the EUSART receive input, and RA5 (pin 2) for the EUSART transmit output. After a bit of troubleshooting, I found no action on RA5. It remained at 4.5 V the entire time. Was this a wiring problem, or a programming problem?

I ended up writing another PIC project and setting up a chip on a solder less breadboard to solve this. This project simply sent "Hello World!" at 300 baud every 5 seconds. It also drive two LEDS on the C port pins. The LEDs which alternate during a 1-second startup. When transmitting, the second LED would light up. 

My serial test project worked perfectly. LED 2 flashed for about 1/2 second every five seconds, just as expected. So, why didn't the beverage controller project work?

I modified the beverage controller project to also send "Hello World!" every 5 seconds. Except it didn't work. I traced the wiring in the controller head. RA5 was connected to the MAX232E pin 11. It was the MAX232E that was driving the pin to 4.5 V. With the MAX232E out of the circuit, RA5 stayed at 0 V all the time. It was like the software had configured RA5 as an input, not an output.

I got to the point that I could test both projects on the solder less breadboard. I even programmed the same chip with the serial test project -- and it worked. Programmed the same chip with the beverage controller project -- and it didn't. This was definitely a programming problem.

I tried several modifications of the configuration, eventually applying the serial test project configurations to the beverage controller project. At some point, it started working. I still don't understand what I changed to make it work.

Putting It Together

Remote relay box

After such a struggle, I was happy to finish. I re-programmed the chips to send and receive at 9600 baud. This is plenty fast enough for this purpose.

The controller supports one Kenwood/Elecraft-style command, which takes two forms - a Get and a Set operation:

• Get - &AR; -- responds with &ARn; where n is 1 through 5
• Set - &ARn; where n is 1 through 5 -- selects the antenna specified by n, responds with &ARn;

With the serial port transmit working, I could remotely interrogate the controller to determine which receiving antenna was currently selected. And selecting an antenna would respond to ensure that the controller had received my command.

The controller mounts nicely on the equipment shelf. I used some temporary stick-on labels until I find my computerized label-maker. 

What's Next

The current firmware sends an &ARn; response when a button is tapped. I probably need to make that configurable with a serial command.

I've also thought about adding a scanning feature. The controller could automatically switch antennas after a few seconds. Holding a button could add/remove that antenna from the scan.

However, after a couple of months of using the controller, I've found a glaring deficiency in my design. The Rx Antenna Controller only selects one antenna for the RX ANT port. I use a broadband splitter to also connect to the AUX port for diversity reception. But this only permits diversity reception of one receiving antenna against the transmit antenna. I can't do diversity reception between two receiving antennas. 

What would be nice is to have the remote relay box select the antenna for the RX ANT and AUX port. This would require twice as many relays and a way to control them individually. Doing this requires a re-design of both the remote relay box and the controller box. 

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. 

Beverage(s)

View 175 feet down NW Beverage.

My initial experience with the 2024 ARRL 160m contest demonstrated a serious noise issue on Ward Mountain. The Inverted-L showed an S4 noise level. I needed low-noise receiving antennas.

I'd had some success with the half-size K9AY loops at the Gwinnett station. But I could use something better.

At contest stations such as NQ4I or WW4LL, I've had the opportunity to use Beverage antennas. But  never at my home station.  I planned to change that. 

The Plan

Having a bit of acreage, there's room for several beverages.The key directions were to the NorthEast (NE), SouthEast (SE) and NorthWest (NW). 

For 160m Beverages, many recommend at least 550 feet of wire, minimum. This is just a bit over one wavelength long. ( Technically, using a velocity factor of 95%, one wavelength of wire should be 520 feet at 1.8 MHz ) Since they don't make spools of 550 or 520 feet of wire, a 500 foot spool should be sufficient. 

Wire is expensive. A 500 foot spool of stranded 14 gauge THHN wire is $78 at Home Depot. 

Beverage antennas are pretty simple. The long piece of wire is fed against ground at both ends. The near end uses a matching transformer to adapt the nominal 500 ohm impedance of the Beverage to a feedline. The far end contains a terminating resistor. 

Beverage terminators (above) and
transformers with F-connectors (below)

Terminator Boxes

I built five Beverage terminator boxes using a 470 ohm 2W resistor (OY474KE Ceramic composition resistor) and a 75v gas discharge tube.

These parts fit snugly in a small plastic box. Thumbscrews make for easy connection to the antenna and ground rod.

Transformer Boxes

500:75 ohm transformer

Beverage transformers are wound on BN-73-202 cores. Primary is 3 turns using red wire-wrap wire. Secondary is 8 turns yellow wire-wrap wire. The primary and secondary are separated using cut off bits of plastic stirring straws. The 3:8 turns ratio is a good match for 75 ohm coaxial cable used to feed the antenna. 

Transformer assembly progression

Transformers are housed in the same small plastic boxes. An F connector jack supplies the transformer primary. Transformer secondary connects to thumbscrew posts with another 75 V gas discharge tube across them. There is no common ground connection between the primary and secondary -- this avoids noise pickup from the feedline. 

Thumbscrews connect to the antenna and ground rod at the feed point.

I built four transformers initially. The small plastic boxes work necessitated a bit of ingenuity to get everything in place. 

Erecting

Single wrap traps wire

Installed insulator

Being surrounded by forest, the Beverages are suspended from trees aligned with the reception path. Screw-in electric fence insulators are used to support the antenna about 8 feet off the ground. 

A rope around a tree supplies modest tension for the wire at each end. This leaves the ends relaxed to connect to the transformer or terminator boxes and ground rods. 

The technique for installing the beverages is straightforward, I start by locating the feed point transformer near a supporting tree and mounting an insulator there. Once the ground rod and tension rope are installed, it's a matter of going from tree to tree installing insulators and hooking the wire. This continues until you reach the end of the wire, where the ground rod, terminator box and tension rope are located. 

Terminator installed

Tension connection

At the transformer and terminator, the wire to the ground rod zig-zags a bit to take up the slack from the insulator. This keeps the plastic box from flapping around in the wind.

Every attempt is made to keep the Beverage straight toward the target heading. A bit of direction change to make supporting trees is tolerable. I used the iPhone Compass app to keep me on heading. 

At my location, the terrain slopes a bit. For the NW beverage, after the first 175 feet, the drop-off is quite gradual. 

The NE beverage is another story. Terrain drops about 10 feet in the first 200 feet, but the last 300 feet drops about 80 feet. The beverage terminator ended up in the bottom of a deep ravine. Navigating the slope was quite difficult. Rocks, branches and other debris on the forest floor made for tricky footing. Be careful out there.

Feed Line

I caught a deal on some RG-6. I found 700 feet on a spool for less than $20 at the Dalton, GA hamfest. RG-6 is cheaper than stranded wire. A 500 foot spool is $50 at Home Depot. This 75-ohm coax makes for a good receive antenna feedline. It's cheap, low-loss and easy to match.

Performance

Only have a little experience with these antennas. NE Beverage has been up a month, and the NW Beverage a week. 

Performance is amazing. 

On the 160m Inverted-L, there's typically S4-5 noise. Noise level on the Beverage antennas varies depending on the time of night, but is typically 1-2 S-units lower. 

More importantly, signal levels are stronger. If I watch the Elecraft P3 panadapter, switching from the Inverted-L to one of the Beverages, the noise level drops somewhat, but the signals rise above even more. Sometimes, when there are no visible signals on the Inverted-L, many are Q5 copy on a Beverage.

Further, switching from one Beverage to the other can have a dramatic effect on signals. Sometimes, signals that are strong on one are inaudible on another. Other times, signals are about the same.

In short, the Beverage receive much better than the Inverted-L. During the recent Stew Perry TBDC, I listened on the Beverages almost exclusively. 

They work.

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....

Bell & Howell IMD-202-2 (Heathkit IM-1212 In Disguise)

Bell & Howell IMD-202-2 in place at workbench.

When my Systron-Donner digital multimeter was damaged by lightning in June of 1992, I looked for a replacement. Somewhere along the line, I found a Bell & Howell IMD-202-2 at a hamfest. This was at least twenty years ago -- I have a email message from January 2005 asking about it.

Somewhere along the line, this meter refused to measure anything. When I moved it to Ward Mountain, it was time to fix it. 

The sticker of the multimeter says "Heathkit IMD-202-2", but it's not a Heathkit number. In twenty years, there's apparently more information available. I found that it's a Heathkit IM-1212 with a Bell & Howell label. They sold this unit in the late 1970s as part of an electronics instruction course.

While I couldn't find an assembly manual, I did find a schematic and a calibration procedure. The unit is a simple and straightforward design. Opening it up, there's a single circuit board, plus a bit of wiring around the function and range switches. 

Stepping through the calibration procedure, I couldn't find anything amiss. I had difficulty using a frequency counter to set the counter oscillator. Even with an oscilloscope, I couldn't find a clear signal to measure -- yet the unit was working. I decided to use the calibration without a frequency counter.

When performing the DC and AC voltage calibration, I backed up these measurements using a modern portable digital multimeter. In the twenty years or so since I obtained the Bell & Howell, I've purchased four of these gems. 

The calibration went smoothly, and the Bell & Howell now has an honored place on my workbench. 

Measuring 1k resistor.

Compared to modern instruments, it's not impressive. It sports 2 1/2 digits -- the first digit is just a neon lamp that signals a leading "1". A second neon lamp lights a "OVER" indicator. By comparison, my modern portable digital multimeters have 3 1/2 digits, and at least one of them is auto-ranging. Accuracy isn't great -- perhaps 2% when freshly calibrated.

Still, it's sufficient to be tied to the workbench. The problem with the modern portable digital multimeters is the "portable" part. I leave them all over, and can't find one when I need it. Plus, the nixie tubes are cool.

At least until I can fix the Systron-Donner, which is a much nicer instrument. I have full manuals for the Systron-Donner. Last I looked, it had a problem with fried comparator using a LM301AH with matched FET input amplifiers. Yes, that's a TO-8 style integrated circuit, something you haven't really seen since the early 1970s. And the matched FETs are in a common plastic case with six leads -- a rather uncommon part. I intend to remove the damaged parts and install new parts with socket pins. 

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.

W5WVO 6m Beam Project

W5WVO clone construction so far.

I wrote earlier on my purchase at the Dalton, GA Hamfest of the 6m Mystery Beam. It clearly formed some kind of antenna, given the lengths of the elements. But I had no clue how those elements were intended to be positioned on the boom -- and even if I did, I had no idea what kind of performance to expect.

Course of Action

Unsure of what to do, I asked the folks on he SEDXC mail reflector. Joe Subich, W4TV suggested that I use the components to implement the W5WVO modification of the A50-5S, or perhaps re-create one of YU7EF's five element designs for a 4.5m boom or 4.15m boom. 

Choosing between these options was difficult. What I had wasn't a A50-5S, so the W5WVO medication wasn't straightforward. And the YU7EF designed were even further afield from my starting point.

I decided to adapt my tubing collection to W5WVO's design. 

My elements were too short, they'd need to be extended. But, it isn't as simple as just matching the length W5WVO specified -- the taper schedule is different. 

The A50-5S and the W5WVO designs use 48" of 3/4" tubing in the center extended with 5/8" tubing to the element length. My tubing is 3/4" the entire way. I'd need 5/8" extensions, but how long?

Answering that question required modeling.

Modeling a Solution

As a Mac user, I use CocoaNEC with the NEC 2 engine. It's pretty sophisticated, actually, but getting good results requires using the NC modeling language, which can be a bit tedious. 

My first model was W5WVO's design using the normal taper schedule - inner 24" of each half element are 3/4" with the rest being 5/8". Results were very similar to, but not exactly the same as W5WVO's article. (Part of the reason is W5WVO used NEC 4 engine) But what I had was close enough.

Second model used the 3/4" element lengths I had, spaced according to the W5WVO design. The results were akin to the W5WVO, but with significantly worse F/B.

Third model used the same 3/4" element lengths, with 5/8" extensions on the tips of each element. Because of the different taper schedule, I experimented using a different percentage of the W5WVO dimensions. Lo and behold, at 80% extension length, I modeled something very, very close to the W5WVO design. 

Reflector with
5/8" extension.

The extensions needed on each end are short:

• Reflector - 2.5"
• Driven Element - 0.75"
• Director 1 - 1.75"
• Director 2 - 1.375"
• Director 3 - 0.25"

I added about 3/4" for overlap inside the 3/4" tubing. I secured the extensions using 1/8" Cherry pulled rivets. These aren't ordinary "pop" rivets. Ordinary pop rivets are just a hollow aluminum tube. These leave a steel mandrel filling the tube -- a solid, structural connection.

Building

Extensions on each element.

First step involved cutting the extensions and riveting to each element. I used two rivets on opposite sides. On the D3 element, with the very smallest of extensions, I ended up with one rivet because I broke my #30 drill bit. 

Second step would be to hang the elements on a boom. Oh, wait, I need a boom!

The parts I bought at the Hamfest had three segments of 1" Aluminum pipe which was reinforced by a 13 foot piece 3/4" pipe. None of this fit well together. And the diameter was somewhat small for a 20 foot boom.

I had a 7 foot piece of 1-1/2" tubing I replaced on a Cushcraft A3S. I also had a 12 foot piece of 1-1/2" tubing. Together, they would be 19 feet. The last 10" of the 7 foot tubing had a crack, so I cut that part off, and used a  1 foot 1-5/8" tubing section to join the two together. My only hesitation was that the 12 foot piece was only 0.035" wall (whereas the others are 0.058"). I was worried it might not be strong enough. I figured it was worth a try, perhaps aided by a supporting truss.

I also had to figure out a boom-to-mast plate. I was fortunate to have one in the junk box, along with U-bolts that would work.

Mapping the elements onto the boom was a little tricky. The U-bolts just barely fit over the 1-1/2" boom, but they could not go over the 1-5/8" joiner. I had to move the reflector 8" away from the end of the boom so that Director 2 did not fall on the joiner. 

I managed to get all the elements positioned on the boom. Definitely looks like an antenna now.

Next step will be to figure out how to feed this beast with a gamma match.

Hamfest Special - Mystery 6m Beam

Back in July 2021, I asked members of the SEDXC reflector how best to work Europeans on 6m, one important bit of advice was to use an antenna with more gain than my Cushcraft A50-3S. Three elements just won't cut it on marginal paths. The suggestion was to use a beam with five or more elements. 

Such antennas are several hundred dollars new. The A50-3S was used from a local club for $80. Yes, I'm cheap, but it has served me well. Since then, I've been looking for a reasonable, used antenna. I'm even willing to do some minor repairs.

As I was leaving the Dalton, GA hamfest at the end of February, I stopped by a tailgate area where a guy had a trailer load of stuff. I could see a Cushcraft tribander, a Hy-Gain tribander, house brackets, guy brackets, feed lines, a gin pole and other stuff. I wondered if he might have something for 6m. So I asked.

The owner wasn't present, so his kid called him on a digital walkie-talkie. He said he had a 5-element Cushcraft 6m beam. By the time he made it back to the trailer, we pulled it out, and he changed his tune, he said it was a 6-element Hy-Gain beam. You could see the gamma feed on the driven element. 

Sounded great to me. I negotiated him down to 63% of his asking price, and walked away with the antenna bundle for $125. Sweet.

Getting home, before  I took the antenna off the truck, I went looking for Hy-Gain six-element 6m antennas. I found manuals for models 66B and VB-66DX. They are very similar. The VB-66DX appears to be a hardware-update of the 66B design. These antennas are also fed with a beta-match, not a gamma-match. What I bought is not a Hy-Gain antenna.

Taking the antenna off the truck, cutting it apart and laying the pieces out on the deck.What I found was surprising:

• 

  The components I purchased
  

  REF - 3/4" Al - 9' 9" - 117"
• DE - 3/4" Al - 9' 2" - 110" (Gamma match)
• D1 - 3/4" Al - 8' 9" - 105"
• D2 - 3/4" Al - 8' 8" - 104"
• D3 - 3/4" Al - 8' 7" - 103"
• Misc - 1/2" Al - 50" - Swaged to 5/8" last 6" (2) - Hy-Gain bracket adds 1 1/2" - 101 1/2" total
• Boom - 1 1/4" Al totalling 24 feet in three sections with 1" thicker wall inner tubing

First five elements mount with a single 1 3/4" U-bolt and saddle in the center. The Misc segments could mount in a single Hy-Gain bracket, giving a total element length of 101 1/2" -- which might be a forth director.

Gamma match is a total of 16" 1/2", most of which is a 1/4" Aluminum rod. The shorting bar is at 14 1/2". The first 1 1/2" is a 1/2" Al tube flattened at one end for a screw. The open end hid a disc ceramic capacitor that sadly I broke in transit. Looks like a 3-6 kV capacitor, value unknown.

The boom is a piece of work. There are three 1" Al pipe sections: 75 3/4", 144", 68". The 68" section has a 156" piece of 3/4"Al pipe with a ticker wall as reinforcement. It is mounted asymmetrically, so more of the end extends into the 144" piece than the 75 3/4" piece. There is no boom to mast bracket.

I'll note that the boom is aluminum pipe. Not tubing. It's designed to carry liquids, not be structural.

Clearly, this is not the parts to a Hy-Gain nor a Cushcraft 6m beam. First off, no commercial 6m beam ships with single-tubing size elements. They all use a taper schedule. There are two good reasons for this. 1) It makes the antenna adjustable. 2) they can ship sections shorter than 7 feet, which allows the package to go UPS, 

These parts are a collection different ideas. The U-bolt mounting is Cushcraft-style, but the boom size is too small for a Cushcraft. The boom is 24 feet long, but it is clearly not a Hy-Gain. The boom is way too small, since Hy-Gain used a 2" boom. Plus, it apparently had a truss (now broken), probably because the    for the 24 foot length.

What I appear to have is a collection of parts used to cobble together a poor imitation of something like the Hy-Gain 66B / VB-66DX. Not at all what the guy at the hamfest told me.

There's plenty here to put together a solid five element beam on a 12 to 18 foot boom. The elements are already cut. The hard question is how far should they be spaced? Once I know what the right spacing is, I would then know how much boom I need. 

The broken gamma match is annoying, but fixable. Once I know where to place the elements....

This project is going to take some work.

The Challenge of a New QTH

A decade ago, my wife and I spent four years in Floyd County in one of her church postings. We loved the area, and imagined we'd retire there.

In November we took the first step. Bought a house in Floyd County near Rome, GA. House is on the top of a small mountain - Ward Mountain, rising 300 feet above the valley floor below. From the front porch, there is a gorgeous view to the West. On a clear day we can see 35 miles to Lavender Mountain, which is practically in Alabama,

The house is a little smaller than we'd like at 2100 square feet, but there's over 11 acres of land. A small office outbuilding with one room and a tiny bathroom has become the ham shack.

We've owned the house in Gwinnett county for 30 years. Now we are transferring things to the new house. There's a lot to do. We'll sell the Gwinnett house in the next months. In the meantime, I'm focused on building up the Floyd QTH when I have the energy.

Antennas are the first order of business. I first put up an 80/40/20m Trap Dipole. It's up about 12m in the trees. I erected a 160m Inverted-L with two elevated radials. It's a bit noisy, so receiving antennas are likely needed to make the most of that. I plan for three beverage antennas. A 6m dipole barely 4m up in the trees offers me an option on that band.

I've also put together the HF4B. I've mounted it on a 19 foot pole lashed to a deck post. It needs adjustment to work well. It's OK on 10m, but 15 and 20m aren't quite right.

I'm planning to put up a tower. I'll need to take down the tower in Gwinnett first. My plan is 70 feet of Rohn 25, with the A3S/A743 on top. 35 feet below that will be an A3S, pointed at Europe. This would give me a stack toward Europe, plus coverage in other directions with the top antenna. Horizon is unobstructed in every direction except to the NorthEast, where the two additional summits of the Ward Mountain chain are. Those peaks are just 100 feet and 140 feet higher, but they are 1 km and 2 km away, respectively.

I'm already seeing good results with the 80/40/20m trap dipole. There are benefits to being on the top of a mountain. Even a simple tower should be awesome.

For 6m, I'm on the lookout for a 5-6 element beam. The Cushcraft A50-3S i've been using in Gwinnett just doesn't have enough gain to work the intercontinental paths. 

On the office building, I've already moved in an operating desk with desktop shelves, and another luncheon table that serves as a workbench. The main part of the floor is a little more than nine feet square, And almost six feet of the rest of the building is split between the tiny bathroom and the rest of the floor. The desk and workbench are a bit of a squeeze.

A wire shelving rack takes up some of the space opposite the tiny bathroom, and gives me room to store things. I don't know how I'm going to get a whole basement of ham gear into this little building.

Such is the challenge of a new QTH.

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.

Cycle 25 is Kicking Butt

Don't know why I didn't write about this when it happened.

August 9th, the daily Sunspot Number (SSN) was 382. That seemed enormously high. I couldn't remember a single time when the SSN was that high. So, I did some digging.

I downloaded all the SSN data, converted into an Excel spreadsheet and did some analysis. The SSN hasn't been that high since 1991. That's 33 years ago!

The SSN has only been this high a total of ten times in my lifetime (since February 1961) -- Five in 1979, Twice in 1989, and Three times in 1991. 

Of course, none of this compares with Cycle 19, where daily SSN values were well over 500 for many days. But those values all happened 1956-1959, well before I was born.

Cycle 25 is shaping up to be much better than Cycle 24, which was really lousy, and possibly better than Cycle 23.  The smoothed SSN has already exceeded the maximum value for Cycle 24, and it is far from over. 

We've already seen a huge change in the bands in the last couple of years. 20m is open 24 hours, and 15m much of that time. 12 and 10m is open every day. I'm hoping we might see some 6m F2 openings. Enjoy it while you can. We should have two more years of these conditions before the cycle starts back down.

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.