MLK Day… and a transistor radio

Today is the day we once a year take time to remember Dr. Martin Luther King, Jr.. There are others who can talk much better than I about the man and his accomplishments, but I did want to share something I came across.

I live in the Atlanta area and there is a tribute the MLK in the airport here. You’ll see one thing that caught my eye in one of the display cases below.


MLK was assassinated in 1968. I was about five years old at the time and I remember many people had portable transistor radios. My dad had a nice Motorola portable in a leather case and even I had a low-cost plastic import. In that way, MLK was like many other and had his RCA AM/FM radio.


I’ll admit I find myself wondering what station the radio is tuned to, but given how much he traveled it could be any number of stations in a variety of cities.

I took this photographs a few months ago and today seemed like an appropriate time to share them.

73 de,


A Novel Approach to Aligning the Wadley Loop

Recently someone asked about a good sweep generator to use in aligning a Yaesu FRG-7 receiver. The FRG-7 is a classic, making use of the Wadley Loop design for all-band coverage. The First Intermediate Frequency (1st IF) of the receiver does “up-converts” an entire 1 MHz span of the shortwave spectrum up to frequencies between 55.5 MHz and 54.5 MHz. (They are inverted in the conversion process–so if you are listening to WWV at 10 MHz, it would be up-converted to 55.5 MHz; if you tune up the band to 10.5 MHz, that signal would have been up-converted to 55.0 MHz.)

Alignment basically involves tweaking a set of capacitors and inductors so that the up-converted signals are “flat” across the 1 MHz band. One way you can tell if things are “flat” is to listen to WWV with the MHz dial set to 10 MHz (where that signal would be up-converted to 55.5 MHz) and then to set the MHz dial to 9 MHz and tune just past 9.999 MHz (where WWV will now be up-converted to 54.5 MHz).

In every vintage Wadley Loop receiver I’ve ever restored, there will be a noticeable difference in the s-meter between the two different ways to getting to a 10 MHz signal. But after an alignment that is properly carried out, the s-meter should show very similar signal strengths in both cases.

Today, a sweep generator isn’t as expensive or rare as it was on the workbench 10 or 15 years ago, but not many people can justify buying one if all they want to do is align a vintage Wadley Loop receiver.

Back in the days before I had one on the bench, I came up with an approach to align the 1st RF filter in an FRG-7 using a simple, low-cost noise source along with a receiver that covered the 54.5 MHz to 55.5 MHz band. Although I did the work on an FRG-7, the design of the Radio Shack Realistic DX-300/302 is very similar and I shared the approach in the RealisticDX group over at Yahoo!.

Subject: Wadley Loop
From: Jim W4JBM
Date: Dec 9, 2008

I don’t own a DX-300 or 302 anymore, but over the weekend I went through and
did a complete alignment of an FRG-7. I used a little different approach than
I had in the past, in particular adjusting the bandpass filter that is used
to generate the 2nd LO.

My basic idea was to use my Yaesu FT-857 receiver so I could “listen” for the
52.5 MHz signal as I peaked the bandpass filter. I originally planned to use
the harmonic generator as my signal source to do this.

One of the key advantages of the Wadley Loop is that by using the same
oscillator for the 1st and 2nd LOs, any drifts and changes cancel themselves

It was amazing to listen to the 2nd LO wander around a range of several dozen
kHz, yet have things remained relatively “peaked” on a signal. Actually,
when you “peak” the MHz control, what you’re doing is centering the 2nd LO in
a filter (that is suppose to be at 52.5 MHz). But as it’s approach or leaving
that peak, it might be 50 kHz or more on either side of that center value.

It just left me in awe that with an LO as unstable as the harmonic generator
can be that you can end up with a receiver as stable as the 302 (and the
FRG-7) have been in my experience. I’m sure the LO is a bit more stable when
the rig is buttoned up instead of open, but it made a believer out of me on
the robustness of the loop design.

Another thing I did that worked very well was use a broadband noise generator
to align the 1st IF filters. I fed the noise into the antenna port and used
the FT-857 in bandscope mode to see the up-converted noise. Then I could
adjust the bandpass filters for the right response (~54.5 to 55.5 MHz).

I’ve avoided doing DX-302 and FRG-7 alignments without having access to some
decent lab grade test gear until this attempt. But things seems spot-on and
I’m pretty happy.

