Tuesday, February 28, 2023

Forty Years of Personal Computing - MC6809

The bare board that held the HB 6809 V1 circuitry. 
Waiting for the next SS-50 project.
In computings early days, advancements happened quickly. Which mean purchases went out of date quickly. I built my SWTPc 6800 Computer System in November of 1977. In 1978, Motorola introduced the MC6809 processor, and by March 1979, SWTPc had the MP-09 CPU board available.


For those who programmed the MC6800, the MC6809 fixed many problems. It sports 16-bit arithmetic operations, more index registers, many additional addressing modes and a very orthogonal instruction set. It was a powerhouse of an 8-bit processor. Early chips were costly, and the marketplace moved quickly beyond 8-bit chips to 16-bit ones. The MC6809 never became popular enough to dominate the market. For that brief time in the late 70s, it was the most powerful 8-bit processor. I wanted one.

Georgia Tech Symposium

In early 1983, Georgia Tech hosted a symposium where Terry Ritter, one of the designers of the MC6809 spoke. I attended, and the room was packed. Ritter talked about the design decisions that went into the architecture of the MC6809, about the importance of reusable software and position-independent code. Their design lead to the creation of BASIC09 and OS-9.

At the time, I wasn't much interested in any variety of BASIC, so I didn't pay much attention to OS-9. I should have.

The last of Ritter's talk was about an unannounced product, termed the General Motors Custom Microprocessor (GMCM). It built on the foundations of the MC6800. At that time, GM was using the MC6802 in their vehicles. The GMCM added some features to the MC6800, such as 16-bit arithmetic, an extra index register and both multiply and divide instructions. (Divide was something that the MC6809 did not have) But the GMCM lacked all the complex, orthogonal addressing modes of the MC6809. The next year, Motorola introduced the MC68HC11.


SWTPc offered the MC6809 with the MP-09 board. The MP-09 draws from the design of the MC6800-based MP-A2 board. Both have four 2716-compatable sockets that can hold 2 KB ROM, PROM or EPROMs. While the primary difference is the CPU, there are other differences:
  • SS-50 bus changes for the 6809 processor
  • NMI and RESET switch connections relocated to a CPU board connector, which frees up two bus lines for BUSY and M.RDY, respectively
  • ROM socket at address F800
  • ROM/RAM sockets at address E000, E800, and F000
  • No on-board RAM. (the MP-A and MP-A2 had 128 bytes of RAM)
  • 16 bytes of writable memory at address FFFx that translate the top 4 bits of address
This last feature is known as the Dynamic Address Translator or DAT. The DAT uses a fast 16x4 bit RAM - the 74LS189 chip. It sits between the top 4 address lines A12-A15 of the CPU and the physical bus. Thus it translates address values in 4KB blocks. It is the reason the MP-09 has no on-board RAM. The ROM monitor SBUG-E, on reset, scans addresses to determine which 4 KB blocks have RAM. It then writes the DAT to position those 4 KB blocks as desired. The first block is relocated at D000-DFFF, and the second block at C000-CFFF. These two blocks are used for the stack, and any operating system such as Flex09. The rest of the memory blocks are arranged from address 0000 upward.

The board has a socket for an additional 74LS189 chip for the DAT, which adds the four higher-order bits to the DAT RAM. This extends the address bus with four more lines (S0-S3) allowing the MC6809 to address 1 MB of memory. The S0-S3 lines take the place of the bit rate signals on the SS-50 bus, so these signals have to be supplied elsewhere for the SS-30 bus. SWTPc did this with their MP-MB motherboards, a component of the SWTPc S/09 systems.

The MP-09 board runs on the original MP-B/B2 motherboards with modifications. More on these later. 

During my years in college, I eagerly wanted to upgrade my computer to the MC6809. I obtained a copy of the SBUG-E source code and studied it. By April of 1981, I modified SBUG-E, removing code for features I didn't need and adding some features of my own. I called my monitor BBUG. I used a cross-assembler on the Pr1me minicomputers to build my code. But I could not run BBUG without hardware.

