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

 

 

Advertisements

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

Measuring Capacitance

What value is that capacitor you are about to use?

Some may take a quick look at the markings. For example, the one I’m looking at is marked “.0022 +/- 1%”

But what is the real capacitance?

That is a fair question these days. I recently built a kit that came from China–the Yosoo PIXIE QRP transceiver. (Watch for an upcoming “builder’s guide” on Amazon! Step-by-step instructions that will remind you of the manuals that came from a certain company in Benton Harbor. But I digress…)

I am in the habit of testing the components I can when building a kit. It is much easier to find a bad diode before you install it than once the circuit is complete but not working like it should. When I measured the 470 pF capacitors in the PIXIE kit, they all measured closer to 220 pF. Were they mismarked which made them available at bargain prices? After all, someone who orders a few thousand capacitors for manufacturing is likely to notice something that far out of spec. On the other hand, the typical kit builder is fairly likely to read the markings and install them. Because the values for most components in the PIXIE are not that critical, the transceiver is likely to work with maybe a slightly degraded level of performance.

But that did get me thinking about how I measure capacitors. Until a few years ago, most of my measurements were made on a Heathkit IB-5281 LCR bridge. It was not necessarily the most accurate of devices, but I could get fairly close and results tended to be consistent and repeatable.

Then I worked on a project where I needed something faster and more accurate. I ended up buying the Almost All Digital Electronics (AADE) L/C IIB. This was a popular meter that is no longer available and mine has seen a lot of use in the last decade.

But looking at the bench, I also have a Yosoo GM328 component tester, a Radio Shack  220-0075 True RMS DMM, and a DG8SAQ VNA that can all measure capacitance. Recently I have been using the Yosoo GM328 more than the AADE L/C IIB because it can also test diodes, transistors, inductors, resistors, and more. I also knew that the Yosoo GM328 was fairly accurate from some testing I had previously done. (If you are interested, you might want to check out the eBook Using the Yosoo GM328: a guide for radio and electronics experimenters by James McClanahan available on Amazon.)

I measured the capacitor I mentioned with all four devices. The AADE L/C IIB read 2.155 nF, the RS DMM read 2.228 nF, the Yosoo GM328 read 2.22 nF, and the DG8SAQ VNA read 2.21 nF.

A note about the difference between accuracy and precision is in order. If I measure something that is around 3.0 and then take the reciprocal (1 divided by that number), I get 0.333333… But that never ending string of 3s is misleading because the underlying values used to calculate it are only known to two or three digits. Some lab grade gear can measure capacitance out to several figures, but for most hobbyist grade gear you are probably better off assuming only two or three digits are meaningful (even if more are displayed).

But that aside, we still have a range of 2.155 nF to 2.228 nF. Years ago I had access to a lab with some high-end test equipment and I happen to know that this particular capacitor is actually somewhere between 2.21 nF and 2.22 nF (with the exact measured value varying slightly with frequency).

For now, let’s assume a value of 2.1215 nF which is midway between the two measured values if we toss out the high and low values. (That is also pretty close to the real value as previously measured on lab gear.)

The AADE L/C IIB work by having an internal L/C oscillator that the unknown component is placed in parallel with. The additional inductance or capacitance causes the frequency of oscillation to shift and by measuring the two frequencies (before and after), you can calculate the component value. Accuracy is going to largely depend on how accurately you can measure frequency. In this case, we are reading about 2.7% low which is respectable.

I’m not sure how the Radio Shack meter measures capacitance, but I suspect it is using a simple R/C oscillator that does not have a capacitor. It is rock stable at zero when no capacitor is installed which would be expected since the oscillator would not be oscillating in that situation. It looks like it is reading about 0.59% high which is more than respectable for a meter where the capacitance function was likely thrown in more as an afterthought!

I go into details on how the Yosoo GM328 measures capacitance in the book I mentioned earlier, but we can do a quick recap. First it discharges the capacitor, then it does a quick charge. If that “maxs out” things (i.e., fully charges the capacitor) the device knows the capacitance has a “small” value. If it does not “max out” it knows it has a “large” value. (Large and small are relative here and I’m going to gloss over the details.)