73 de

“With a soldering iron in one hand, a schematic in the other, and a puzzled look on his face…”

Working the world from the New Dog Iron Ranch!

I thought I had done more of a write-up at the time. I know somewhere I have some screen shots from the bandscope of the FT-857 I was using. But, basically as I recall, I used a divide-by-10 probe off the oscilloscope connected to the antenna jack of the FT-857 to feed the signal from the FRG-7’s 1st IF in without loading it down.

The noise source was the traditional zener diode design with a pair of transistors providing some amplification.

Looking through the Yahoo! Group archives, I did find where I talked a bit more about the approach a few years later.

 Subject: DX-302 alignment probes
From: Jim W4JBM
Date: Oct 5, 2012


I’m kind of with Jim on that, I didn’t build anything fancy for any of
my alignments. I used a divide-by-10 probe on the frequency counter when
I used it. Most of the other measurements were made with an o’scope and
a divide-by-10 probe. I do have a “dummy antenna” that I use when I’m
aligning receivers designed for long-wire antennas, but I usually use 50
ohm signal sources otherwise.

And while I’ll agree with him that aligning the IF is not for the faint
of heart, if you don’t have a sweep generator but have a software
controlled receiver that can receive from (if I remember right) 54.5 to
55.5 MHz, there’s a summary back in the group message archive of how to
use a simple RF noise source while using the radio as what amounts to a
spectrum analyzer. I’ve used that approach on two Yaesu FRG-7s and one
DX-302 so far with good results. (I’ve also used the same basic approach
but with some differences in how the rigs work on the Allied SX-190 and
an AX-190.) It was very interesting to how far off the 1st IF was tuned
on all of them. It isn’t trivial to get it peaked even with the right
equipment but it did make a noticeable difference.

BTW, if you are wondering how far off your 1st IF alignment is, the best
way to make a quick estimate is to find a station slight below a MHz
mark. I used a signal generator at 12.995 or so for some of my testing.
For that frequency, dial up to 12.995 MHz and read the s-meter. Then
dial to 13.000 MHz and work your way down a few kHz. When you hit the
test signal, read the s-meter. If your 1st IF response is flat, both
s-meter reading should be roughly the same. I have yet to have a radio
come my way where they are anywhere close to the same… 🙂

For some listening, the fact that the same signal reads S9 when tuned
one way and S3 when tuned the other doesn’t matter much, but it is a
pretty obvious sign that something isn’t cricket.

One piece of advice–do all the other stuff you plan to do before you do
the alignment. Change out electrolytic caps, verify the power supply is
at spec, etc.. Nothing is worse than being an hour or two into an
alignment and getting flaky results only to find the regulated power
supply isn’t actually regulated. Then you get to fix the power supply
problem and start from scratch on the alignment.

73 de

“With a schematic in one hand, a soldering iron in the other, and a
puzzled look on his face…”

One of these days I’ll probably either do another alignment (although these days I can use my DG8SAQ Vector Network Analyser (VNWA) to do the job) or come across the screenshots I grabbed before.

Or maybe someone will find this useful enough to give it a try and provide a more detailed write up on how they went about things!

73 de

“With a schematic in one hand, a soldering iron in the other, and a
puzzled look on his face…”

Kolakoski yet again…

About a year ago I was working on a project that required cranking through files with millions of records. It was for a municipal area of about a quarter million households and typically having somewhere between one and six records per home. The records were in a text file in CSV (comma separated values) format and included positions for monthly information.

It was a huge data set to work with and tools like Excel just couldn’t handle it. (Unfortunately, Excel would typically chug along for ten or fifteen minutes with the computer being unresponsive before it informed you the file was too large to process.)

I had done something similar years ago and used sed (*nix’s string editor command) to help. I used the same approach this time to filter through the raw file, narrow it down to the records I was interested in, and then used a simple BASIC program to read the resulting file and crunch some of the numbers to give me the information I needed.

With a simple script (i.e., batch file), the computer churned through the data over the course of a day.

The output from BASIC was also in CSV format and I imported this into Excel for the final tweaks and presentation of the results.