MC6809E V1

My last months at Georgia Tech, I took a required course that involved building a working microprocessor system. It had to have ROM, RAM and I/O. Many of my colleagues used the computing laboratory that provided prototyping plugboards and components for their circuits.

This was a challenging course for many computer science majors. It was their first experience with digital logic. And the prototyping plugboards had been used and re-used so many times that their connections were not always reliable. This made it difficult to determine if problems were programming bugs, wiring errors, or just flakiness in the hardware.

I didn't relish dealing with flaky prototyping boards. I had fulfilled many of the requirements of this class when I built the SWTPc 6800 system in 1977! This seemed an opportunity to create my own MC6809 processor board.

I had read  articles about the MP-09, and had copies of the schematics, which I studied in-depth. There were  electronic parts stores and friends around Atlanta where I could obtain components. It seemed right.

MC6809 V1 Design

April 1983, I drew up schematics. My design borrowed from the MP-09, and included the DAT, but there were several differences.

I did not include an MC14411 bit rate generator or crystal. I intend to use extended physical memory right away. I moved the bit rate generator and crystal to a card plugged into the SS-30 bus. There were no bit rates on my SS-50 bus, only S0-S3 address lines.

Instead of the MC6809 chip, I opted to use the MC6809E. The MC6809 has a built-in clock oscillator and bus control logic. The MC6809E requires an external oscillator as well as a few chips to handle bus control for things like DMA. In trade, it has an LIC (Last Instruction Cycle) and AVMA (Advance VMA) pins. I made use of AVMA in my design.

Instead of four 2716-compatible 2KB sockets, I only had two. A ROM at Address F800, and ROM or RAM at address F000. Having ROM or RAM at E800 or E800 didn't make sense to me, since those addresses conflicted with the I/O ports used by SBUG-E. (In October 1986, I would revise this board to use a single 2732-compatible 4KB chip, covering F000-FFFF)

The memory map for this design was pretty straightforward:
  • 0000-EFFF - accessing off the CPU board to the SS-50 bus
  • F000-F7FF - ROM/RAM socket #1
  • F800-FFFF reads - ROM socket #2
  • FFF0-FFFF writes - DAT RAM
I had no option switches or jumpers in this design. It was exactly how I wanted.

Dynamic RAM Design

The same month, I drew diagrams for dynamic RAM boards. One was a 64 KB board using  4116 chips. Another design provided 256 KB memory using 4164 chips. I intended to add one of these boards to my project. The 4116 design was complicated, with multiple voltages involved. The 4164 design was simpler, but the chips were more expensive. I never build either design.

MC6809E V1 Building

Although I had made some simple PC boards, creating one for the MC6809 design was outside my skill set. Plus, it would have been expensive for my student budget. I had constructed a seven-chip CMOS keyer in 1979 using point-to-point wiring. That was difficult. I built a duplicate keyer for my brother in 1980 using wire-wrap construction. Wire-wrap was a heck of a lot easier. Plus, I already had the tools. A friend supplied wire-wrap wire and sockets and I was in business.

Wiring a design this complex directly from the schematic worried me. Wiring mistakes were easy to make, and hard to track down. Then a classmate asked to join my project. Denise Messerschmidt worked with me in the Users Assistance office at the Computer Center, and she didn't want to have to fuss with the flaky prototype boards either. She asked if she could help, and I figured should could do the wiring of the hardware. This required good instructions.

I solved that problem with a bit of software. I used the LL(1) parser generator written by fellow student Roy Mongiovi and defined a 28 production computer "language" that described the chips and devices and the wiring between them. Given a well-described design, my program produced three lists as output.

The device list showed each device and all of the signals connected to each pin. A device was either a chip or a plug. Chips listed two pins to a line, just as it would appear on a DIP device. Plugs listed one pin to a line. The device list made it easy to verify the design was correctly programmed in the language.

A cross-reference list related the signals connected to each device. Another cross-reference list showed the signals by each device and pin. One would follow this final list to do the wiring. The Wire Wrap parser was about 2500 lines of Pascal code, and it worked beautifully.