Once that is done, a second set of tests performs the actual measurement.

For a large capacitance, the device will discharge the capacitor and then charge it through a known resistance until it passes the voltage threshold on a comparator. Knowing the charging current, reference voltage, and charging time, you can calculate the capacitance.

For small capacitance, the device will discharge the capacitor and then charge it for a known period through a known resistance. At the end of that period, the voltage across the capacitor is measured. Knowing the charging current, charging time, and the ending voltage, you can calculate the capacitance.

This capacitor would be measured using the Yosoo GM328’s “small capacitance” method and the reading is within one digit (it only measures to three digits) and 0.22%. For a device costing under $30, that is extremely good accuracy! (Getting better than one digit is tough and since it stops at three digits, we can’t know if it internally calculated 2.2149 nF and then rounded to 2.21 nF, so calculating accuracy at this point is, to be candid, somewhat meaningless.)

The DG8SAQ VNA can measure the the reflected power (kind of like a really fancy SWR meter) and calculate the capacitance from that. One interesting feature of the VNA is that you get to choose the frequency used to measure the capacitance. This is more useful in radio frequency (RF) applications than at lower frequencies, but is worth noting. The accuracy of the VNA is basically the same as that of the Yosoo GM328 (with the same caveats).

The AADE L/C IIB was something around $75 as a kit if I remember right. The Radio Shack True RMS meter cost about the same new (except I picked mine up on closeout for around $10).

That leads to an interesting situation… The Yosoo GM328 is around $30 and the DG8SAQ VNA costs around $650. So the least expensive and the most expensive devices were also the most accurate.

(BTW, both the Yosoo GM 328 and the DG8SAQ VNA uses an Atmel ATmega 328 processor. The VNA also has other processors and requires a PC to run, so it isn’t an exact matchup from that perspective. But it is still kind of interesting knowing what is at the heart of both of them…)

So I will probably put the AADE L/C IIB to the side for now and do most of my quick measurements using the Yosoo GM328. For things that are more frequency dependent or where I want to double check the value, I will probably use the DG8SAQ VNA. Don’t take that as meaning the AADE L/C IIB (or the Radio Shack DMM) isn’t an excellent instrument. But if you are just starting out, the Yosoo GM328 is low priced, flexible, and (at least in my case) fairly accurate.

73 de
Jim W4JBM

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

The Altair 8800: More Retro Computing

I’ve been working on a Z80 computer kit off and on for a while. I have to admit that soldering small parts onto tightly packed boards is less fun than when I was younger.

A few weeks ago I came across an Altair “clone” that was available:

Altair Clone

I was tempted, but I decided that I really needed to finish up the Z80 kit before investing that much in my next retro computer. Then I came across an kit that was bit lower priced that really caught my eye:

Arduino Altair Clone Kit

At the time the kit was sold out, but I ordered one as soon as they were available again. The kit arrived about a week later and I spent some time over two days of vacation building it.

Overall, I’m very impressed. If this looks like fun to you, then I’ll guess you would enjoy it and would not hesitate to recommend it.

You can load an SD card with up to 15 different disk images or choose from several preloaded ROMs that are on the system.

I’m still getting my feet wet on running it, but can offer a few thoughts that might help you if you build one.

The Arduino is attached to the main board using header strips. When I install header strips, I normally will just pull pins instead of breaking the strips into smaller ones. I’ve attached a picture of where I was able to do this on one side.

header

Pulling a pin just involves grasping the long end of the pin with needle nose pliers, touching a soldering iron to the short end for a few seconds, and the snagging the plastic part of the header under your fingernail and pulling. This approach makes it easier to keep the pins lined up.

There are two other sets of headers. One is a dual row header that is a single length of stock and the other uses an offset spacing for part of it to act as a “key” to ensure the board is correctly oriented.

