If you are of the generation who were lucky enough to use the first 8-bit home computers in your youth, you will be familiar with their use of cassette tapes as mass storage. Serial data would be converted to a sequence of tones which could then be recorded using a standard domestic cassette recorder, this recording could then be played back into the machine’s decoder and loaded into memory as a complete piece of software. Larger programs could take a while to load, but though it was rather clunky it was a masterful piece of making the best of what was at hand.
[Mike Kohn] was working with some microcontroller infra-red communication projects when he saw that the same techniques could be used to produce a tape interface like those on the home computers of old.
Over the years he has returned to the project a couple of times, and his original Atmel processor has been supplanted by a W65C265SXB development board based on the 16-bit derivative of the 6502. This made generating the tones as straightforward using his processor’s built-in tone generator, but decoding still presented a challenge. His earlier attempts used an LM2917 frequency to voltage converter to decode tones to logic levels, but on further consideration he decided to move to the LM567 tone decoder. This chip is designed specifically for an on-off logic output rather than the 2917’s analogue voltage output.
His recording device was originally a hi-fi separate cassette deck after experimenting with microcassettes, but eventually he used a data recorder designed for a Radio Shack TRS-80. All his code can be found in his GitHub repository.
It’s probably true to say that [Mike] has made a better cassette interface than the one you could have found on your home computer back in the day. We’ve featured a few data cassette hacks over the years, including this Commodore tape deck with an LED counter, and a tape deck emulator capable of holding an entire software archive.
Is it compatible with the Kansas City standard?
Doesn’t seem so. It’s missing the 256 zeros as a header and the baud rate is lower.
It was interesting to see the loaded data come up as text on the screen as it gives some idea of the speed. The old Kansas standard was faster and also most programs were tokenized to be faster again.
I still have that same tape recorder and tapes with BASIC, assembly and 6809E machine code programs on them. Sadly I no longer have my TRS-80 CoCo computer and have been wanting to throw something together to read it all into my modern PC and do something with it. It’d be awesome fun to write some interpreters.
There is software out there to do exactly that. Connect the tape to the line input of the audio and run the application.
I figured there would be but doing that part is half the fun.
I had a portable cassette tape player for my Ohio Scientific C1P. Floppy Drives were available but too expensive for me.
Lucky you! I had only the OSI Superboard. But I remember doing a hack that doubled the data rate to the cassette… but you had to use high quality tape if you wanted it to be reliable.
I had the same setup. I am having fun trying to read those tapes now.
20 bytes/second is 160bps… didn’t Kansas City/CUTS do 300bps?
KCS was 30B/s; CUTS was 120B/s. (Both were FM-encoded 8N1 asynchronous serial).
MFM or RLL2,7 should make for even better densities, as would some interface using an analog modem… the only real question is how much flutter we have to compensate for.
i wonder what baudrates we could achieve on these tapes with modern modulation schemes like QAM ..
Good question but the math is simply, using a bad scenario a cassette/deck have a bandwidth of 12 kHz but only 10 kHz are useful, the we use the modulation used in the 56k modems (efficiency 14bits/s) then we have 140kbps (17kiBps). And that is for one track, if we use both stereo tracks the datarate doubles. In reality with a quality media/deck is possible to obtain rates 50% higher or more.
A VCR would be a much better candidate, but even that would be way behind what cheap USB drives can do. That said, I suppose there is the cool factor of having a cassette recorder that stores MP3s on unmodified cassettes or a VCR that records H.265 HDTV on unmodified VHS tapes.
For an idea over VCR the D-VHS had the same recording mechanism as the S-VHS, it offered it to 28mbps and 50GB per tape. True this things are done for the cool factor, the “why not” and “because it can be done”.
Only problem with the VCR is that you’d either have to severely limit the bandwith to something around 1MHz and inject synchronization signals (even less usefull data to store) or come up with your own synchronization electronics…
IIRC D-VHS required special tapes that had a denser, higher coercivity coating than ordinary VHS. S-VHS tapes were, though in the waning years of the format, a recording method was invented to enable S-VHS VCRs to record S-VHS quality onto standard VHS tapes – but without any guarantee they’d be playable on any other VCR brand.
Most of the later standard VHS VCRs were capable of playing S-VHS tapes but downsampled the signal and mixed the luma and chroma to composite.
Back in the day, there was hardware to use VHS tapes for backups, my friends had it for the Amiga (simply connect the regular video output to the VCR and connect the video output from the VCR to some hardware connected to the parallel port), It worked very well. I myself had an ISA card in my PC for the same purpose but it never worked right: it kept crashing the computer even when it wasn’t in use.
Nowadays, generating video from data and extracting that data from video again is pretty simple using modern microcontrollers. If you use PAL (25fps) and fill 480 lines of each frame with usable data (the rest of the lines for error detection / correction and time code) in the form of black and white video, your throughput is 12,000 video lines per second. So if you put one byte on each video line, you get 12,000 bytes/second.
On a regular VHS recorder with average quality tape you can probably record 16 bytes per video line (192,000 bytes per second) which is more than the data rate of uncompressed 44.1kHz stereo digital audio like audio CD’s use (176,400 bytes per second (*)). With S-VHS you can probably go up to 40 bytes per line if you design things carefully (hint: S-VHS is good enough to record Teletext signals), but by the time you can make the video rate that fast, you’ve probably already run into problems getting the data to and through the microcontroller fast enough, and you’ll have to start dealing with wow/flutter of the tape. Not to mention data loss through tape dropouts.
===Jac
(*) The fact that digital audio used 32kHz, 44.1kHz and 48kHz is directly related to the fact that video tapes were used to record digital audio before Compact Disc and Digital Audio Tape came along.
Actually the VHS capacity is slightly different, with 3Mhz luma bandwidth and 400Khz chroma bandwidth, chroma can be used to tracking and some error correction, and for encoding data in luma we use a 6 bits/Hz (similar to cable tv) we optain 18Mbps if we add another layer or error correction and leaving headroom This is going to be more like 14mbps that is even hither than the DVD bitrate. And for S-VHS that have the same chroma bandwidth but with 5Mhz of luma Bandwidth the rate is boost to 23mbps. And this without pushing the technology to their limits.
Dam the efficiency is 14bits/Hz the bits/s is an error.
lets call that an even 30kB/s for both tracks with some room for an error correction scheme and framing.
that would mean that a 90min tape could store about ~160MB on one side ?
Yes and No as each side have half the cassette running time, then you did the math wrong and those ~160MB are actually for a 90min tape or ~80MB per side using my basic example with your headroom, but if we push the cassette to a medium/high quality (15khz useful bandwidth) the capacity goes to ~240MB (~120MB side) and if the is pushed to their limit directly interfacing the heads and precision speed control is probable to obtain the capacity that you appoint ~360MB (~160MB side). And finally in the wild some data loggers machines on the 80 where putting 60MB on as standard cassette.
It’s not as simple as the math might have you believe. For example QAM is a suppressed carrier modulation so the carrier has to be generated at the other end (read back) and it is regenerated with a Phase Locked Loop (PLL). In fact the actual data comes from the correction signals (or phase state) of the PLL.
Frequency Shift Keying (FSK) used for cassettes is also normally suppressed carrier but in the case of cassettes one of the frequencies is exactly twice the other so it is effectively transmitted carrier.
This is important because of some of the limitations of cassette players. They were a (very) cheap domestic product that was made without any great consideration for signal fidelity. This was the era before high fidelity (Hi-Fi) was taken up by any except the audio enthusiast and audio enthusiasts didn’t bother with crappy cassettes, choosing instead to use records and multi-track (4 to 8) ‘Real to Real’ tape players.
Cassettes has the following issues –
Flutter – the cogging of the drive motor would modulate the tape speed and therefore the recorded frequency
Wow – other rubber drive parts would also interfere with tape speed causing a slow repeating variation
Motor speed – the motor speed was mechanically regulated in some cases and in other cases it had a voltage regulator that didn’t compensate for changes in friction or temperature so playback frequencies may be different on different players.
The pole gap of the head – this was designed as a poor quality audio playback head and had a catch 22. To increase data rate you would often consider increasing tape to head speed but for the audio head this means increasing the effect of the pole gap so that at higher speeds the top of the recordable bandwidth is reduced cancelling any benefit of the higher tape speed.
All of the above meant that you had to use a modulation scheme that didn’t suppress the carrier for it to work from one cassette player to the next and that is why the Kansas City standard was made.
The Kansas City standard was often talked about but rarely implemented to it’s full specification because most manufacturers didn’t want or need to have their cassette tapes work on other systems so there was more or less no real standard at all.
The Kansas City standard specified several cycles of each of the two frequencies in modulation so that the AC modulated signal could then be put through a low-pass or high-pass filter and rectified to recover the data.
Later non-Kansas City standards that were implemented for higher storage rates and densities brought the cycles per bit token down to one significant cycle so data recovery was strictly done on a DC basis from the recovered signal and that is why it was so finicky to get the volume setting right for it to work.
So in effect, most of the data rate limitations were mechanical limitations of the cheap hardware.
FSK is never suppressed carrier like any FM based modulation method, but in reality I omitted a lot of data on the implementation trying to simplify and omit the complex math, as I noted 60MB per tape was done in the late 80s in datalogers using modem techniques.
The flutter and wow can be compensated using a clock carrier and DSP techniques, this signal can be also used as a clue to the QAM demodulation.
The rate limitation where not only mechanical but also computational, and today digital modulation techniques are very computational intensive and can push the Shannon capacity to their limit.
And some more complex math: a cassette have a bandwidth of 12khz and a SNR of 50db, but we assumed that only 10khz with a SNR of 35db are workable, using the Shannon–Hartley theorem the capacity of the cassette is ~116kbps, if we add a layer of data correction using LPC 7/8 we obtain a rate of ~102kbps or 12kiB/s, and for my previous example is needed a bandwidth of 11khz and a SNR of 40db.
And the question was to push the tapes, and I assumed the use of deks from the mid 80s to mid 90s.
PD. I sometimes suppress some data because can be a pita to explain it, and only is useful if we go to the most technical aspect.
sorry FEC is not LPC but LDPC, but there are other possibilities for error correction.
I worked at TEAC in 1982-83, and fixed about a thousand tape machines while I was there. I always finished up with a complete alignment/calibration. In cassette machines, even the high-end ones’ frequency response was measured at -40VU, because that’s the only way they could get decent-looking frequency response specifications for marketing. If you brought it up to 0VU like the open-reel machines were measured at, the cassette response made it only to about 4kHz before dropping off sharply. An exception was the Portastudios (I worked on gobs of 144’s and 244’s) which ran the tape twice as fast (3.75ips), and used a bias frequency of only 60kHz. Their top end of 13kHz may not have looked so good on paper; but they maintained it up to higher record levels, even 0VU IIRC.
Another problem that would plague cassettes for trying to reliably get the data through faster is undoubtedly the dropouts, or pinpoints on the tape where the output drops way, way down, which would really mess up the “A” in “QAM.” In fact, in the alignment process, you first align the playback to the calibration tapes, and then put in the specified tape to record on and align the record to the playback. If you’ve ever bought calibration tapes, you know they’re very expensive; and we were given replacements quite frequently to make sure that tape wear was not affecting our alignments. One of the calibration tapes had a 10kHz tone on it, alternating with 100Hz IIRC. The 10kHz made the oscilloscope display bobble and jump a lot. The cassette simply could not put out a stable amplitude at 10kHz. The open-reel machines OTOH were solid.
The “Q” in “QAM” would also be messed up at high frequencies because cassettes’ poorer tape handling (compared to open reel) made for more phase variation. The normal way to get the tape heads’ azimuth aligned is to use a full-track calibration tape with increasing frequencies. After peaking the output, you can take two channels (like right and left of a stereo head) and do a Lissajous display on the oscilloscope and try to get the two in phase by further refining the azimuth adjustment; but at 10kHz, the cassette output was all over the place, like scribbling on the screen.
The ticket to getting faster data rates on cassette, if the machine didn’t have to be compatible with music cassettes, would be to run the tape at four or eight or sixteen times the normal cassette speed, say 15ips. Part of the point in data storage for early home computing however was that cassette machines that were made for voice and low- to medium-quality music reproduction were ubiquitous, and the tape modems were made to work with those. However on dedicated ones like Commodore’s, there was no good reason to hold it down to the slower speed. Did this not occur to Commodore’s designers? Or were they not anticipating enough sales to get a transport custom-made to run at a much higher speed?
Woops—I don’t know if it matters, but my website address is wrong for the post above. It says http://wilsonmines@dslextreme.com. I don’t know how that happened. It should be http://wilsonminesco.com/ . It’s probably wrong for my last two or three posts.
A project for a glutton for punishment – I was happy to see the end of that era, and I have no wish to revisit it.
The limitation of the cassette recorders was the desire to use them unmodified. So anything off the shelf could be used. I had a stereo tape deck, or rather the transport intended for one, bought at the surplus store, so I wired it up with meters and record level controls.
But every so often someone got bold, they went directly to the tape heads, and put DC on them, “saturation recording”. No audio tones, and faster throughput. But not compatible with anything.
Considering many or most had a cassette recorder for their computer, modifying didn’t matter, they weren’t using it for other things anyway.
At least one commercial device used this, I think, including a tape drive that the computer had more control over.
For a step up, one company sold a floppy drive and controller, but treated it more like a cassette recorder. So no operating system, you told it where on the floppy disc to save the program, and wrote it down on paper, not unlike writing down what the tape counter on the cassette recorder showed at the start of a program.
Michael
Coleco’s ADAM computer used direct digital recording onto cassette tapes. Unfortunately Coleco did not put the ability to format tapes into the system. Blank, specially formatted tapes could only be bought from Coleco. Then there was the problem of one version of the ADAM (IIRC the standalone version, not the Colecovision expansion) that would blast the drives with an EMP when turned on. Having tapes in the drives when turning the computer on could damage them.
Another company that tried vendor lock-in with tapes was Iomega with their Ditto series of tape backup drives. The types of QIC tapes the drives could format were limited. Some it couldn’t even write to. The highest capacity tapes they supported were the proprietary Ditto formats, which the drive could not format.
The market shunned Ditto and the QIC standards were expanded with extended length tapes and some with tape wider than 1/4″.
The wang 2200 (circa 1973) used a cassette tape for program and data storage; floppy and hard disk storage were also options. Wang did a few things for higher speed and greater reliability. First, the tape speed was higher. Second, it used both tracks to encode clock/data (really one was a zero track and one was a one track). The tape direction was under CPU control, and if there was an error, it would reread the block in question up to 10 times before giving up. Each block was recorded twice as protection against errors.
It recorded at 800 bpi,7 1/2 inches/second, so 6000 bits/s, but because of redundancy and block overhead, it was somewhat under 3000 bits/s. In practice is was fairly reliable, and I was horrified when I later used a TRS-80 cassette based computer, where recovering the program off tape was a crap shoot and required a lot of manual fiddling.
http://www.wang2200.org/docs/internal/2200_TapeDriveSpecifications.2-73.pdf
Amazing how the digital wheel keeps getting reinvented.
The Germans with their Nascom emulator did the old CUTS cassette interface in DSP on the host PC. Many modern microcontrollers have the power for that functionality. The weak link is always the tape itself however.
8bit Atari stadard Turbo speed about 2700bd, capable of 6000bd
http://jpecher.sweb.cz/turbo/pic/XC12.gif
Who even has a tape recorder any more these days??
AFAIK they are still used in data centers for cold storage, backups and archiving.
for long term storage it is still the cheapest and probably the best option, the are actual archival tape available.
formats like DDS and LTO are still widely available, only real issue is the price of the drives, the tapes are fairly cheap for the storage provided.
Tapes certainly are still widely used as backup medium all over the world. My previous job also involved making daily data backups on tape for safe off-site storage.
I have several; but the problem is that the rubber belts especially, and to a lesser extent the rubber wheels, deteriorate (even without use) and render the unit non-op, and it is difficult to impossible to find replacements. The rubber parts should be changed every few years. However, as for the medium, I have an open-reel tape of Frank Sinatra singing from the 1950’s that still sounds outstanding, whereas I’ve seen home-burned DVDs lose their data in as little as two years.
Convert old FSK audio to nice MP3 and store on DVD. That way you dont lose those programs to tape degradation. Sure… could use CD but thats low class. Thanks for the flasback and HERO I salutes you.
Better off with low-quality WAV. I wouldn’t trust MP3, or any lossy compression, with computer tapes. I would bet that even if it did work, you’d need such a high bitrate it would be smaller just storing as flat WAV.
Fortunately that doesn’t matter. 8-bit fans have been using TZX for a decade or two. Originally just for ZX Spectrum tapes, it now has support for most other old computer tapes. The format has lots of information, can cope with weird tape formats, and produces files about as tight as they’re gonna get. It’s covered!
You’d want to keep it on flash or hard disc. I have an open-reel tape of Frank Sinatra singing from the 1950’s that still sounds outstanding, whereas I’ve seen home-burned DVDs lose their data in as little as two years. I assume CDs could go south almost as fast.
The heck with 300 baud KC standard. You guys should look at Don Tarbell’s standard. He used Manchester encoding and was getting 15 Kbaud. The trick is to bypass the audio stuff and talk directly to the read/write head.
Also, I had a TRS-80 with an Exatron “Stringy floppy.” Plugged right into the TRS-80. They used the same Manchester encoding, got the same baud rate. The software was written by Li-Chen Wang, the author of Palo Alto Tiny BASIC. He used very careful clock-cycle matching to ensure exactly equal timing on transition/not transition. Manchester encoding is very insensitive to frequency, and needs no separate clock signal. But at the frequency limit, every square wave looks a lot like a sine wave.
I tried writing my own software for the ESF, but didn’t worry about the timing. I got 14.5 Kbaud, which ain’t half bad, but never quite matched Wang’s wonderful code.
Jack
Still have my S-100 computer with the Tarbell tape interface. I plan on pulling out of storage ‘someday’.
15kbps is amazing. How tolerant was it of variations in tape speed? One problem with tape, especially cassettes was dropouts, basically pinpoints on the tape where the output dropped way, way down.
I’m still using 9 track tapes for backup, with huge monsters such as this one (not mine, video here just for example):
https://www.youtube.com/watch?v=TVx31unjf-g
Such a tape at density of 1600 bytes per inch could hold around 30 MBytes.
At 6250 bytes per inch, the capacity could reach up to 700 MB, like a CD.
If VCR tape is used (thicker, but in a continuous stream from the VCR tape assembly line feeds), capacity can go up to 2 GBytes.
So you can’t get any performances using normal audio cassettes.
And you can’t connect digital tape drives to older computers via audio i/o.
What you need is some sort of a parallel port or a pertec (industrial standard) interface connected to the extension i/o bus of the host system.
Hook a 9 track tape drive to that interface, write the proper subroutines and voila – you’ve got yourself an ancient computer which can store data on tape.
100% original and cool.
Yeah but where the hell’s he going to get a 9-track tape recorder from? Or the tape? At least cassette recorders are still available. If he’s going to abandon cassettes, he may as well go straight to SD card. Tapes have a provenance, there’s a certain unique feeling doing something like loading a tape, or setting a VCR, for the first time in 20 years. It’s pleasurable!
Yeah but where the hell’s he going to get a 9-track tape recorder from? Or the tape?
I’m guessing that’s what the remark beginning “If VCR tape is used…” is all about.
I worked on an AIM-65 system 2 years back that was controlling a metal cutting laser making aircraft parts. The manufacturing engineer fried the AIM board and hence its coded custom 2532 EPROMs with not backups. But he sent me the cassette tapes which I loaded onto one of my AIM systems but was not able to find any program dumps. It was way cool but unsuccessful for the result we were trying to achieve. I think they changed the controller over to a modern and supported variety.
You can get the tape from http://www.athana.com/html/ctape.html . (It’s 1/2″ computer tape. How many tracks you put on it is up to you, I suppose.) Getting a machine will be a bigger challenge. They even sell 8″ floppy discs, at http://www.athana.com/html/diskette.html#8 . :D
There’s an even simpler way, if you’ve got a microprocessor. Same way the ZX Spectrum did it.
You generate the tones in software. Set the tape port to 1, wait a while, set it back to 0.
To read it back in, do the same. Wait for the tape port to change, 0 -> 1 or 1 -> 0, doesn’t matter. While you wait, keep a counter. On change, check the counter. You’ve just counted the length of the pulse.
Use a long pulse for 0, a short for 1. You ignore the polarity of the pulses themselves, 0 / 1, altogether, all that matters is the time between changes.
Needs just about no hardware. Just an IO port, with a circuit to produce the right voltage for the tape’s record input, and another to change the tape’s play output into digital pulses. Something like a Schmitt trigger, for the hysteresis right around the time the signal changes, to stop “bounce”.
This can be done with just about no hardware. Solved problem, nearly 4 decades ago! A CPU is more than capable of doing tape IO in software, the audio frequencies are practically glacial compared to a CPU’s clock speed. The Spectrum managed about 2,000bps (yes two thousand). Less smart designers, on 6502 machines, for some reason only got about a tenth of that. Speccy games would load in 3 minutes, Commodore and Atari took more than half an hour. In fact, the Spectrum could load a game off tape, faster than the Commodore 64 could load from disk (that is, using the Commodore’s built-in loader, though people started to use fast loaders pretty quick).
I bet the Commodore / Atari used a more complicated circuit, too.
I would just only use Machester encoding (BPSK) as opposed to the standard used in ZX Spectrum (FSK). The former is much more resistant to wow and other pitch fluctuations. I used to own a 8-bit machine that used Manchester as well as repeating 256-byte blocks twice to increase reliability, and that worked quite well even on average tapes.
I never owned a C64, but the tape format described at http://sidpreservation.6581.org/tape-format/ suggests 864us per bit =~ 1.2kbps, so slightly better than half the spectrum’s speed. https://en.wikipedia.org/wiki/Commodore_1541 suggests that the C64’s unmodified disk transfer rate was 512 bytes per second, so well over twice as fast as the spectrum tape system, and max 2 minutes to transfer the entire 64KiB of RAM. These rates are pretty poor, but nowhere near as bad as you suggest.
The Apple II cassette interface achieved 1333bps with virtually any off-the-shelf cassette recorder, using an attenuated digital output to drive the microphone input and an AC-coupled open-loop op amp driven from the headphone output, connected to a digital input.
Software timing loops generated and decoded all the signals.
No rocket science, just competent design.
how to make a yamaha Dx7, Tx7, Qx7 cassette interface that will work.
Very interesting topic! But I dont see clearly what can be the highest kbps which can be recorded onto a compact cassette with a hifi tape deck. Over 48kbps it is possible to make acceptable stereo sound with mp3 pro & vbr & joint stereo. So it would be an interesting project to make a hifi tape deck capable for digital audio record and playback.
Just sayin, the best data to store on tape is Biphase mark code at 4800baud. I use it flawlessly