The board used 0.1" perf-board, cut to 8 1/2" by 5" -- a little smaller than standard SWTPc boards. Molex connectors epoxied on the edge connected to the SS-50 bus. I installed the wire wrap sockets, and wired up the voltage regulator and the SS-50 pins,  plus a handful of discrete components. That took care of everything that required soldering. After training Denise in wire-wrap technique, I gave her the board, wire, tools and the wiring list.

About two weeks later, she came back with the finished product. Every wire had to be manually stripped and wrapped. Denise had done an excellent job - better than I would have. 

MP-B Modifications

The MP-B motherboard required modification to work with my 6809 CPU board. The I/O ports on the MP-B decode as eight, four byte ports starting at address 8000. The SBUG-E (and hence BBUG) monitor expects eight, sixteen byte ports starting at address E000.

The modifications aren't difficult:
  • Connect SS-50 A2 and A3 to SS-30 UD3 and UD4, respectively
  • Move the ABC inputs in U3 from SS-50 A2, A3 and A4 to A4, A5 and A6, respectively
  • Cut the trace on U3 pin 5 (Enable*) and connect to SS-50 A9
  • U5 has an unused NOR gate, connect the inputs to SS-50 A10 and A11, and the output to U3 pin 6 (Enable)
  • Move the U6 pin 4 (Enable*) from SS-50 bus A6 to A12
  • Move the U6 decode output on pin 4 (4*) to pin 7 (7*) this signal goes to U3 pin 3 (Enable*) and  U5 pin 13 (Enable* for data bus drivers)
Modifications on underside of
MP-B. The brown wires on the 
right go to the 74LS21.
To support extended addressing using S0-S3, the traces between the SS-50 bus to the SS30 bus for the bit rate lines 110, 150, 300, 600 and 1200 must be cut. 

I added extended address decoding for the I/O ports. I mounted a 74LS21 4-input AND gate on a daughter board, and connected the inputs to S0-S3, the output goes to U6 pin 6 (Enable).

With these modifications in place, the I/O ports show up in memory as eight, sixteen byte ports, from physical address FE000 to FE1FF. The ports show up in memory four times in sequence, because address lines A7 and A8 are not decoded. 

Bit Rate Generator

Bit Rate Generator Board
Since I used the extended addressing lines S0-S3 on the SS-50 bus, the bit rate signals must be provided on the SS-30 bus. 

For this, I built a simple card that had just four components: MC14411, LM341-5 regulator, 1.8432 MHz crystal and a capacitor. You can see them lined up on the left side of the board. The MC14411 is the original device from the MP-A CPU board with a date code of 7718 - the 18th week of 1977.

Later, I added the MC6840 timer chip and the SN74LS04. At some point, this board also held an Intel 8250 UART, which is the reason for the molex connector in the upper right. But those parts have been removed. There's certainly room for an MC6850 ACIA or other I/O device on this board.

Bit rates are configured as follows:
  • 110 = 38400 baud
  • 150 = 2400 baud
  • 300 = 300 baud
  • 600 = 9600 baud
  • 1200 = 1200 baud
This represents a good collection of rates across a wide range. As configured other rates are available on the MC14411 from 300 to 115200 baud.

MC6809E V1 Debugging

The beautifully wrapped board Denise wired didn't work.

When I built the SWTPc 6800 Computer System, it didn't work the first time, either. I borrowed an oscilloscope and figured out the issues. For the SWTPc 6800 boards, the problem was nearly all solder bridges. But those boards started with a working design. Mine was untested.

I had access to test equipment on campus, but I couldn't take any of it with me. I had to bring the whole computer and terminal into one of the computer center labs in the evenings, when the labs weren't in use. An oscilloscope wasn't enough. I was introduced to a new device, an HP logic analyzer -- although it took me a while to figure it out. Those evening sessions in the lab were very productive.

Dragging my computer and terminal in and out of he lab each day, I isolated six different wiring errors on the board. Had Denise let me down? No, the wiring errors were all in the original wiring listing! Denise had done her job to perfection -- she wired it exactly as specified. 