Meanwhile, a colleague who is a real “data scientist” looked at the same data set from another perspective. He seemed to be able to crank out answers on the fly and I was impressed enough to ask how he was doing it. He said he was using Python. (What he didn’t mention is that he was using Python inside of Microsoft’s Azure cloud computing solution. So while I was limited by disk access time and processor power, he had no such issues.)

I had used Python a few times before. It is deceptively simple to get started with, but I found that when I tried to do something a step removed from the Hello World! example I tended to reach the point of needing to dig into the manual.

Recently I had taken the Kolakoski Sequence program I had written in BASIC and converted it to C using an on-line (and free) C compiler. That same site offered a Python compiler which caught my eye at the time.

So during lunch hour one day (literally), I converted the program to Python.

Calculate Kolakoski Sequence in Python
by James McClanahan, W4JBM

Original Version in BASIC written in May 2018.
Python version written in February 2019.

#initialize list with K sequence
#(easier to start at element 1 and waste element 0)

i =[0, 1, 2, 2]

# with Python, it turned out to be easier to initialize
# the first three elements of the sequence because while
# use an append() function to add to a list instead of
# using absolute indexing to place values in an array

n1 = 1
n2 = 2
p1 = 3

## my sense of symmetry likes that last set of constants...

while len(i) < 55:
     for x in range(0, i[p1]):
          i.append(n1) #add new decoded items to list

     ## for debugging or to watch the list build, uncomment
     ## the following print()
     ## print(i[1:len(i)])

     p1 = p1 +1
     n1, n2 = n2, n1 #swap n1 and n2

print("Kolakoski Sequence to %d digits:" % len(i))
for x in range (1, len(i)):
     print (i[x], end="")

Things like printing the sequence or swapping the values of two variables are simple and elegant. The program is amazingly short. (Without comments, it could be shorted to ten lines without much trouble.)

The only thing that took some getting used to was the fact that white space (specifically, indentation) is so significant to Python.

The use of lists instead of an array simplifies things greatly, but I can also see where the ambiguity of the type of data you are dealing with as you go through a list might get tricky.


With most programs in C, my brain has to do a bit of juggling before I fully understand what is going on. With Python things seem fairly self evident. Of course if you regularly program in one or the other, you would (hopefully) quickly gain a lot more familiarity with it.

At this point, I’m thinking C and Python are both valuable tools to have in my kit.

C is widely used in emulators for vintage computers and there are even modern C language tool chains for the 6502 and Z80.

I will probably make a focused effort to use Python as the replacement for a lot of simple “data crunching” programs I previously cranked out in BASIC.

While I was at it, I also cranked out a version in Fortran 95.

The code can all be found on Github. I still may try a version in 6502, 6809, or Z80 assembly at some point.

What other languages do you think might be interesting to code this for?



“With a schematic in one hand, a soldering iron in the other, and a puzzled look on his face…”


The Kolakoski Sequence revisited…

“If you can’t beat ’em, join ’em!”

Over the years I have tinkered with lots of programming languages: BASIC, various microprocessor flavors of assembly language, FORTRAN, COBOL, PASCAL, C, Forth, various minicomputer flavors of assembly language, Python…

I’ll admit I usually drift back to BASIC and assembly language.

But I’ll also admit there are a lot of times I wish I had a better grasp on C.

Around 25 years ago (1992 maybe), I started working with Small C in MS-DOS and eventually ended up with a version of Borland C. For fun, I tinkered with the source code for an MS-DOS directory program I happened across and created a color coded ls (or dir, as I recall the name went back and forth) program.

Since then I have done bits and pieces of tweaking, setting configuration parameters, or even some minor debugging of C programs.

J.B. Langston’s video card convinced me to give the RC2014 system a try and when he announced he had added C support I knew that I was going to have to give C another try.

I actually found a really nice online, browser-based C compiler that made it easy and convenient to dust off what little C skill I possess and begin working on improving them. Picking a random challenge for myself, I decided that re-creating the Kolakoski Sequence program I had written in BASIC in C would be a worthy start.

It took a bit of studying my own code to figure out the details of the approach I had used, but once I got started it was fairly easy (easier than I would have thought, actually) to get a version ported over to C:

Calculate the Kolakoski Sequence

by James McClanahan, W4JBM

Original Version in BASIC written in May 2018.

C version written in February 2019.


#include <stdio.h>

int main ()

