Making a Python script to convert audio tape to binary code for my PAL-1 seemed somewhat useful, but especially instructive as since I wanted to learn more on how that worked. Showing off a working prototype at the PAL-1 forum I got asked: but can it do hypertape. Oops… no. So, how does that hypertape work? Back to the drawing board.
Hypertape, part 1
‘Back in the day’, when serial interfacing using a teletype or glass terminal was usually way out of reach for the average KIM-1 enthusiast, loading programs was usually done using the audio tape interface. Taperecorders were reasonably priced and many people would already own one for recording and playing speech and music.
The audio tape format is well described in the KIM-1 manual.
It is actually fairly easy to recreate in code, but that will be the topic for another post. For now I was interested to see if hypertape would work on the PAL-1. I haven’t yet implemented hypertape format in my program that converts binary to audio (.wav). So I used the KIMposer website to create some hypertape audio files. But loading on the PAL-1 failed. So, what is going on?
The KIM-1 audio input can be checked by probing the PLL pin with a scope. The PAL-1 has a similar pin out (acutally, exactly the same if you study the circuit diagrams, it’s just called ‘cassette’).
So, what does the input look like for a ‘normal’ tape format, and how is that converted by the PAL-1 cassette interface?
The following is an audiogram created from my own script:
You can clearly see the difference in frequencies between 2400 and 3700 hz, and the prescribed length of each frequency duration. If we zoom in a bit we can appreciate the individual waves better:
Looking at the figures of the waves they look quite ideal, and they should be as they are generated to be just that. However, the output I captured from the PAL-1 earlier also looks quite good (from the recording, the actual audio output looks even better):
If we look at a Fast Fourier Transform (FFT) of the input that I’m going to feed to the PAL-1, the pattern is more or less as expected with peaks at the expected frequencies.
When we feed the audio to the cassette interface of the PAL-1, and probe the cassette pin, the following image comes from the scope:
Zooming in and measuring the wave, we see that my own audio file is slightly off in timing, about 1.7% faster than indicated in the KIM-1 manual, but probably reasonably within spec.
Ok, so what about hypertape? Well this is an interesting story in itself, detailed by the (co-)inventor of hypertape and 6502 guru, Jim Butterfield. The KIM algorithm for ‘listening’ to the input doesn’t care for absolute timing at all, it cares about the ratio of time of high and low frequency sound. Effectively, the duration of each frequency can be compressed to 1/6th. The secret is to make use of ‘half-cycles’, which allow a short duration interval of 3700 hz to be compressed to 1.5 pulses.
Interestingly, Butterfield remarks in the article that the sound is different when you listen to it yourself. And that makes sense looking at the FFT:
The FFT is from a digitally generated audio file with the KIMposer tool, which can output the normal and hypertape formats.
Looking at the waves in the audio file, it is clear that KIMposer aims to apply the format prescribed by butterfield, although it is not obviously the same.
What certainly is clear is that the format uses half-cycles which makes the pattern far less legible to the human eye as we try to interpret the pattern as 0s and 1s. It also explains the FFT - the concentration of frequencies inbetween 2400 and 3700 hz.
Ok, so how what happens when we feed this audio file to the PAL-1 and probe the cassette pin?
It is fairly clear that something is amiss right away. The low and high patterns seem out of proportion and there even appear to be gaps.
Zooming in, it becomes more clear how the ratio of high/low frequency interval duration isn’t quite right. Also, the bits seem to be a bit short, every bit is expected to last a little over 1ms. Some bits are right in timing, but others, like this one, is not.
But probably even more problematic is that some phase transitions result in bouncing of the high signal. This can’t be right and certainly is enough to make the hypertape fail.
So, what now? Not sure, this needs to be continued. In the mean time I have amended my program to convert audio to binary with the option to read hypertape. That does work, at least on the KIMposer-generated audio. But feeding that same audio to the PAL-1 does not work. Bummer.
A little postscript: Interestingly, at the site of Hans Otten a bunch of WAV files can be found from the first book of KIM. These seem generated by the KIMTAPE software, although I’m not sure. These audio files look rather different - not only are they not square-waved, they seem to be close to half-duration compared to the formal specifications - so, a bit like a ‘slow hypertape’.
The PAL-1 seems to read these fine, but the duration of intervals is about half, as expected.
This hypertape story will be continued, for sure. In the mean time, if you’re interested, check out some code I’ve made to convert and analyze audio tapes for KIM-1. Note though, this project is still very much a work in progress.