Once the wiring errors were fixed, the debugging process went smoother. I also had to correct some defects in BBUG. At one point, I had all 24 channels of the HP logic analyzer engaged. 16 pins went to the address bus, and the other 8 to the data bus. This way, I could watch each memory cycle of the MC6809 and determine what was happening.  

Eventually, I fixed the issues and had the system running. I received an "A" for the course. Denise, because of her limited involvement, received a "B", but we were both happy.

End of an Era

In 1988, I built another MC6809 CPU board. It replaced the V1 board, and once working, I stripped the V1 board down for parts. All that is left is a board with edge connectors and a voltage regulator, which you see at the beginning of the article.

Sunday, February 26, 2023

Moving the A50-3S Closer to Home

A3S/A743 on tower, A50-3S nearby.
Nearly five years ago, I mounted a Cushcraft A50-3S out in the yard. I figured this would work for a few months until I found a more permanent solution. This lasted way longer than I expected.

It was a good move. I worked 48 states, plus 39 countries using that antenna, despite feeding it with 120 feet of RG-8X which likely adds 3 dB loss.

In July 2021, I asked the SEDXC email reflector for advice on how to work Europeans on 6m. I heard others working them, and even heard a few myself. For the most part, however, I could not hear them, or I couldn't get them to hear me.

The first piece of advice was to get a better feed line. RG-8X is not a good choice for VHF, especially with over 100 feet. The second bit was to mount the A50-3S a little higher. It's taken me a year and a half to get there. I've finally taken the first step.

The first question: where to put the antenna? The mount in the yard used a mast concreted into the ground that originally supported a Cushcraft R7000. I considered moving it to my 50 foot tower below the Cushcraft A3S/A743. The option allowed for easy rotation, and would have been convenient. However, with antennas in close proximity at five feet away, I believed there would be too much destructive interaction. I needed a mount point further away.

View of installation.
Without room for additional towers, I opted to mount a mast against the house, about 30 feet away from the tower. This location is close to where coaxial cables exit the house, which meant a shorter feed line. An older but serviceable piece of 9913 had sufficient length, so the feed line problem was solved.

How to mount a mast to the house took a bit of figuring. I used a small 6" wall mount on the eave of the house, just below the gutter. This gives the mast enough distance to clear the gutter. The bottom of the mast sits in a pole mount on the railing of the deck blow. The mast is the same 19 feet using two 10 foot pieces of rigid EMT I used to mount the antenna in the yard. 

Erecting the antenna was a little bit of a challenge. I used a rope and pulley hooked on the wall mount to raise the mast into position, then lifted the mast up on the railing. The weight of the rigid EMT made this harder. 

Reflector askew
In the process, the reflector of the antenna brushed up against the roof, which knocked it out of alignment. It doesn't affect the operation of the antenna terribly much, but I will fix it eventually.

The mast bracket is not cinched on the mast, to allow for rotation. Jam nuts are used to keep the bracket U-bolt from loosening.

The result has the antenna around 27 feet (8m) high, next to the house, fed with about 50 feet of 9913. This should be a substantially better than out in the yard.

I plan to replace the mast with some aluminum tubing, as well as adding a rotator, which should put the antenna a couple of feet higher. That will also give me an opportunity to straighten out the reflector alignment. 

In the meantime, I'm ready for this year's Es season in plenty of time.

Monday, February 6, 2023

Nine-Band Worked All States

Nearly twelve years ago, I wrote about completing Worked All States on six bands. I'd worked all states on 160, 80, 40, 20, 15 and 10m. About three years ago, I finished up 30m, so now it was seven bands. However, finishing 17 and 12m seemed like it would take forever. I felt stalled out.

A couple of months ago, it occurred to me that I was only four band-states away from Ten-Band Worked All States. I needed Delaware on 17m, Kentucky on 12m, and Alaska and Hawaii on 6m. 

