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="")
print("")

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.

kolaSeqPy

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?

 

Thanks,
Jim W4JBM

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

 

Advertisements

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];
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);' */

void
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:

KolaSeqC

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…

73,
Jim W4JBM

“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:

1,2,2,1,1,2,1,2,2,1,2,2,1,1,2,1,1,2,2,1,…

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:

1,2,2,1,…

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:

1,2,2,1,1,2,…

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

10 REM CALCULATE KOLAKOSKI SEQUENCE
20 REM
30 REM BY JAMES MCCLANAHAN, W4JBM
40 REM ORIGINAL VERSION MAY 2018
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%
260 PRINT:PRINT
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.)

series

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.

73,
Jim W4JBM

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

frace

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

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
       RTS
end:

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:

10 READ A,B
20 IF A=-1 THEN 70
30 FOR C = A TO B
40 READ D:POKE C,D
50 NEXT C
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.

?FM ERROR

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:

foorace_sample

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

The 2018 Retro Challenge… It begins!

My first computer was an Ohio Scientific C1P that I bought the summer before my senior year in high school. I spent months figuring out what to buy.

SWTP had a 6800 system that I liked but that was much more expensive than I could afford. I liked everything related to Heathkit but, again, it was out of my price range. So was the Commodore PET line of computers and the VIC 20 (which was just coming out) didn’t do much for me. Radio Shack had the TRS-80, but it seemed like a premium price for a rather average system. The 1802-based systems were interesting and scaled from low-cost starter boards up to full systems, but you rarely came across programs or information about them in the popular microcomputer magazines.

All things considered, the Ohio Scientific (OSI) Superboard II looked like the best deal. It came without a case or a power supply. While 4K of memory seems limited today, with the built-in BASIC ROM I thought it would be adequate and it could easily be expanded to 8K. It offered upper and lower case—something that seemed important to me at the time even though the screen size was limited to 25 characters of 25 lines. You could use your own TV as a display and it interfaced with a standard cassette player.

I saved my money and, not being comfortable driving around town at that point, my mom drove me to the local dealer in Tulsa when the big day came. My parents must have had some idea that computers were going to be an important part of the future because they added to what I had saved and I ended up with an OSI C1P (which was a Superboard with a case, power supply, and 8K of memory) and a “video monitor” which was a converted television.

A year later as I was graduating high school, the C1P was traded in for a C4P MF. This gave me 24K of memory, a 5-1/4” floppy disk system, 64 characters per line and a color display, along with joysticks and a serial port. They also loaned me a Eaton printer that used a roll of paper maybe 3.5″ across for a few months.

As college started, I also ended up going to work for the local dealer, Gauger & Associates, as a “jack of all trades” including hardware repair, sales, and helping remodel the new building they were moving into. On the side at first and later in college as a full time job, I did a lot of free-lance programming of business systems including development of a complete system that included general ledger, payroll, accounts payable, accounts receivable, and job costing.

After college, a lot of what I did was on the IBM PC although I did make a stop with the Commodore 128 along the way. I started going to grad school at night working on my MBA and it was when I took a graduate level statistics class that I found I just couldn’t put off buying a MS-DOS based PC.

That was three decades ago now and over the last two years or so, my interest in vintage computers has peaked.

Sometimes we become fixated on things for reasons we don’t understand.

For me, that has been a program I wrote on the OSI C4P MF called Foo Raceway.

When I saw an announcement for the Retro Challenge, I knew that it was a chance to start trying to bring those old memories back to life.

Over the next month or so, you can (if you are interested) follow my progress on the project.

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