It’s been a long time since computer hobbyists stored their programs and data on cassette tapes. But because floppy drives were expensive peripherals and hard drives were still a long way from being the commodity they are today, cassettes enjoyed a long run at the top of the bulk data storage heap.
Celebrating that success by exploring the technology of cassette data storage is the idea behind [Greg Strike]’s Kansas City decoder project, which he hopes to use with his [Ben Eater]-style 6502 computer. The video below explains the Kansas City standard in some detail, and includes some interesting historical context we really hadn’t delved into before. There are also some good technical details on the modulation scheme KCS used, which [Greg] used to base his build. After a failed attempt to use an LM567 tone decoder chip, he stumbled upon [matseng]’s KCSViewer project, which decodes KCS-encoded audio signals using nothing but discrete components.
[Greg]’s prototype has a comparator to convert sine waves to square waves, followed by pair of monostable timers, each tuned to either the high or low frequency defined in the KCS specs. A test signal created using Audacity — is there anything it can’t do? — was successfully decoded, providing proof of concept for the project’s first phase. We’re looking forward to the rest of the series, which will turn this into an actual decoder, and presumably add an encoder as well.
Listeners of the Hackaday Podcast may recall we experimented with using KCS to hide some data within an episode a few months back.
2nd link is wrong
Thanks. Don’t know where it wanted to go, pointed to Ben’s site.
Although it’s instructive to see how audio loading was done on old 8-bit computers, I don’t really get the obsession with Kansas City Audio encoding when other 8-bit computers had simpler, yet higher performance protocols. The British BBC micro and ZX Spectrum, which used zero-crossing techniques to encode data at over 1000 baud using barely more than a couple of Schottky diodes, a few resistors and caps springs to mind.
https://worldofspectrum.net/documentation/
Kansas City is likely popular conversation piece because it was a widely implemented open standard.
And it has great steak houses!
dunno, maybe cause in the states disk drives were adopted much quicker, and though at a greater cost, a “cheap” computer by the early 80’s here was a serious investment and hardly any software came on tape
Radio Shack had a hand held computer that loaded BASIC code from cassette tapes. It had a record to tape using 3 wires. Data plus and minus into a standard portable cassette player recorder.
The Apple ][ wrote to tape at about 1200 baud, using a shift register and a couple of discrete components.
It’s the reading back that’s always more interesting
It was early on, and a long time ago. There was already a helter skelter of schemes. Someone thought thefe should be a standard, despite different software and different CPUs. So they called a get together in Kansas City. I don’t know the process, but Don Lancaster’s scheme won, I think he’d created it before the conference.
Some used it, or modified it, but it really never was a standard, except on paper. People wanted things faster, others probably wanted to do it their way.
And while there were things like floppy roms (those flexible records) that came in magazines, there wasn’t widespread distribution using the “standard”.
So it really meant nothing.
The BBC Micro actually used the Kansas City Audio standard (or the related CUTS), at 300 or 1200 baud.
KCS probably was the worst transmission format ever conceived. FSK with a frequency ratio of 2:1 is just plain silly, it requires a low distortion channel to work reliably. Simply adopting proven telco standards like Bell 103 or V.21 would have been a better choice.
This is true.
I fixed a thousand tape recorders when I worked at TEAC in the early 1980’s. I can tell you from plenty of experience that cassette tape has its own set of problems that would prove troublesome if you tried to use the telco methods. The cheaper tape machines that the home computers used had very poor frequency response at high record levels, and the output at high frequencies had very poor consistencies in amplitude and phase. Open-reel did far, far better. An open-reel machine’s high-frequency output was a lot more stable, due to the better tape handling and higher tape speed. When I worked on these things, I would do a Lissajous display on the ‘scope when adjusting the heads’ azimuth; and on the cassettes, when you’d get into the higher frequencies, it would just turn into a scribbling effect, just a mess, because the phase was all over the place. Distortion of the waveform should not be a significant problem for the KCS though, because the harmonics resulting from distortion are of high-enough frequencies to be pretty attenuated. When I designed a cheap tape modem for a product at work (in a later job), I fed a triangle wave to the tape, and got a fairly good sine wave out, totally reliable for data. I did what was basically the KCS, although at the time, I didn’t know others had done the same thing and I was re-inventing something that was already common.
Cat with laser vision?
Kansas Kitty Standard.
How about recording v.90 modem output onto a tape then playing it back into a computer?
Did you actually consider what it takes to encode and decode that signal even today?
These cassette interfaces had to work with as few components as possible – and cheap. Requiring a dedicated, specialized IC for this was pretty much a no-go.
Maybe with a 300 or 1200 baud modem, on account of the bandwidth on the commodity cassette recorders of the day was terrible. Otoh if you had one of those 19 inch component stereo decks, it might capture higher rates.
Anyway it’d no doubt require some kind of matching network or interface bc analog phone lines and cassette in/outs weren’t directly compatible, afaik.
Lee Felsenstein had his Pennywhistle modem in Popular Electronics in about February 1976. And hedid suggest it for recording files.
This was after the KC Standard, and I think it was a 110 baud modem, nothing special.
V.90 modems work because both modems “hand-shake” at the start to try and figure out the peculiarities of the particular telephone circuit they’re sharing. Thus they “tweak” the equalisation profile and decide on various modulation parameters. _Then_ they announce the connection to their DTEs and the actual data transfer starts in earnest.
A bit hard to do that with an audio tape unless your modem can travel in time to a future where the receiving modem has had a chance to listen to the past recording your modem made, write its hand-shake response to the tape for your “in the past” modem to receive.
Because in 1975, modems were mostly 110 baud.
v.90 required that the medium have very tight control of amplitude and phase response, which you absolutely cannot get from a cassette at the frequencies involved.
I’m pretty sure Ma Bell would have sued anyone using their standards! (But Bell did have the better data protocols).
Love this 🥰