The 6m states would have to wait -- I'd need very special conditions to work either state. But with the recent rise in sunspots, working those close-in states on 17 and 12m seemed do-able. The biggest problem would be operating the Gwinnett station. That was solved after I configured the RemoteRig devices to allow remote operation

Indeed, the first afternoon operating remotely, I was able to work Kentucky on 12m and the LoTW confirmation came the next day. Finishing off 17m took a month longer.

It was surprising to me how calling CQ DEL AA4LR EM83 would gather so many responses from people who were not in Delaware. I worked at least one station in Delaware, but the LoTW confirmation was not forthcoming. Then the RemoteRig Control device no longer powered up.

I got lucky one Friday afternoon when I was in Gwinnett county and managed to get a legitimate answer to my CQ DEL message and a confirmation later that day. I'd done it. Worked All States on Nine Bands. 

Now, I just have to wait for those special conditions in order to work Alaska and Hawaii on 6m....

Monday, January 30, 2023

Remote Operation - Level 1 (RemoteRig RRC-1258MkII)

RemoteRig RRC-1258MkII at Radio

Last spring, I wrote about using RealVNC to remote control a computer in my shack allowing me to make FT8 contacts on 6m. I have made many contacts using that remote system, including several new countries and grids.

I want to be able to operate the Gwinnett county station remotely -- on any mode or band, as if I were sitting there. Doing this required several connections over the internet, and, being behind on other software projects, it seemed a daunting one. 

A company called Microbit (www.remoterig.com) has a solution. The RRC-1258MkII is a pair of devices that establish multiple audio, serial and control links over the internet. One unit sits with the Radio, the other is called the Control. They are similar boxes, with subtle differences: the Control box as a CW speed knob, but the Radio box does not. These units work with a number of radios, including the Elecraft K3. 

One operating mode is K3 Twin. In this mode, the Control K3 acts as a front-end to the remote Radio K3. All the knobs and buttons operate the remote radio. Indeed, Elecraft made special, stripped down, non-RF versions of the K3 for this purpose (K3/0, later the K3/0-mini).

This seemed perfect, as I owned two K3 radios. Obtaining the RRC-1258MkII was more difficult. Microbit is based in Sweden. Due to the pandemic and subsequent supply chain issues, they no longer sold them in the USA. I had to find them used. 

I managed to find Kirby, VE6IV, who had a set surplus to his needs, and we agreed on a price. Then ensued a much longer negotiation on how to get the funds to Kirby in Canada. Eventually, we figured it out, and a week later, the devices were delivered.


Configuration was not plug-and-play, by any means. These boxes are designed to connect to 10/100BaseT networks. I found an old router and set up a local network to do the initial configuration. First step was to update the firmware. This did not work over the network, and I had to use the USB connection. After a few tries, I successfully updated both units to the latest firmware. 

The local web server in each box allows configuration of the other parameters. There are dozens of settings, and the manual leaves a bit to be desired explaining all the details. 

First order of business was the IP configuration. I opted to define a static IP addresses on my local network. for the Radio, for the Control. You can use DHCP for the Control, but it is easier to change configuration settings when you know the address. 

The Radio device needs to be accessible from the public internet. Since I don't have a static public IP address, I opted to use dynamic DNS. RemoteRig supplies such a service, at ddns.remoterig.com. They automatically set up a host address based on your serial number. 

I set the web site username and password, as well as the SIP password. Audio was set for 16 bits and 8 kHz dual channel. The COM ports were set with COM1 inactive, COM2 in logical parallel with COM0, and COM3 inactive. 


Next step was to integrate the Radio unit into the Gwinnett station. I still needed to use the station locally. I found that I could connect the local computer through the COM1 port on the Radio unit and still be able to run WSJT-X locally. One caveat - the RemoteRig devices don't pass through the DTR and RTS signals, so you can't do CW keying from the serial port. You also can't update K3 firmware. Both of these require direct connection of the computer to the rig.

The manual shows the Radio unit connected with seven different cables, but only six of them are described in the manual. The seventh cable connects from the I/O port on the back of RemoteRig to the ACC jack on the K3. The Radio unit turns the K3 off when you disconnect remotely. Without this seventh cable, you cannot turn the K3 on when you connect. That took some experimentation to figure out.

