Introduction
While I’m waiting for the optical components from DigiKey to arrive, I have some time thinking about other parts of the system. That, and the fact that I managed to get my hands on a four-track cassette recorder from eBay made me contemplate how to make the tape interface work. What’s going to follow are some initial thoughts on this part of the computer, options and experiments to conduct. It is highly theoretical and consequently, probably wrong, but it should be a good reference for my thought process for the future.
Cassette tape machines
In case you are much younger than me: these were designed to record and play back audio. This is how they normally looked, at least the more expensive ones:
My device is not significantly different from any other such machine, except that its guts is replicated four times (for the four tracks) instead of the usual two for stereo. That, and the erase head is also a quad-channel contraption allowing individually erasing (or not) any of the four tracks. This is how it looks:
Let’s quickly go through how these machines worked! The tape itself is nothing but some ferromagnetic material glued to a strip of plastic. In case of cassette tapes, this tape is 1/8″ wide and is tightly wound on a spool and put into a plastic case:
The thickness of the plastic that carries the magnetic material determines how long a strip can fit in the cassette. Normally this allows for about 280 feet of tape, which translates to 60 minutes of play time (30 minutes each side). By using a thinner plastic, one can manage to get 90 or even 120 minutes of play out of a single cassette. The trade-off is less mechanical stability, specifically more stretch in the material.
The mechanism reeled the tape from one end to the other during playback or record. The tape is pressed against a couple of heads, namely the erase and the read/write heads. The progression of the tape is held at a constant 1.875inch/s speed by a capstan and pinch roller mechanism:
The first head from the left (the white one) is the erase head, and this is the one the tape passed in front of first. The second head in the center is the read/write head, followed by the capstan and pinch roller.
Recording
During recording, the tape is first erased, as it passes in front of the erase head. This is done by a driving a high frequency (~100kHz) AC signal into the erase head. As the magnetic medium (the tape) passes in front of the head, it incurs several magnetization events. First, as it approaches the head, the amplitude increases, then decreases:
This magnetic field drags the permanent magnet particles inside the medium through their hysteresis curve several times. At peak (in a well designed system) the material reaches saturation, deleting any previously held magnetic information. Then, as the pulsating field amplitude decreases due to the piece of tape getting further and further away from the gap in the erase head, the little elementary magnets “wiggle back” into a random position. The tape at this point is not magnetized either in the north or in the south direction.
As the tape progresses forward, it reaches the read/write head, which is used in its “write” role. A current proportional to the audio signal is driven through it. This current will magnetize the section of the tape in front of the head. However, note that the hysteresis curve is highly non-linear:
As we drag the medium out from the origin on this diagram, it follows a curved path. This would result in high distortion during playback. To remedy this, a “biasing” is used:
This is well described by Ampex in one of their papers where I lifted this diagram from. As I understand it, what’s going on is that we use a small portion of the magnetization curve to store audio information (D-E and F-G), but travel a huge portion of the curve many many times faster then audible. The small portion that we actually use is linear enough that distortion is kept to a minimum, but the large overall travel keeps the signal-to-noise ratio reasonable. What is interesting to note here is that the audio signal during recording is of much lower amplitude than the the AC bias signal (which is the same as what we use in the erase head). Here’s how the recording signal looks like on my tape deck:
You can see the high-frequency ‘buzz’ on top of the audio signal. Note, that the two signals are simply added together, there’s no AM or FM modulation going on.
Playback
During playback the erase head is not used at all. The read/write head is connected to a sense amplifier of about 60dB of gain. As the – now magnetized – medium is dragged in front of the head, the changing magnetic field generates a voltage across the read head. This voltage is detected and amplified by the read amplifier.
I don’t quite understand it, but nevertheless the fact is that during playback we won’t get any of the high-frequency bias signal back, just the lower frequency audio portion. Maybe it’s a function of the bandwidth limit on the read amplifier. If you know, let me know!
What is important to notice is that the generated voltage is proportional to the change in the magnetic field, not it’s amplitude. This in turn is the function of the speed of the tape (constant and the same for read and write) and the change in magnetization in the medium.
In other words, the read amplifier output is the derivative of the recorded signal. In order to get back the original, the signal needs to be integrated. This fact has a few consequences:
First, DC level cannot be recovered. Luckily, it doesn’t have to; audio signals don’t have DC components either. They range from 20Hz to 20kHz.
Second, the slower the signal changes, the less output signal the read head will produce. These low-frequency components are boosted by the integrator, but so is any noise: we shouldn’t expect a flat noise curve from a tape playback.
Third, nothing is ideal. That, plus the need for interoperability between various tape decks resulted in the industry standardizing the frequency response of the read “integrator”. Here’s the standardized curve:
You can see how, in the middle (around point B), this looks like an integrator, but for both high- and low-frequencies there are deviations. The type of the tape (the magnetic material) determines which curve is to be used.
The need to distribute cassette tapes with prerecorded audio meant that the magnetic flux response curve was also standardized. This, for a given tape deck (magnetic head construction, price point, attention to detail, etc. etc.) meant that some record pre-compensation is usually also applied.
These curves are detailed in a pretty good article here. This article shows one example for this pre-compensation. They called it “implicit recorded flux”:
Digital recording on cassettes
Normally home computers used an unmodified cassette deck for storage. That meant that the computer itself interfaced with the deck on its audio input and output connectors. All this complexity that I described was handled by the tape, what was left for the computer to deal with, was an AC-coupled, (highly) noisy, (highly) bandwidth limited channel. They usually opted for a balanced digital modulation (FM in most cases) for recording and simple zero-crossing detection for playback. This works well in these environments as long as fundamental frequency of the digital signal (i.e. the bit-rate) is relatively low, usually only a few hundred bits per second.
Digital recording done right
Recording to tape was not relegated to home computers though. In fact, tape drives were one of the first mass-storage medium used for computers. Just that they weren’t cassette tap drives. They were large, fridge size affairs with spools of tape of a diameter measured in feet:
These worked very differently from what I described above. They dealt with digital information after all. They didn’t care about linearity (this is a vast oversimplification, but will do for now). That meant that – as long as they used high enough write-current to drive the tape material into saturation – they didn’t need to ever erase the tape. They could just re-magnetize it in whichever direction they wished wish during recording. No biasing was needed either.
For recording, all was need was the ability to drive a set current one way or another into the record head.
For playback, they still needed to deal with the fact that the read-back voltage is the derivative of the original recording signal. This is something that disk drives have to deal with as well, so here’s the corresponding depiction from a disk drive circuit application note:
They even describe how the quality of the read voltage “bumps” depend on the read head and magnetic material geometry.
There’s also a very nice application note from Motorola describing a lot of the higher level details.
One can try to implement an integrator, similar to what’s in an audio tape drive to recover the original signal.
However, that’s not the way the industry went. The used a (digital) FM or MFM (or RLL or some other more esoteric) technique to record information on the disk, not in the signal levels, but in the location of the changes. For the sake of FM, for instance even the direction of the read-bumps can be ignored. All that matters is that there always is a bump on the ‘edge’ of the bit-period. For 1-s, there’s also a bump in the middle. For 0-s, it’s missing:
Of course, for this to work, one must have to identify the ‘edge’ and the ‘middle’ of a bit-period first. This is usually achieved by specific bit-patterns, called preambles.
What should I do?
I could go either way. After all, what I have is simply a four-track tape recorder. I can have four parallel bit-streams, recorded and played back in the same way as other micro-computers did.
I could also rip the whole electronics out and go full digital. For recording, this means a current drive circuit that can direct a preset current either way into the read/write head. This is almost exactly the same problem I had with the X/Y select wires in the core memory. Not exactly, because the load now is non-resistive; it is truly a coil, highly inductive. The current setting will also need to be very different, I’m sure. Still, I think I can reuse a ton of the circuit experience from there.
For read-back, I need to greatly amply and detect (threshold) the bumps coming from the read/write head. I need not to bother with the polarity of the bump, purely with their existence. This is almost exactly the same problem that the read amplifiers deal with in the core memory. Again, not exactly, the gain needs to be higher, much higher in fact, but the learnings, maybe even much of the circuitry will carry over.
In terms of the digital coding of the signal, synchronization, transport control (that is, controlling the motors and solenoids inside the mechanism) the two methods are identical. To be honest, the second path sounds way more fun. The only benefit I see to the first is that I don’t have to take that nice Yamaha machine apart. Still, that’s a reversible process, nothing is permanently destroyed.
Head information
So it seems I’m signing up for a record/playback circuit to be designed. To properly design this, I will need to know the specs of the record/playback head in my device.
This of course is not documented. I did find some head specs on the web though. They even spec the heads for digital usage. What I can do is to measure my head (216ohms of DC resistance and 130-140mH of inductance) and match it with this list. The closest match in that table is the W2P6F-A head, with 200ohms of DC resistance and 200mH of inductance. Taking that as the best guess I have, the record current should be around 1mA, the read output should be 9 (mV, I assume) and it should be capable of 1600BPI recording densities.
Larger, digital-only tape drives used write currents in the range of 20-50mA if I read in-between the lines of the specs correctly.
This should give me a ballpark to shoot for. With plenty of flexibility to adopt as needed of course.
Data rates
The same site where I found the head specs actually gives some rather nice application notes. From that, it seems that a standard 50mil head gap head (and I have no reason to believe my head would be any different) produces 5dB loss at 20kHz, at normal speed. At high (twice) speed, it would drop to only about 1dB. My deck can do both normal and high-speed operation, so I can go with the later.
We’ve also seen that the closest head in the spec-sheet was rated to 1600BPI. That is ‘bits per inch’. So, at 3.75 inch per second (high-speed) this comes out to 6000bps per channel or 24000bps for all four channels combined. That is ~3kBps transfer rate. Not stellar, but acceptable. To fill my 32kB of core memory would take 10 seconds or so. Make it 15 seconds by the time I account for error detection, framing, etc.
As far as capacity is concerned, 280ft of tape (length for a C60 tape) and 1600BPI recording density means 2.56MByte of storage per tape. Not shabby!
What’s interesting is this: to get 6000bps in using FM modulation would require 12000 transitions per second, so, a 6kHz fundamental frequency. The rule of thumb is that one wants to ‘see’ the 3rd harmonic of the fundamental to be able to easily recover the signal. That is 18kHz. that’s somewhat lower than the bandwidth of the system (only 1dB loss at 20kHz). So, maybe I can push things a little higher? Well, as always, experimentation will be needed.
As far as processing this data is concerned: 6000bps per track for a machine running at 2MHz and taking 5 clocks per instruction means I have ~65 instructions per bit. This is potentially bit-banging territory, but I would certainly need to disable interrupts and focus all the CPUs attention on this task. So, I think that’s where I will start and only complicate things if absolutely need to.
Conclusion
Let me stop here. It appears that much of what I’m learning (and going to learn) on core memories will have rather direct applications to this tape-storage business. It also seems that I can get pretty decent capacity and acceptable data-rates out of the system. The required HW doesn’t seem terribly complicated, especially if bit-banging works out.
Hopefully this topic wasn’t terribly boring to you and see next time with more optical ROM musings.
