🚀 go-pugleaf

doriang@microsoft.com (Dorian Garson) writes:

> {Forgive me if this has already been addressed in a FAQ somewhere...}
> 
> So we've got dozens of old relics that have nothing to save/load data 
> to/from but a cassette tape recorder.
> 
> Now, note that a PC clone with a cheap sound card can generate and capture 
> audio signals.
> 
> Proposal: Is it possible to write an app that could capture programs & 
> data from an old computer's cassette interface via a sound card?  If so, 
> could it be architected to accomodate all popular data formats and so that 
> people could add new formats as they're discovered?
> 
> The benefits are obvious: greater reliabilty, limitless, random access, 
> and greater ease in trading/distributing/archiving legacy code for old 
> hobbyist platforms.  Also, those old cassette tapes are losing their bits 
> with every passing year!
> 
> Would anyone want to take this on with me?

It's already been done to some extent for the TRS-80 model I (and
possibly model III). 

Unfortunately, I don't have a "normal" sound card, just the (pretty
decent) sound hardware built into this Tandy 1000 TL/3. So I have to
write my own software anyway.

Given that there *are* different interfaces to various sound hardware,
I think we need to break the problem down into sections:

1. document the various cassette formats
2. come up with software to read one of the standard sampled sound
   formats (*.WAV?) and interpret it according to one of the formats. 

It might even be a thought to define our own sample format. It'd have
to be an uncompressed format, but at the same time, we probably don't
need to save the "normal" sort of dynamic range info. 

In any case, I do think it's best to have software that translates
sound files to program or data files rather than having them go direct
from the sound card to the program/data file. That way it doesn't
matter *what* you got the data into a sound fuile with, just that you
*did*. 

I think the highest bit rate of any of the old cassette formats was
2400 bps or so. That means that we need a sample rate *considerably*
higher so we can be sure to filter out sampling artifacts, and catch
the (very distorted!) waveforms. 8 times higher is probably overkill,
but that is only 19,200 Hz. So 22khz sampling ought to do it. If I'm
remembering wrong and the highest rate is 1500 bps (used in the TRS-80
Model III/4, CoCo, and Model 100/102/200) then we could even manage
with 11 khz (unless I've overlooked something).

I know of the following formats: 

bps	System
------	--------------------------
250	*TRS-80 Model I/III Level 1
500	*TRS-80 Model I Level 2
1500	*TRS-80 Model III
1500	*TRS-80 Color Computer (all models), Micro Color Computer
1500	*TRS-80 Model IV, 100, 102, 200
1200	*"Kansas City Standard"
????	Apple II
????	Pet 2001
????	Vic-20 (may not be readable on standard casstte recorder)
????	C-64   (may not be readable on standard casstte recorder)
????	Atari 8-bit systems
????	IBM-PC
????	Sinclair (various models, do they all use the same format?)

* = I have docs of the format buried *somewhere* in storage

BTW, the Tandy formats are all actually a "protocol" format, and there
are multiple file types encoded with that protocol (BASIC programs,
data files, machine language executables, etc). But if you can do the
"protocol" you can get the files as a stream of bytes, suitable for
feeding to an emulator. Converting them further is an excercise for the
programmer who wants to do the extra work (but worth it for getting
programs and data extracted to use with other systems)


Leonard Erickson 		(aka Shadow)
 shadow@krypton.rain.com	(preferred)	
leonard@qiclab.scn.rain.com	(last resort)