Initial Connection

Puzzling out the rest of the operation was easier on the local network. I programmed my Control unit to connect directly to the Radio unit's local IP address. Initially, I couldn't get anything to work. I would have brief periods where the Control unit would connect. I could hear the audio of the radio, and then it would disconnect. Nothing was happening with the Control K3.

Part of the problem is my Control K3 had been upgraded to a KIO3B, so it did not have an RS-232 jack. Generally, I used the USB port. The KIO3B has an RJ-45 jack labelled RS-232/P3, and I had a cable designed to plug into the P3. I used that cable, but it didn't work. I decided I needed a special cable from Elecraft, part #E980297, an RJ-45 to DE-9S. 

The new cable didn't work either, and that lead to more sleuthing. I tried using the K3 Utility on this cable, and it didn't work either. I then discovered that the CONFIG:RS-232 menu had to be set to 38400 b for the serial connection to work. That was part of the problem.

A bit more checking and I determined that the RemoteRig COM2 jack required a null modem cable between it and the K3. I had that, and it required a male/male DB-9 adapter. Both these items were in the batch of cables that Kirby shipped me. 

With CONFIG:RS-232 and the correct cabling, the Control unit placed the Control K3 into TERM mode. I successfully connected locally. 

Remote Connection

Connecting through the dynamic DNS address was the next step. I figured I had to change the SIP Contact parameter on the Control unit. That was correct, but it would not connect. Then I thought perhaps it didn't work because I was trying to connect on the same IP address on the public network. So, I packed up the K3 and the Control unit and took them back to Warren county. But, it didn't work there, either.

This was frustrating. Then it occurred to me that perhaps I had to re-program the firewall of my Gwinnett county router to let certain traffic pass. I lamented that those experiments would have to wait until I could pack it all up and go back to Gwinnett county to fix. Then it dawned on me that I could use the RealVNC connection to my shack computer to re-program the firewall remotely.

Programming the router was not simple. I used the IP Allocation mode of Default Server to direct all incoming traffic to the Radio unit IP address. That worked! I was able to connect and control the station.

This configuration worried me. RemoteRig uses four UDP ports, plus TCP port 80 for the web server configuration and port 23 for telnet configuration. Having those TCP ports open on the public internet seemed like a bad idea. A single password protected access, which seemed to invite hacking.

Instead, I wanted to pass the traffic on the four UDP ports and block everything else. This was accomplished by setting up four custom "gaming" services for each UDP port. I then assigned these services to the RemoteRig Radio IP address. Bingo.


Operation is pretty straightforward, even though the RemoteRig manual isn't. To activate the system, you simply turn the Control K3 on. Within 20-30 seconds, the devices connect across the Internet, the remote K3 is turned on and the Control K3 goes into TERM mode, and audio starts streaming into the Control unit. All of the knobs, buttons and indicators on the Control K3 operate the remote K3. 

When you are finished, you turn the Control K3 off, and the remote K3 also turns off. If you happen to lose your internet connection, the remote K3 turns off in about a minute. 

During my experiments, I was able to confirm operation of WSJT-X using the remote shack computer. I've also been able to transmit CW, using the paddle check on the Control unit. So far, though, I haven't figured out how to transmit voice signals. Most likely, I have another cable or configuration problem. 


The system has a few rough spots. The audio volume is controlled from the Control K3 volume control. Certain operations stop the audio stream -- switching into or out of SUB receiver mode, or into or out of DIVersity reception. Moving the volume control brings the audio stream back. 

In my set up, the audio occasionally has small drop-outs, perhaps when a UDP packet fails to arrive in time. For this reason, I would not recommend using RTTY across the audio connection. One can operate a remote computer to run RTTY, just as I do for FT8. There may be a configuration option to help this.

Next Steps

While I can operate my Gwinnett K3 remotely now, I need to automate other parts of the station. I cannot change antennas, rotate rotators or switch the K9AY direction. I'm working on solving those problems.