/* i array holds the sequence; first two elements are initialized
p1 points into the array where we are now "getting" values
p2 points into the array where we are now "putting" values
n1 is the current "value" loading into the array
n2 is the other "value" and we "swap" them as needed
x is used as a temporary index in the for() loop

int i[60] = { 0, 1, 2 };
int n1 = 2, n2 = 1, p1 = 2, p2 = 2, x;

while (p2 < 57)
/* We start by expanding i[] with p2 as the pointer to the last
known value and p1 as the pointer to the last value processed
in the run length encoding. */

for (x = 1; x <= i[p1]; x++)
i[p2 + x - 1] = n1;

/* After the new values have been "decoded" from the run length
encoding, p2 is updated to the new end of the decoded portion
of the array and p1 is updated to point to the new 'last
location decoded' in the array. */

p2 = p2 + i[p1];

/* n1 is the value being loaded into the array and n2 is The
'other' value. We swap them before we go through the next round
of decoding. */

swap (&n1, &n2);

/* The while() loop continues as long as we have some array
space remaining. Since we don't know if the value last decoded
will be a 1 or 2, the array is just oversized to avoid having
to implement any additional truncation logic. */


/* Once we have reached "the end", print out the values in the
array. */

printf ("The Kolakoski sequence decoded to %d places is:\n", p2 - 1);
for (x = 1; x < p2; x++)
printf ("%d", i[x]);

printf ("\n");

return 0;

/* SWAP function is called by 'swap(&x , &y);' */

swap (int *a, int *b)
int t;

t = *b;
*b = *a;
*a = t;

I’ll admit that the swap() function gave me a few Segmentation Faults along the way, but eventually it worked. Overall, I highly recommend the OnlineGDB compiler as a way to get started. Here is the result:


It may not be elegant, but it works and I’m kind of proud of myself for being able to cobble it together with a few hours of reading and patience. If you are interested, the various ways of generating the Kolakoski Sequence can be found in my github repository.

While I’m at it, maybe I’ll dust of my Python tutorial next…


“With a schematic in one hand, a soldering iron in the other, and a puzzled look on his face…”

The Kolakoski Sequence in BASIC

To me, the argument about structure vs. unstructured programming languages and the general bashing of BASIC has missed an important element.

BASIC takes some of its approach from FORTRAN (which was short for FORmula TRANslator). One thing I have always enjoyed was trying to solve various math puzzles in BASIC. In the 1980s, BASIC was for fun and many business applications. You could also write a lot of games and puzzles in BASIC (as David Ahl proved). As for the early video games, a lot of the more advanced ones were likely to be written in assembly language.

Recently, the Kolakoski Sequence caught my imagination and I wanted to write a simple program to construct the series.

Details on the sequence can be found various places, but the simplified version paraphrased from Wikipedia is, “The Kolakoski sequence is an infinite sequence of symbols {1,2} that is its own run-length encoded value. It was initially named after the William Kolakoski (1944–97) who discussed it in 1965, but subsequent research has revealed that it first appeared in a paper by Rufus Oldenburger in 1939.

Run-length encoding simply means that the value represent how long or how many instances of a particular value lasts or exist in a series.

So let’s look at the start of the sequence:


Now for some simple run-length encoding, how many 1s in a row, how many 2s in a row, how many 1s (for a second time) in a row, and how many 2s (for a second time) in a row? That would be:


When we run-length encode the first six digits of the sequence, they yield the first four digits of the sequence.

We can “unencode” our four digit series by saying the first number represents how many times 1 is repeated, the second number represents how many times 2 is repeated, the third digit goes back to the number of times 1 is repeated, and the fourth digit goes back to how many time 2 is repeated. So our 1,2,2,1,… becomes:


Using this general approach we can write a simple program that will “unencode” or “expand” the series starting with nothing more than the first two digits. Below is a simple BASIC program (written for the Brandy BASIC interpreter, but fairly easy to port to any other vintage version of BASIC):

