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…)

Retro Challenge 2018 Midpoint Update

Work has been busy and I haven’t had as much time (even on the weekends) as I had hoped to work on this. I did spent most of yesterday on it and made some significant progress.

The initial assembly language coding of the reverse scroll routine went pretty smoothly. While I find the 6809 assembly syntax a bit different than what I’m used to (on the 6502 and Z80 mainly), it is actually fairly powerful. With things like pre or post increment or decrement of the register you are using to hold the address when you load or store, what would be a few lines of code on the 8-bit 6502 becomes a single line on the “16-bit” 6809. (I use quotes because the 6809 has a 16 bit internal architecture but works with an 8 bit external bus. Some don’t consider it a true 16-bit processor. Personally, I think it is absolutely fair to call it a vintage 16-bit processor that tried to keep a degree of 8-bit compatability.)

But almost immediately the issues began…

Let me start by saying I’m running Ubuntu Linux and doing “cross-development” (where a lot of the work is done on a machine other than the target system) for all of the assembly code and portions of the BASIC code. It will turn out that which operating system you are using will be relevant. I am also using Drivewire so the “disk” is a file on the server.

I was using LWASM to assemble the code and it has a handy option to generate a BASIC file that includes data statements and a routine to poke the program into memory.

So my assembly code initially looked like this:

; Downward Scroll Routine
; by James McClanahan W4JBM
; Rev 1.0 for Retro Challenge, April 2018
;***** Define Constants
; starting addresses have "+2" to compensate for pre-decrement
; of the X and Y registers.
sfrom  equ $5de+2 ; where do we start copying from?
sto    equ $5fe+2 ; where do we start copying to?
done   equ $400   ; where do we stop copying?
       org 16000
;***** Start of Program
;***** Load Constants into X and Y
start: LDX #sfrom
       LDY #sto
;*** Main Loop (copies from address in X to address in Y)
loop:  LDD ,--X
       STD ,--Y
       CMPX #done
       BHI loop

That is pretty straight forward with it starting at the top of video memory (or the bottom of the screen), loading a 16 bit word, then moving it down 32 bytes. We auto decrement the X and Y registers by 2 (the two negative signs) prior to the load and store and do a simple address to find if we’ve reached the top of the screen.

Like I mentioned, LWASM has a nice feature to create the object code and put it into a basic program. So we assemble it using this:

lwasm -f basic -o scroll.bas scroll.asm

And, in this case, the scroll.bas file looks like this:

20 IF A=-1 THEN 70
30 FOR C = A TO B
60 GOTO 10
70 END
80 DATA 16000,16016,142,5,224,16,142,6,0,236,131,237,163,140,4,0,34,247,57,-1,-1

NOTE: If you want to play with this yourself, you will need to start the program with something like:

5 CLEAR 10,15999

This will protect the memory at 16,000 and above for our machine language routines.

Anyway, the logical next step is getting this simple BASIC program onto the CoCo itself.

I have also installed MAME and eventually want to do emulation for troubleshooting and debugging, but haven’t made it to that point yet. But MAME also includes a utility call imgtool which lets you create a disk image file, store files to it, retrieve files from it, and do a number of other cool things.

I created a test disk and it worked fine. I added some files and it seemed to be working to an extent, but I was getting error messages and not able to read the files on the CoCo even when I could see them in the directory.

In theory, I can create a blank disk image using this command:

imgtool create coco_jvc_rsdos test.dsk

I was able to use imgtool’s “dir” option or open this with Drivewire and things seemed good. So the next step was to add my BASIC program. It is in ASCII format, so I need to do this:

imgtool put coco_jvc_rsdos test.dsk scroll.bas SCROLL.BAS -ascii=ascii -ftype=basic

This should take the scroll.bas file on the Linux box and put it into the disk image file as SCROLL.BAS as an ASCII BASIC file–except every time I would get the error message:

scroll.bas: Bad file name

I could load test.dsk using Drivewire. With some combinations I could even get SCROLL.BAS on the image, but it was in ASCII format (without the ASCII flag) and the CoCo was expecting a tokenized file, so on the CoCo I would get the expected.


I tried different combinations of flags and options. Since the message was “bad file name” that led to a lot of searching for things that had nothing to do with what ultimately turned out to be the real problem.

I’ll save you the painful details, but eventually I figured out that the issue was the end-of-line marker in the BASIC file.

This is one of those things that seems simple, but is different on different systems. In ASCII, a carriage return (or CR) is character number 13 and a line feed (or LF) is character number 10.