Update: Sad News

Unfortunately, about two weeks after I started writing this article, my Control unit fails to power up. I apply power, but the PWR LED does not come on. I've tried with two different power supplies, no luck. RemoteRig support indicates this could be a failure of the CPU. Sadly, they don't offer repairs in the USA, and will have no replacement units available until May, 2023. 

In the meantime, I'm back to Remote Operation - Level 0.

Forty Years of Personal Computing - BBUG


In the early 1980s, I was excited about the MC6809 processor. I wanted one. But my student budget couldn't afford it. I studied all material about the MC6809 I could get my hands on.

In 1981, I obtained the source code to SBUG-E, the SWTPc ROM monitor for the MP-09 board. I was familiar with the source code to the MC6800 ROM monitors MIKBUG and SWTBUG. SBUG-E demonstrated the elegance of the MC6809 processor.

As I understood SBUG-E, I wasn't satisfied with it. I began to modify the source to suit my own purpose.  I called this resulting monitor BBUG. 

I worked on BBUG for a couple of years, off and on. My earliest printout is from April 1981. I wrote code using a cross-assembler and pour over the listings. I hunted for ways to make BBUG compact, as it had to fit in a 2 KB ROM. But the code never ran until I built the Homebrew MC6809 CPU board in mid-1983. (Which is another story)

BBUG's command structure is similar to SBUG-E, as is a lot of the code. Here are the differences.

Commands Removed

I removed several commands from SBUG-E. My plan for an MC6809 computer had floppy disks, so the cassette tape operations were the first to go. The DMAF1/2 8" disk system seemed incredibly expensive, so I removed that boot command, and used the D command character for an SS-30 floppy disk controller boot. Finally, the stack memory dump didn't seem useful to me, so I pulled it, too.

In summary:

  • D - no DMAF1/DMAF2 boot - no DMAFx 8" disk controller
  • L - no cassette tape operation
  • P - no cassette tape operation 
  • S - stack memory dump didn't seem useful
  • U - changed this command to D, see below

Commands Added

I added a couple of new commands for BBUG. The first was a memory fill command. SWTBUG had this as well. I also added a help command.
  • F start-end byte - Fill Memory from start to end address with given byte value
  • Z - Help - prints a summary of commands

Other Changes / Refactorings

Other parts of SBUG-E were re-written and improved:
  • Q - I spent some time in college investigating memory test methods. I re-wrote this test to use a modulo 255 memory convergence test with nine total passes. This is a fast test that detects most kinds of memory errors.
  • U - Changed this command to D and completely re-wrote as an improved boot from an SS-30 Floppy Disk Controller. Major changes include:
    • Performs up to sixteen tries, allowing recovery from soft errors.
    • Alternates single and double density between tries, so it can boot from double-density disks.
    • Works with FD1771 and WD2797 controller chips
    • Works with 5 1/4" and 8" versions of controller board (more on this later)
  • Command code positioned in alphabetical order in source. This made no difference in the space requirements or efficiency of the monitor, but it made it much easier to find the commands I was working on.
  • Alter register commands refactored to use less space.
The last iteration of BBUG v1.91 fits in a 2 KB EPROM with 1 byte to spare. 

4 KB Version

In October 1986, I experimented with expanding BBUG to fit a 4 KB ROM. This version has a test string at address F000, and the rest of BBUG at address F800. You can see this version at the bottom left in the picture above. 

The test was successful, and this left space for more commands. At that point, however, I was more interested in OS-9, and had less use for BBUG.

Future Changes

If I make any future modifications to BBUG, the first thing I'd do is a fix a bug. The extended memory initialization assumes that the E-block is at physical address FE000, so it writes F1 into that block. That's not compatible with the current Homebrew MC6809 V2 board (which is another story), where the value should be 01 instead. This would also match the value written by OS-9 Level 1. 

There's also 2 KB of additional space for more commands. Extended memory functions would be welcome. A command to catalog all the extended memory blocks would be useful, as well as running memory tests on extended memory blocks. That would be a start. And I might bring back the stack memory dump command.