20 REM
50 REM
100 S%=50
110 DIM I%(S%+5)
120 I%(1)=1:I%(2)=2
130 N1%=2:N2%=1
140 P1%=2:P2%=2
150 FOR X%=1 TO I%(P1%)
160 I%(P2%+X%-1)=N1%
170 NEXT X%
180 PRINT P1%;" - ";
190 FOR X%=1 TO P1%
200 PRINT RIGHT$(STR$(I%(X%)),1);
210 NEXT X%
220 PRINT:PRINT P2%;" - ";
230 FOR X%=1 TO P2%
240 PRINT RIGHT$(STR$(I%(X%)),1);
250 NEXT X%
270 SWAP N1%,N2%
280 P2%=P2%+I%(P1%)
290 P1%=P1%+1
300 IF P2%<S% THEN GOTO 150
399 STOP

The value of 50 in line 100 shows how many digits maximum we want to calculate the series out to. (We may fall a few digits short and we may actually expand the sequence a few digits further. I’ve included simple logic to deal with that. I’ve also used some common string functions to format the sequence.)


At some point, I may take one of my older memory mapped video systems and use the display memory as the storage area for the sequence. But for now, I’ve accomplished basically (pun intended) what I set out to do: Demonstrate how the sequence can be calculated to an arbitrary length (limited, in our case, by computer memory or storage) given just the first two values of the sequence and the rules used to develop it.

Nothing fancy, but the kind of things you can spend an hour with BASIC playing around and learn a bit from. For me, it’s better than the crossword puzzle.


“With a schematic in one hand, a soldering iron in the other, and a puzzled look on his face…”



Retro Challenge April 2018 Semi-Final

I’m wrapping up this round of the Retro Challenge.

It is something of a mixed bag. I had a lot less time than I expected to spend working on it. I also ran into some things that took longer than expected. Overall, I would say I’m happy with where I was able to get to. I was able to:

  • I was able to get DriveWire4, LWASM, and the imgtool portion of MAME working on the Linux machine I set up for the purpose.
  • I learned a lot about the machine during my first real effort to write a program for the Tandy Color Computer.
  • I was able to get two different machine language routines written in my first real effort at 6809 assembly in decades. (I had some experience with the 6800 and had migrated some 6800 code to the 6809 decades ago, but that barely counts in the overall scheme of things.)
  • I developed a couple of scripts to simplify things like kicking off DriveWire, assembling and transferring machine language programs, and even editing BASIC programs for the CoCo under Geany.
  • I was able to get Foo Raceway (6809 version) to a reasonable state, even though there is more I want to do with it.

In the area of shortcomings, they are mainly features I planned to implement but have not:

  • Head-on collisions are handled okay, but if you side swipe an obstacle (e.g., move left when there is an obstacle to the left of the car) it currently goes undetected.
  • I am using the INKEY$ function for input and really wanted to do more with scanning the keyboard. (Something that was done in the original version of Foo Raceway.)
  • There is currently not “increasing difficulty” mechanism. More obstacles and faster play are things I’d like to add.
  • Also, a crash results in a fairly lame message and I would like to add some additional effects to that.

There were some unexpected detours (no pun intended) as I worked on Foo Raceway.

I had expected the “reverse scroll” routine to be the only machine language routine. In the end, I also had to add a second routine to draw the car itself to eliminate flicker.

One pleasant surprise was finding it worked on Brad Grier’s on-line Mocha CoCo 2 emulator. I actually thought about making the code more CoCo 3 specific (especially after finding some information about programming custom character sets), but in retrospect (pun intended) I’m glad what I have so far runs across all versions of the CoCo.


This is the raceway with the “obstacles” (the hash marks) that scroll downward towards the car. If you don’t get out of the way, you “crash”.


And I already see a bug–I should have ended the “PRINT@” statement with a semicolon because it apparently wiped out the track edge marker to the right.

All of the code and a disk image (that will let you play using the on-emulator if you want) can be found on GitHub.

One last observation: I am thinking it would be about as easy to code this in Assembly Language as it was in BASIC. On GitHub I’ve got code for a 6809 random number generator. There really isn’t a need for floating point math in anything I’m doing. And 6809 Assembly is fairly straight forward if you’ve used the 6502 much (and I’ve done A LOT of 6502 assembly work) or other common microprocessors (I’ve also done A LOT of Z80 work).

It was fun and I wish I had more time to spend on it, but doing this got me a long ways down the path towards becoming comfortable with the CoCo and a very powerful development tool chain to support it.

Thank you John Linville for the Challenge!

Picking a Retro Computer System