With normal ASCII text files, DOS and Windows uses a CR+LF at the end of a line. Linux and later Apple systems just use just a LF character. Older Apple systems used just a CR character. (I think the only combination not used is LF+CR, but it wouldn’t surprise me to find some system, some where even uses that.)

There is a utility call unix2dos that will convert the LF’s to CR+LF’s. So all I ended up having to do to make things work was take the BASIC file from LWASM and do the conversion:

unix2dos scroll.bas

It took me about two hours to figure that out.

With that moved over, I started coding a basic race track game. I use the command:

EXEC 16000

to do a “downward scroll”.

With a simple working framework, I found more issues…

I was poking 3 lines of 4 characters onto the bottom of the screen as the car. With the scroll, there was very noticeable and distracting flicker. I ended up having to rewrite most of the scroll routine. Now it goes character by character (instead of pairs of characters) and only “scrolls” characters that do not have the high bit (bit 7). (Bit 7 is zero for most normal characters. It is the semigraphics that has Bit 7 set. Loading them from the screen also sets the N bit in the condition code when Bit 7 of the character is set because they could be a negative number if you were using two’s-complement math.)

This helped, but there was still some flicker as the car moved side to side. To overcome this, I wrote an assembly language routine to draw the car. Now I just have to do a single poke (to let the routine know where on the bottom of the screen to place the car) and call it with an EXEC command to have it quickly draw the car.

But in that process, I found yet another issue. I wrote the second routine in assembler and had the output in BASIC. By now I had figured out how to get and put ASCII BASIC files on the image file. I added the new DATA statements using a more powerful editor (Geany) and it didn’t work…

It would draw the first two lines of the car, but not the third. Again, I struggled for a bit. Eventually I broke the DATA statements into several smaller lines. I think (but have not verified) that there must be a line length limitation on ASCII BASIC lines. The line would probably have worked fine if it was line 70 or 80, but because I needed to make it something like 470 or 480, I think the end of the DATA statement was being truncated as I pulled it in.

As an aside, the old laptop I am using to do the development and as the Drivewire server has decided that certain keys should no longer work. I don’t have E or I or about a half dozen other characters. Unfortunately some of those are used in the system password. I did have a USB keyboard setting around and things work fine with it connected.

With that done, I now have the downward scrolling working, the car drawn, and the ability to move the car left or right using the keyboard. Here is a screen from the JS Mocha online emulator by Brad Grier:


Horizontal movement of the car is limited, so you can’t “crash” into the sides. I will be adding obstacles (probably just simple characters such as “X”). There will also be some element of “speeding up” as the game progresses.

This is different than the original Foo Raceway. That original program had a track that would move from side to side and vary in width. That would not be that hard to implement, but the original also used the 32 character display mode of the Ohio Scientific (OSI) C4P-MF and the character graphic car was only 1 character wide and two characters high.

On the CoCo, the car is much bigger as related to the track: four characters wide and three characters high. So for the OSI, the car width was something like 3% of the track width while on the CoCo the car is something like 13% of the track width. Too much weaving or narrowing of the track would make the game unplayable.

A few other things…

The code runs on both my CoCo 3 and the CoCo 2 emulator, so it seems reasonably portable. That was one of my unwritten goals. (I do have a CoCo 1 that I might try it on at some point.)

Also this week a very special package arrived. Several years ago Briel Computers offered what they called the Superboard III. This was a “clone” of the OSI Superboard II. That was the computer I first had decided to buy back in the summer of 1980. With my parents helping out, I was able to get the OSI C1P instead which included 8K of memory (as compared to the Superboard’s 4K), a case, and a power supply.

I was not particularly active in the retro computing community at the time and I did not hear about the Superboard III until about a year after they had sold out. They were available built for around $250 or as a kit for $200. I have tried to buy one several times over the past few years. They either had already sold or the seller was asking (and usually eventually receiving) a significantly higher price than they originally sold for.

I had decided that if I could one day get one for a somewhat reasonable price I would be happy. I happened to look on eBay for some components one evening and came across a Superboard III that had been listed a few hours earlier for $250 plus shipping.

Several people were already watching it, so I immediately snapped it up. I was out of town all week so I couldn’t pick it up from the post office until Friday. Unboxing it and firing it up for the first time brought back memories of buying the C1P almost 38 years ago now.

If thing had been a bit different, I would probably be doing Foo Raceway on it… but for now I’m setting it to the side and working to finish up Foo Raceway and the Retro Challenge!

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…)