Monday, December 26, 2022

Forty Years of Personal Computing - Code Practice Program

In the spring of 1980, as my first year at Georgia Tech was coming to a close, my parents were coming to pick me up and take me home to West Virginia in June. My brother Ben suggested during the trip, we could take the FCC exams for Amateur Extra class. At the time, we were both General class, and all exams were administered at official FCC offices, such as Atlanta.

I wondered how I might practice for these exams. Although I was a member of the Georgia Tech club station W4AQL, getting access was a hassle. I hadn't been on the air since I'd come back to Tech in January. I was afraid I had forgotten Morse code entirely. My solution was to write a code practice program for my SWTPc 6800 Computer System, using the Kreepie Peepie

The program is small, just over 200 bytes long. It creates a five character code group by choosing characters randomly. Then it sends the group, complete with a word space. A check of the serial port determines if someone has input a character, indicating a request to stop. If not, it continues to generate and send the next five character group.

The characters themselves are sounded out by toggling a bit on the Kreepie Peepie. A wait loop of roughly a millisecond is used. This gave a pitch of about 1 kHz. The wait cycles are repeated a sufficient number of times to sound out the element (BAUDV). Silent periods used the same timing element, without toggling the Kreepie Peepie. This made it easy to adjust speed by changing the BAUDV location. I had this programmed to 64, which came out right about 20 wpm.

I'd typically run the program for a few minutes, copying as many of the five character groups as I could. It was enough. I passed the FCC 20 wpm exam.

Thursday, December 8, 2022

Upgrading the KK1L Antenna Switch Load Resistors

My KK1L board, showing the old resistors on the
board, and the new ones on the desk.
While testing the KK1L Antenna Switch after mounting to the Single Point Ground (SPG), I noticed that some of the load resistors were no longer 50 ohms.

These resistors provide a load impedance whenever a antenna jack is not selected by either port A or Port B.  This protects the antenna from static build-up as well as dissipating any coupled RF energy.

I originally used 50 ohm, 1/2 watt resistors I had on hand. Clearly they were not up to the task. On the ports for the shunt-fed tower, and the 80/40/20m trap dipole, these resistors were completely open. Both showed signs of overheating. 

Most likely, these resistors succumbed to dissipating too much couple RF energy. I needed bigger ones. KK1L had 50 ohm, 50 watt resistors in his Mouser parts list, so that's what I ordered. These sorts of things come in handy, so I bought ten. Due to supply chain issues, they were back-ordered for months. But they finally arrived.

Replacing these parts is a pain. First, I had to remove the KK1L box from the SPG panel. Next, I had to remove the board from the aluminum box. Before I did that, I made sure to mark the locations the mounting screws for each resistor. To remove the board, I had to unsolder the eight connections to the SO-239 center conductors and bend them out of the way. Then came twenty-some nuts holding the board in place. 

With the board separated from the box, I drilled the holes for the resistor mounting screws. I used a numbered drill bit the same size as the hole in the board to give me the largest tolerance. With the holes drilled and de-burred, my attention turned to the board.

Board with new resistors
Next step was to remove the existing resistors. Where they connect to the relays was easy, but the connections to the ground plane were harder. The ground plane tended to carry the heat away, making it hard to melt the solder without damaging the board. Getting these holes cleared of solder took a lot of effort. 

Once done, the new resistors mount cleanly on the underside of the board. I oriented the resistors so the ceramic patch was toward the aluminum box. This patch does not appear electrically conductive. 

After the resistors are soldered, the process is reversed to re-install the board in the aluminum box. In addition to the existing twenty-some nuts, there are also six new #4 screws and nuts to mount the resistors securely. With that in place, re-soldering the eight connections to the SO-239 center conductors completes the job. 

I mounted the KK1L box to the SPG, and then re-tested all the switching combinations. This was to ensure I had connected the switching lines correctly.

I hope the new resistors are up to the job. I'll have to check on them in a few months to make sure.