It has been a long time since we stored software and computer data on audiotape. But it used to be the de facto standard for hobby computers and [Noel] has a great video about the Amstrad’s system (embedded below) which was pretty typical and how the process could be sped up since today, you have perfect audio reproduction, especially compared to consumer-grade audiotape.
The cassette tapes suffered from several problems. The tape had an inherently low bandwidth, there was quite a bit of noise present from the analog circuitry and heads, and the transport speed wasn’t necessarily constant. However, you can easily digitally synthesize relatively noise-free sound at high fidelity and rock-solid frequency. So basically a microcontroller, like an Arduino, can look like an extremely high-quality tape drive.
The idea is similar to a modem except instead of a computer talking to another computer over a phone line, it records it and listens to it again, later. The normal tape system could only get about 2 kbps. How fast can you get if you are generating a nearly perfect digital signal? Watch the video, and find out.
We will say, that he’s not done speeding things up. Emulating tape drives isn’t exactly a new idea. We’ve even seen it done for big iron tape drives.
is possible using cassete to internet? I download data trought cassete and put to the terminal/browser
seeking cassete is my data sending to ‘cassete’ internet.
Yes! See: https://joak.nospace.at/works/rrtrn/
on zx spectrum we used to use ibm’s floppy drives, now that was a much faster user experience, not to mention the c64 had a way more inferior (serial?) floppy drive so we all laughed when they was loading their games :)
The C64 disk drive was connected to the C64 by a serial interface and had its own on-board CPU (this was a continuation of the PET disk drive), but due to a bug in the chip set of the C64 (the CIA chips if I remember correctly) it couldn’t run at the planned speed. It was however still much faster than tape. Later C64s and variants (like the C128) had fixed the problem and could be made to communicate with the floppy drive much faster.
The Amstrad and Spectrum machines used a floppy controller directly connected to the Z80 bus, which was inherently faster and cheaper, but limited you to two drives and, if one of those was external, needed a thick and relatively short connector cable.
It was worse than that. 6522 VIA was broken on PET, but C64 shipped with fixed 6526! Apparently someone forgot to route serial shift register pins to the connector :-) and Commodore in all of their wisdom just went with old slow software method instead of fixing the pcb …
C64 Tape Turbo was capable of 500 B/s while standard floppy operated at 400 B/s.
ActionReplay6 Floppy Turbo managed 5 KB/s.
Current state of the art is Krill interrupt loader at ~10 KB/s https://csdb.dk/release/?id=189130 and ~20 KB using his own custom disk layout/filesystem https://csdb.dk/release/?id=197710 All still using 2-bit software bitbanging with no hardware modifications :o
And to fill in information about contemporary tape – these days one would use Tapecart (Arduino Nano/Micro Pro+SD card adapter) to load single-file programs. It has a tiny bootloader loaded using standard (slow) protocol which then switches to a timed 2-bit transmission (cycle-exact on both sides) which reaches ~9.5KB/s.
I wonder how much things could have been improved if hobbyist tape storage had used error-correcting codes.
Slow it down?
I don’t recall fussing.I can’t reme!ber if I used a cassette recorder with my KIM-1. But I did with my OSI Superboard II in 1981. Once I got things adjusted, I never had problems.
But I used a cheap stereo transport (surplus, intended to go i to low end hifi sets). So I had volume controls on both record and playback, and level meters. And a tape counter, so I could write down where a program started. I saved a few programs to each cassette, even buying ten minute cassettes (for outgoing messages on answering machines) for some key programs I always needed.
Different comouters used different schemes, and most were used with cheap cassette recorders. So they had agc on record, and no level control. I suspect that contribured to the problem.
There were schemes to modify cassette recorders by feeding digital signals directly to the tape head, and feeding the tape head into a comparator on playback. Saturation recording, no fussing with levels, no problem with sort of square waves in analog circuitry. But most people used the cassette recorder they had, and wanted to play music when not computing. So they wanted it intact, not midified.
For people who wanted better, there were floppy drives.
Machines like the C64 and Amstrad had their own dedicated cassette drives, which did away with issues like AGC, but they still couldn’t run reliably much above 2400 baud.
Tapes were used because they were easily available, cheap and, for the most part, good enough for early microcomputer hardware (filling only a few K of memory didn’t take that long). As numbers increased (both of deployed machines and standard RAM sizes) then floppy drives became more practical.
Not much, simply because tape storage was already really robust. Sure you could have a bad tape or a misaligned tape drive, but on the whole read errors were pretty rare. Error correction might have pushed their occurance down a bit, but at the cost of slower load times.
I figure if we could squeeze 56kbps through a phone line, we should be able to do at least twice that on a stereo tape deck. I wish I knew DSP, it would be cool to find the maximum bit density on an audio tape…