A Cassette Interface For A 6502 Breadboard Computer, Kansas City-Style

October 11, 2022 by Dan Maloney 25 Comments

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.

Continue reading “A Cassette Interface For A 6502 Breadboard Computer, Kansas City-Style” →

Unraveling The Hackaday Podcast Hidden Message

July 1, 2022 by Tom Nardi 7 Comments

When Elliot and I record the raw audio for the weekly podcast, it’s not unusual for us to spend the better part of two hours meandering from topic to topic. During one of these extended gab sessions, we wondered if it would be possible to embed a digital signal into the podcast in such a way that it could be decoded by the listener. Of course, storing and transmitting data via sound is nothing new — but the podcast format itself introduced some level of uncertainty.

Would the encoded sound survive the compression into MP3? Would the syndication service that distributes the file, or the various clients listeners will use to play it back, muddy the waters even further? Was it possible that the whole episode would get flagged somewhere along the line as malicious? After a bit of wild speculation, the conversation moved on to some other topic, and the idea was left to stew on one of our infinite number of back burners.

That is, until Elliot went on vacation a couple weeks back. In place of a regular episode, we agreed that I’d try my hand at putting together a special edition that consisted of pre-recorded segments from several of the Hackaday contributors. We reasoned this simplified approach would make it easier for me to edit, or to look at it another way, harder for me to screw up. For the first time, this gave me the chance to personally oversee the recording, production, and distribution of an episode. That, and the fact that my boss was out of town, made it the perfect opportunity to try and craft a hidden message for the Hackaday community to discover.

I’m now happy to announce that, eleven days after the EMF Camp Special Edition episode was released, ferryman became the first to figure out all the steps and get to the final message. As you read this, a coveted Hackaday Podcast t-shirt is already being dispatched to their location.

As there’s no longer any competition to see who gets there first, I thought it would be a good time to go over how the message was prepared, and document some interesting observations I made during the experiment.

Continue reading “Unraveling The Hackaday Podcast Hidden Message” →

Reading Old Data Tapes, The Hard Way

October 7, 2018 by Dan Maloney 29 Comments

Those who were around for the pre-floppy days of computer mass storage were likely to have made the mistake of slipping a cassette tape containing data into a stereo tape deck. Instead of hearing the expected Awesome Mix, the speakers gave off an annoying bleat, warbling between two discordant tones and no doubt spoiling the mood.

What you likely heard was the Kansas City standard, an early attempt to provide the budding microcomputer industry with a mass-storage standard. It was successful enough that you can still find KCS tapes in need of decoding to this day. That job would be a snap with a microcontroller, which is exactly why [matseng] chose to do it the hard way and built a KCS decoder with nothing but discrete components.

The goal was to decode the frequency-shift-keyed (FSK) signal into an 8-bit parallel output, and maybe drive a seven-segment display as the characters came off the tape at a screaming 300 baud. Not an IC is in sight in the schematics; as [matseng] says, it’s nothing but “Qs, Rs, and Cs.” All the amps, flip-flops, and counters needed are built from a forest of transistors, and even the seven-segment display is a DIY affair of LEDs in a 3D-printed and hot-glue frame. The video below shows the display doing its best to show the alphanumeric characters encoded on the audio tape. And for who absolutely need a dose of Arduino, [matseng] used one along with a dead-bug low-pass filter to emulate KCS signals, for easier development.

We always appreciate hackers who take the road less traveled to arrive at a solution, but if you’re pressed for time to decode some KCS tapes, fear not – all you need is a PC and Audacity.

Continue reading “Reading Old Data Tapes, The Hard Way” →

Dump Your (Old) Computer’s ROM Using Audacity

April 12, 2016 by Elliot Williams 32 Comments

If you’ve got an old calculator, Commodore 64, or any other device that used a tape recorder to store and retrieve data, you’ve probably also got a bunch of cassettes lying around, right? Well, you can get rid of them now (or sell them to nostalgic collectors for outrageous prices) because you can just as easily dump them to Audacity, decode them and archive them on a more sane medium.

In [Kai]’s case, the computer was a Sharp Pocket Computer system, and in his post there’s a lot of detail that’s specific to that particular system. If that’s applicable to you, go read up. In particular, you’ll be glad to find that the Pocket-Tools is a software suite that will encode and decode files between the Sharp binary formats and audio. Along the way, we found similar tools for Casio pocket computers too.

For a more general-purpose approach, like if you’re trying to dump and load data from a more standard computer that uses 1200/2400 Hz FSK encoding, this Python library may be useful, or you can implement the Goerzel algorithm yourself on your platform of choice. If you’ve got a particular binary format in mind, though, you’ll have to do the grunt work yourself.

Anyone out there still using these audio data encodings? We know that ham radio’s APRS system runs on two tones. What else? Why and when would you ever transfer data this way these days?

via the Adafruit blog!

The Dan64: A Minimal Hardware AVR Microcomputer

April 7, 2015 by Elliot Williams 26 Comments

[Juan] sent us his writeup of a microcomputer he built using an Arduino UNO (AVR ATmega328p) and some off-board SRAM. This one’s truly minimalistic.

Have a look at the schematics (PDF). There’s an Arduino, the SPI SRAM, some transistors for TV video output, and a PS/2 connector for the keyboard. That’s it, really. It’s easily built on a breadboard in a few minutes if you have the parts on hand. Flash the Dan64 operating system and virtual machine into the AVR and you’re good to go.

Now we’ve seen a few 6502-based retro computers around here lately that use a 6502 paired with a microcontroller for the interfacing, but they’ve all been bulky three-chip affairs. [Juan] wins the minimalism prize by using a 6502 virtual machine implemented in the AVR to reduce the parts count down to two chips for the whole shooting match.

Using a 6502 virtual machine was a crucial choice in the design, because there are 6502 cross compilers that will let you compile and debug code for the microcomputer on your macrocomputer and then load it into the micro to run. This makes developing for the micro less painful.

How does it load programs you ask? The old-fashioned way of course, using audio files. Although rather than using the Kansas City Standard as in days of yore, he encodes the data in short and long pulses of square waves. This might be less reliable, but it sure saves on external hardware.

Continue reading “The Dan64: A Minimal Hardware AVR Microcomputer” →