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!
Tapes. That’s… not ROM, then, is it?
The project that Elliot was talking about is how one guy copied his 80’s era pocket computer ROM to his computer; he used the machine’s BASIC CSAVE function, which is supposed to save a program to tape, to transfer the ROM data to his PC using audacity and pocket-tools.
Tapes aren’t ROM.
Paul, you are right. But that isn’t what is going on. Did you read the article?
And anyway, they’re kind of like Flash ROM – you can’t alter individual bits or bytes, but you can erase and rewrite blocks of data.
Anytime you want data to go thru a voice or audio channel that already exists, which can then be easily pulled off. Think of those modem sounds for EBS on radio setting off alarms for storm warning etc.
Is that how (for example) tornado sirens are activated? They just listen to the radio 24/7 for the sound of a certain emergency broadcast?
Yes, look into EAS, and specifically the SAME header which digitally encodes location information (so you don’t have to constantly hear about floods happening at the other end of the state).
https://en.wikipedia.org/wiki/Specific_Area_Message_Encoding
No I’m not using them anymore, and I can’t think of any reason I’d want copies of those programs – I was happy to see the back of them.
I did the same for my old MSX programs saved on tape. I created them when I was about 10 years old, my very first programs in MSX-BASIC. Good fun to see them back and see them spring to live again on an emulator.
There were some bumps in the road though. The tape deck I got second hand had a problem with the belts, they were slack. 3D printed a new set and it came alive again :)
The tapes had degraded a lot. I used Adobe Audition FFT filter to filter out 50hz hum and boost the frequencies of interest. I made a decoder in C# with the flexibility of being able to change the parameters. Sometimes inverting the polarity helped getting the data decoded for example.
Some of the data was too degraded to decode successfully, but I could still differentiate between a 1 and a 0 by looking at the wave pattern zoomed in. That way I could decode the header of 6 characters by hand and have an idea what the data contained.
How did you 3D print rubber belts?
so you ” 3D printed a new set and it came alive again :)”
well, so 3d printing rubberbands is a thing now?
i don´t think you did that thou
So you say ‘A picture or it didn’t happen’. Here you go:
http://www.makercentral.net/media/forum/_MG_0384.jpg
http://www.makercentral.net/media/forum/_MG_0388.jpg
http://www.makercentral.net/media/forum/_MG_0393.jpg
I used TPC flex filament which is similar to poly urethane. It’s very flexible but not very elastic. Elastic enough, when printed with tight tolerances, to work as a belt. The tricky bit was that it shouldn’t be too tight because the tape deck motor isn’t very powerful, which is by design as it would snap the tape when the tape gets stuck. The other tricky bit is setting the retraction just right so no blob is present, which ruins the sound quality :)
I also did such a thing using some rubber filament (I’m not sure what it’s called, I was only given a small amount as a sample, but it’s black and really has that rubber belt consistency) for my reel to reel machine, where the only belt was the one for the tape counter. 4 months and still running.
Belts come out a bit softer than the original ones, but that only matters if one’s going to stretch/break them manually, otherwise they’re completely fine. And I’ve yet to find out if they’ll turn into an awful black goo after 30 years :)
P.S. On topic of old pocket computers, I recently made an Elektronika MK85 emulator. It’s not exactly finished yet, but it works already and I just want to show it off, here it is: http://kp1533tm2.github.io/js-mk85/
It never had a tape interface though, but now it backs up into browser cookies :)
There are a number of Commodore-specific programs to make cleaning up TAP files easier.
I dumped some C64 and VIC-20 tapes in 2011, one of which was only rumored to exist before I found it : )
http://greg-kennedy.com/wordpress/2011/08/19/dumping-c64-tapes/
When I moved from my old Texas Instruments TI-99/4A to a Tandy 1000 SX, I simply re-typed all my code into text files. They have been copied from 5 1/4″ floppies to 3-1/2″ floppies to CDs to DVDs. I haven’t looked at them, though. I’m a digital packrat.
> Why and when would you ever transfer data this way these days?
We actually use a similar method to attach hardware peripherals to smartphones and tablets – very much like those CC readers that plug into a phone’s headset jack. It’s been largely replaced by BLE at this point, but we still support the wired versions.
Ham Radio Digital communications still use a number of protocols that are similar to these. The reason is simple. They are robust and can have a great deal of noise immunity.
Went to fire up Electric Pencil on the old TRS-80, someone taped over it with some Megadeth…
Seems appropriate somehow (though they should have been called Kilodeth in those days)
(Sorry, couldn’t resist :)
The title is bad as what does this have to do with dumping ROM though? Shouldn’t the title be “Dump Your (Old) Computer’s Data Tapes Using Audacity” ?
Neat project though. However, as any tapes that may have had data on them that my family had are long gone (from Timex Sinclair 1000 system), I have no use for it.
Where exactly is ROM involved in this? Dumping a tape program isn’t the computer ROM.
Check out the first link. He uses the computer’s built-in CSAVE function and specifies the memory space where the ROM is attached. CSAVE being the function to copy programs to tape.
I recently backed up my TI-99/4A program tapes. Fortunately, I still have my TI, so that made my process simpler.
Here’s what I did:
– Connected my TI to a cassette player
– Load the PROGRAM into the TI (OLD CS1)
– Connected my Windows 7 laptop to the TI via the cassette cable. Red plug goes to the laptop’s microphone jack.
– On the TI, Start saving the program (SAVE CS1)
– Start Audacity on the laptop, and save the audio to a wav file
– Used the CS1er to convert the wav file to a FIAD file that can be used with emulators
I thought the user memory on a Casio or Sharp PC was NVRAM not ROM. The BASIC interpreter should be on the ROM or EPROM and you can’t dump that via CSAVE command. Why would you decode user data? Why wouldn’t you just archive the raw data via a wave file? I guess decoding it allows you to edit the content via a text editor and then send it right back to the PC via CLOAD. This would make a cool portable modem-like transceiver for radio or POTS. You could set your own data encryption via a piggyback BASIC program… just RUN it after CLOAD. With a audio amplifier you could exploit CSAVE/CLOAD as a through the air audio communicator. In both commands a SPST relay engages for cassette motor. Cool way to deploy a PTT function on a 2-way radio. However, using the LPRINT command via serial interface may be more straight forward. But to receive serial port you’d need to use PEEK which is more complex. Not sure these things used COM port modems back then. If so then much easier to make into a RS232 transceiver.
I discovered that there is a quicker more efficient method of exploiting the cassette I/O for radio transmission/reception or through the air communications (the later is rather noisy though). After looking up the PC-8 BASIC commands there is PRINT# and INPUT#. Both of these commands work inside your program to send contents of your variables to the cassette port (PRINT#). And to get them from another PC-8 you’d let INPUT# listen for them back. The pin-out for the 11-pin jack is available and I have them.
The format of the cassette signal is to activate the SPST relay on the REM port to cause the tape motor to start and stabilize. A long single tone is transmitted before data. Then serial data is sent in a format (IIRC) I think used to be called TARBELL. I believe the data is sent several times for error correction purposes. Tapes were notorious for wow and flutter due to belt problems or battery power. The commands also can be set to look for a particular filename too.
You would not need to use CSAVE and CLOAD for 2-way data communications. PRINT# and INPUT# would be better as they don’t erase the program like CLOAD would do. All you need is to use a isolation capacitor on CASSETTE OUT and IN pins and attach to a 2-way radio mic and speaker ports. The CASSETTE REM relay can attach directly to PTT if all it needs is a simple dry switch closure. No isolation needed (I think). Then you need to build in your own encryption based on the variables used. The variables are very specific as they are supposed to be arrays with only 26 limit. You could just read in the arrays, clear, and display and start over. The 26 limit should not be a constraint.
I also found pin-outs for RS232 DATA IN and OUT. But what BASIC commands used to get at them is a mystery to me. I guess if POKE and PEEK are available on the PC-8 (and it’s sisters) might work.
I forgot to mention… these tiny 1980’s mini-PC’s were only the size of a 21st century SmartPhone. Mine easily fits into a modern Smartphone holster. And it’s cool to be able to program it to do whatever you want within reason. I know my Smartphone makes it look like a dinosaur but if you put your thinking cap on you can find a use for a small device that can do complex maths, beep, and 2-way data communicate with a secret friend with the same setup via the cassette ports. The display is only one line at a time though. And is only monochromatic.How about a slow Morse Code keyer using the CASSETTE REM relay or the BEEP command? Can’t think of a way to decode Morse with it though.
It turns out you can use POKE and PEEK on a PC-8 or PC-3 (Sharp has a equivalent)..You could do a FOR NEXT Loop with a PEEK command from 0 to 2048. You could jump the DATA IN pin to GROUND. Then watch the display for a zero or higher number during loop. Do it again with pin UN-jumped. That way you can tell what changes. If this works you can build a small piggyback board like a NE567 PLL that decodes a remote Morse Code beep and it can close and open a TTL transistor or relay. You’d have to built a BASIC program to decode the slow Morse.
[PC-1 is] Sharp PC-1211 [PC-2 is] Sharp PC-1500 [PC-3/3A is] Sharp PC-1251 [PC-4 is] Casio PB-100 [PC-5 is] Casio FX-780P [PC-7 is] Casio FX-5200P [PC-8 is] Sharp PC-1246Tandy to Sharp or Casio -
Could you use something like GNU Radio to decode the audio stream? Sure, it’s meant for Software Defined Radio, but does it care where the stream comes from?
Many early programmable synthesizers used the “sound as data file” system. Roland’s Juno 60 is one example (I believe)..
I do recall needing to restore the factory sounds and settings for an old analogue synth for a friend, I’m pretty sure that’s what it was.
Really, anything in that short era between the advent of storage and the existence of floppies – there be the tapes.
Are they “ROMs”? idgaf.. Useless debate on the comments, here.
If you call the program game files for emulators ROMs, then.. Yeah, this is the same niche. Semantics don’t belong in hacking old goodies, just have fun.
X
The Pocket-Tools where initially developed for saving/loading old personal software on Sharp pocket computers.
Through the time, contributors added several features, like the support of data block’s save format (most of Sharp pocket computers allow to save data blocks). This allowed other users to easily dump ROM from Sharp pocket computers. These dumps where used in some emulators, like PockEmul (http://pockemul.free.fr/).
This brief history reminder may explain the article title.
Why anyone would use audio based data storage? Well it’s one of the things that you can design from the ground up when doing homebrew hardware.