Thirty-some years ago, the reverse scroll code that I developed on the Ohio Scientific (OSI) C4P MF eventually served as the basis of a simple race track game. As discussed in earlier blog entries, recently I’ve had a desire to recreate that and Retro Challenge 2018 seemed to be the opportunity.

When the idea became an obsession a few months ago, the first question was, “What platform should I use?”

I wrote a partial version under Chipmunk BASIC on my laptop, but I had really wanted to get it going on a vintage system. At that point I had an Arduino-based Altair clone, a 1802 Membership Card, and a few other old systems setting around. In fact, my original C4P MF is in a box where it was packed when we moved from the Tulsa are to the Dallas area around 1993—I just haven’t had the time to really focus on getting it up and running again. (There is also a certain element of fear that I’ll find it isn’t going to run again for some unknown reason. So it sets in the box; sealed in like Schrodinger’s Cat in an indeterminate state.)

So what would be the best retro machine for me to use as a development platform?
Well, I came up with a “wish list” of features I wanted.

  • 80 column character mode preferred (64 minimum) with 24 lines supporting upper and lower case characters
  • Support for a joystick (I like digital ones, but can live with analog)
  • Memory mapped video (just because that is what I’m most comfortable with)
  • Sound output (something simple to program, but the truth is I’m not good at creating music anyway)
  • BASIC language and at least a primitive machine monitor
  • A matrix-read keyboard (again, because that is what I’m most comfortable with)
  • Some type of mass storage (I like the idea of SD card holding dsk images and server-based solutions like Drivewire are also interesting)
  • A real time clock (optional, but nice; and not necessarily a time-of-day clock)
  • A decent software library, good documentation, and an active user community
  • Some way to connect to a VGA or HTMI monitor (although it would certainly require adaptors; and I could live with composite or RGB output)
  • A decent “local” assembler, monitor, and debugger (and easy cross-platform development would also be a plus)
  • Some kind of “real” disk operating system (I’ve built a half dozen simple machines that need terminal programs to download and upload code—that has gotten old)
  • I’ll admit I like the 6502 but felt like the 6809 and Z80 were also good choices. (But that is just personal preference.) I have done significant development in both 6502 and Z80 assembly language. The 6809 seemed interesting with a lot of power but also some quirks.)

While emulators have their place, I wanted real vintage hardware. One example of where I’ve had trouble with emulation is trying to scan the keyboard for a game. With an Apple ][ emulator I was tinkering with at one point, you had unexpected latency in simple game play because the keyboard sends a character, then pauses until its repeat rate kicks in. FPGA is nice, but most use a PS-2 keyboard and have the same issue. (Of course something like a proper joystick implementation gives you a work around.)

The Commodore 128 was certainly a candidate. Sadly, I used to have one but gave it away when the power supply died and I was primarily using a PC anyway. I wish I had it back, but instead of buying another vintage Commodore 128, I’ve been thinking the Mega 65 clone of the never-made-it-to-market Commodore 65 was something I’d like to get when it becomes available. Investing in a C128 seemed like it might be redundant down the road.

After looking around, I leaned towards the Apple IIe and the Color Computer 3.

I actually almost bought the Apple. In fact, I thought I had bought one. But things shifted and the deal fell through. That kind of soured me on Apple in general.

While not the cheapest option, I found that Cloud 9 offers Tandy Color Computer 3s with the processor upgraded from the original 6809 to the 6309 and with a 512k memory expansion module installed.

I bought it and only had it a few weeks before the start of Retro Challenge 2018, but so far I’m very happy. It meets all the criteria I set and since the start of the Challenge I have been able to get a reasonable pass at a cross-development system running using LWASM, MAME’s disk imgtool, and Drivewire.

The first few hours of tinkering with 6809 assembly language involved flipping through various reference books, but it definitely is a powerful processor even if the assembly syntax is a bit quirky.

And so far it has served me well as my rewrite of Foo Raceway on the new platform has progressed. There is still lots to learn and I still need to pick up some additions (like a joy stick), but I’m happy with the choice I made.

DISCLAIMER: I’ll admit that after three decades, some of my memories of events may be a bit fuzzy or blurred together. Certain things I (think I) remember clearly, while others are kind of vague. I’ll do my best to stick to the facts and try not to ramble too much. (I know, it’s already too late for that…)