There are two ribbon cables (one pre-installed on the Arduino) and the colors may not match the pictures in the build instructions, but the places they connect are well labeled and it is pretty obvious how they go. (You would have to work at it to mess this up.)

One interesting feature of this kit is that it offers a “serial port” connection from the USB port on the Arduino and a second serial port that can be built two different ways. (You choose your preference when ordering.)

The second serial port can either be an RS-232 port or it can be a Bluetooth device that will act as a serial device when connected. You can swap this second port to be the primary interface if you want. With the Bluetooth connection that means you could open a terminal emulator on your Android phone and play with the Altair.

I choose the Bluetooth option. I had some of the plastic from a project that had required removing it from a row of header pins once installed. I used two of these “blank” single pin plastic pieces as “spacers” at each end of the BlueTooth card after straightening the pins on the card.

bt1.jpg

This gave me a neat installation with some spacing without having to juggle things with my hands in the attempt.

bt2.jpg

The power supply connector is a fairly standard make with three lugs. That allows you to connect one lead from a battery to the third lug and have it disconnected when power is supplied by an external supply. (You don’t want to run a supply and batteries in parallel in most cases.) That doesn’t apply here, but the lug is still there and can just be ignored. The proper wiring is shown here:

batt.jpg

The supplied USB cable is stout and a bit short. I was worried it would pull over the Altair clone, so I used a lighter cable I had around. I also used a wire tie on this cable, tying it to one of the standoffs. This will keep any “tugging” on the cable from putting mechanical stress on the Arduino’s USB port.

usb.jpg

The computer comes with a wooden (some bamboo but also some pressed board with an imitation bamboo lamination) enclosure. I used the front panel as a template to drill the holes in the back, but still had trouble getting things lined up. I tried to install from the back first and then the front panel last, but that didn’t work well, So I used a trick I’ve found helpful before and took a pocket knife, put the blade through the holes from the inside, and twisted the knife a few time. One hole seemed to be a bit off so I gave it a few extra twists. This will create a bevel (or cone) on the inside. That, in turn, helps catch and guide the threads to and through the holes. I messed around with it for probably 15 or 20 minutes before trying this. After doing this, it went together on the first try and with no “wiggling” to try to get things lined up.

A few extra parts were included. This is a really nice touch that you won’t appreciate until you have trouble. For a first time builder who gets an LED or a transistor installed wrong, it is much easier to clip out the old one, pull the leads, clear the holes (something like a toothpick works great if you don’t have desoldering tools), and then install a new component. For someone without a lot of practice and without the right tools, trying to remove a component so that it can be reoriented and reused often leads to things like solder bridges and lifted traces. I’ve kitted a few different projects up over the years–it can be a pain and little things like this tend to show the person doing the kitting is more interested in you being successful building it than in saving a buck or two in parts.

The only other thing that was a bit of research was getting the Arduino drivers installed. You have to download a zip file, unzip it, and then point to the driver. (At least on Windows 7.) It wasn’t difficult, but it did require downloading a 120 meg file. Anyone who regularly plays with Arduinos is probably not going to have that issue.

Things worked fine on the initial test, but as I was finishing up I had an issue where when powered up the lights would all come on, but then they would go off and the HLDA light would flicker dimly. It happened with both the power supply and powering over the USB. I carefully looked at things, trying to figure out what might have changed. When I tested it after finding nothing with a close visual inspection, it worked again. I suspect I had a piece of lead that had ended up gumming up things someplace and that I knocked loose through later handling.

A couple of other hints…

Do a full format (not the “quick format”) of the SD card and place all the disk image files in the root directory.

Also, when clipping the short leads of the LEDs (or, for that matter, any leads), I would strongly recommend wearing safety glasses. They are tough to cut, short, and will go flying if you aren’t careful.

So now it is time to make it do something!

altair.jpg

Here is the assembled computer being tested. The main background on the screen is a web page, but the window in the center of the upper part of the picture is the terminal session I’m running. The device is being power from the USB port in this picture.

I’ll keep you posted as I play around with this and some of my other retro computing toys.

Thanks,
Jim W4JBM

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