audio cassette storage interface

[saipan59]

I have 2 or 3 portable cassette machines that still work. I'm thinking of building the interface electronics to use one as a storage device. I would use it with my MPU 'sandbox' hardware, which includes a DEC T-11 and a Motorola MC6803. [Not because I "need" a storage device, but just because it sounds fun and nostalgic.]

1) My guess is that the simplest approach would be like what the KIM-1 did (write bits with an FSK tone; use a 565 PLL for reading). It could be real slow, and unreliable.
2) Another approach is like the Commodore PET 2001 - not really an 'audio' signal, but rather more like a 'real' computer tape drive.
3) A third approach is to use a stereo tape drive, and do a 'clocked' scheme, with one channel for data, the other for a clock. I assume it could allow for a higher data rate, and would support arbitrary bit rates.

SO, I'm looking for any other ideas to consider...
Modifying the tape drive is OK - it does NOT need to be 'plug and play' with a generic audio cassette drive.

Once the basic tape interface is decided, one interesting approach to interfacing is to use a UART (rather than relying on software to handle individual bits).

Other ideas??
Thanks,
Pete

[Ed.Kloonk]

3) A third approach is to use a stereo tape drive, and do a 'clocked' scheme, with one channel for data, the other for a clock. I assume it could allow for a higher data rate, and would support arbitrary bit rates.

It seems wasteful to me to dedicate a whole channel just for clocking. At least throw in some CRC, if not just do dual channel data wonderment.

Try and have it that either channel can be connected to either input. I recall the Commodore implementation had an annoying polarity which had to be wired correctly to work.

[pqass]

If you don't want to re-implement the Kansas City Standard (https://en.wikipedia.org/wiki/Kansas_City_standard) because it's too slow, you can use a pair of 4046 PLLs to implement a slower, audio version of this modem: http://ethierd.weebly.com/80khz-modem.html

Experiment with mark/space frequencies and UART bit-rate to fill the available channel bandwidth.  Use XMODEM packetization to detect errors or maybe even implement forward error correction.

See also:
https://e2e.ti.com/support/logic-group/logic/f/logic-forum/743875/sn74lv4046a-fsk-modulation-demodulation-troubles
https://www.ti.com/lit/an/slaa618/slaa618.pdf
https://www.ti.com/lit/an/scha003b/scha003b.pdf

[cfbsoftware]

In the 1970's I built the "Cassette Tape Interface for Microcomputers" to be used with my Signetics S2650 SBC. It was designed by David Edwards and published in a six page article in the April 1977 issue of Electronics Australia. The full circuit diagram, PCB layout and construction details were included. You can download a copy of that issue of the magazine from:

https://archive.org/details/electronics_australia-1977_04

[granzeier]

One trouble with the Kansas City Standard is the use of the 1200Hz and 2400Hz frequencies. After a while of using these interfaces, it became apparent that you should not use one frequency that is a harmonic of the other; the two frequencies can get confused in the receiver circuit.

Dr. Suding, in the July 1976 issue of Byte (https://archive.org/details/byte-magazine-1976-07) page 46 (page 48 of the PDF) presents a faster cassette interface, which also avoids those harmonics issues.

This circuit is more complex, but it provides a better (faster and more stable) interface.

[Circlotron]

Everyone who's been around for a while knows that dial-up modems once upon a time pushed 33600 bps down a phone line using the very limited frequency response of that phone line. Could one of these modems be used instead to feed the same signal into a cassette recorder, and later to receive and demodulate it from the tape at something like 33600 bps?

[Benta]

Your biggest issue will probably be the analog processing with pre/post-emphasis to square up the signal.
For modulation I'd do the same as the Synertek SYM-1, which used Manchester coding for the tape deck. Self-clocking and 4800 bps should be possible.

[saipan59]

dial-up modems once upon a time pushed 33600 bps down a phone line using the very limited frequency response of that phone line.

This reminds me that I have an MC6860 chip, which is a "digital modem", but it only goes to 600 bps... :-(
But it's good 'food for thought' to leverage modem technology.

Pete

[Benta]

Everyone who's been around for a while knows that dial-up modems once upon a time pushed 33600 bps down a phone line using the very limited frequency response of that phone line. Could one of these modems be used instead to feed the same signal into a cassette recorder, and later to receive and demodulate it from the tape at something like 33600 bps?

No. The PSTN/POTS has a frequency range of up to 3.4 kHz.
The V.32 and V.34 modems you are referring to use QAM modulation to go far beyond the normal Nyquist/Shannon rate.
But this requires full amplitude/phase/echo/delay control over the transmission line.
If you remember, setting up a V.32 or V34 connection took around half a minute with strange beeps and other noises. That was the modems testing/analyzing the telephone line and setting up their internal adaptive filters to have the inverse response. In the end, a linearized line appared to the modem, allowing 128-QAM transmission.

I don't see how that can be done with a cassette deck. Sure, you can record a similar equalization sequence and play it back again to set the adaptive filters. It's an idea, but I have my doubts. And you'd be locked to a certain tape deck and cassette forever.

[Phil_G]

The Cottis-Blandford tape interface was (is, I still use mine) very reliable at 2400, and is cheap & easy to build

[pqass]

In searching for the Cottis-Blandford interface (see: page 64 in https://worldradiohistory.com/UK/Personal-Computer-World/70s/Personal-Computer-World-1978-12-S-OCR.pdf),

I stumbled upon this very easy (hardware wise) interface: https://maker.pro/pcb/projects/make-uart-cassette-tape-interface
It uses a gated oscillator (555@4kHz) to produce (on/off) bursts on record and a schmitt trigger+monostable(555) to recover the byte stream on playback.  You may get a multi-kilobit data rate if you use a higher frequency tone (8kHz, 12Khz) but it'll be limited by the variation in tape playback speed. I'm thinking: a start+8bits+stop byte frame, no embedded clock, at least 2 tone cycles per bit.

[saipan59]

I stumbled upon this very easy (hardware wise) interface: https://maker.pro/pcb/projects/make-uart-cassette-tape-interface

In my reading, I notice that the 2-tone system is common because many recorders have an AVC that would be confused by a signal that is on and off (like the simple design that you reference).
However, for my purposes, I would bypass any AVC functionality, and go somewhat more directly to the media.

I'm thinking of experimenting with this approach:
- Interface via a MC6850 UART (I have a bunch of them).
- For TX (writing to tape), each falling edge writes a 'pulse' on the tape. The specifics of the pulse don't matter, except to be as short as the tape will allow.
- For RX, any hi-amplitude signal triggers a monostable set to match the bit time of the UART.

Other than the AVC issue with a generic tape drive (which I can avoid), what are the weaknesses here?

Pete

[Benta]

Other than the AVC issue with a generic tape drive (which I can avoid), what are the weaknesses here?
Pete

The issue is, that your modulated signal has to have a DC content of zero (all audio devices are AC-coupled). Your scheme won't fulfil that requirement.
Manchester coding will.

[pqass]

I just found this writeup on the Apple Cassette Interface (see Appendix C incl. schematic): http://myapplecomputer.net/docs/ACIBuildGuide.pdf

"INTRODUCTION: The Apple Cassette Interface [ACI] is a peripheral device for Apple Computer which enables the user to store and retrieve information using a standard audio grade cassette recorder. .....   The ACI reads and writes data at a rate of approximately 1500 baud. All the ACI timing is done in software, resulting in extreme accuracy, no adjustments, and consistency between units."
TAPE RECORDERS & TAPE: Almost any cassete recorder will work well with the ACI. ....
SPEED: The ACI uses the technique of recording a whole cycle of either 1kHz (representing a 'one' data bit) or a 2kHz cycle (representing a 'zero' bit). Therefore, with an average data mix of one's and zero's, data will be recorded at 1500 baud. A ten second header of all ones will automatically be recorded on the tape prior to memory data. This is to insure that the clear leader portion of the tape will have passed."

Apparently, using a single [square wave] cycle per bit is possible in an audio interface!  Nice sine waves are not required and no need to interface directly with the tape head either.  The read circuit is just a schmitt trigger, although, I haven't a clue why it's being fed into the low address bit (A0) of a PROM.  Woz' wizardry?  I guess your software can just count the width of each pulse read (1kHz=0.5ms=H or 2kHz=0.25ms=L).

EDIT: Here's the PROM contents. See WOZACI.ASM (includes comments) in https://www.sbprojects.net/projects/apple1/roms.zip

See nicer schematic here:

[Phil_G]

Yet another 'mostly software' option (ie no uart) is the Tandy TRS80 / Eaca Genie format, which is well documented on the net.

Going back to the Cottis-Blandford circuit, it has been run successfully at 4800 baud, though 2400 is more suitable for a cheap tape recorder.
The Nascom-2 used Cottis-Blandford at 1200 and was (is) extremely reliable.
C-B can be simplified by omitting the PLL if speed variation isnt an issue, a uart inherently gives maybe 5% speed tolerance anyway.

[Benta]

I've now read the Cottis-Blandford article linked to earlier, and can conclude that it's Manchester encoding. Very complicatedly built, as there's no clock signal from a UART/ACIA. With a clock signal, an XOR-gate is sufficient for the modulator. The demodulator is a bit more complicated.

[saipan59]

Other than the AVC issue with a generic tape drive (which I can avoid), what are the weaknesses here?
Pete

The issue is, that your modulated signal has to have a DC content of zero (all audio devices are AC-coupled). Your scheme won't fulfil that requirement.
Manchester coding will.

Why is that? I understand the concept of DC balance (related to 'neutral disparity' in a high-speed serial link).
My thinking is that a short AC-coupled pulse will pass through the chain just fine, although the waveshape may be seriously distorted (but I don't care about the shape, polarity, etc., since the pulse is just a timing element that is assumed to be shorter than the bit time).
I think the key thing is that a 'pulse' represents only the falling edge of the UART output - there is no attempt to write the actual UART output as-is, which would require neutral disparity as you say.

Pete

[saipan59]

I'm thinking of experimenting with this approach:
- Interface via a MC6850 UART (I have a bunch of them).
- For TX (writing to tape), each falling edge writes a 'pulse' on the tape. The specifics of the pulse don't matter, except to be as short as the tape will allow.
- For RX, any hi-amplitude signal triggers a monostable set to match the bit time of the UART.

I just realized that I over-simplified the plan here. It's not just falling edges that need to be captured -- sometimes the timing of rising edges are needed also.
SO, perhaps the scheme should be that a pulse represents a *transition* (high or low), with the understanding that the idle state is high. It's easy to do a bi-directional edge detect with just a a couple of gates, and produce a pulse that is always the same [Trivia: When I would occasionally interview new-hire candidates, one of my test questions was to show a simple 2-gate edge detector (with just an XOR and inverter), and see if they could explain what it does.]

Pete

[Phil_G]

I've now read the Cottis-Blandford article linked to earlier, and can conclude that it's Manchester encoding. Very complicatedly built, as there's no clock signal from a UART/ACIA. With a clock signal, an XOR-gate is sufficient for the modulator. The demodulator is a bit more complicated.

Sorry but thats not right, Cottis-Blandford is a simple modulator/demodulator using FSK with 2400hz mark, 1200hz space, it has no intelligence for Manchester and simply outputs (or detects) tones based on the logic level of the connected UART output. Its simple Kansas-city or CUTS format. The demodulator is simplicity itself, - just a retriggerable monostable that times out on a 1200hz cycle but is retriggered by 2400. The text explains how a master 4800 clock is divided by four or by two to give the high & low transmit tones. On receive, rather than using the same clock as the uarts transmit, it recovers the clock from the audio tones using a PLL to give greater tape speed tolerance than that inherent in a uart. If speed variations arent a problem then the whole PLL section can be discarded, leaving a cassette interface as simple as it could be!
In a nutshell, its a simple modem, converting levels to tones and vice versa, and simply follows the uart output. Mancester coding doesnt come into it at all!
Cheers
Phil

[pqass]

I'm thinking of experimenting with this approach:
- Interface via a MC6850 UART (I have a bunch of them).
- For TX (writing to tape), each falling edge writes a 'pulse' on the tape. The specifics of the pulse don't matter, except to be as short as the tape will allow.
- For RX, any hi-amplitude signal triggers a monostable set to match the bit time of the UART.

I just realized that I over-simplified the plan here. It's not just falling edges that need to be captured -- sometimes the timing of rising edges are needed also.
SO, perhaps the scheme should be that a pulse represents a *transition* (high or low), with the understanding that the idle state is high. It's easy to do a bi-directional edge detect with just a a couple of gates, and produce a pulse that is always the same [Trivia: When I would occasionally interview new-hire candidates, one of my test questions was to show a simple 2-gate edge detector (with just an XOR and inverter), and see if they could explain what it does.]

Pete

I needed to visualize how a single tone (on/off bursts) or two tone (each bit is either a 1kHz or 2kHz cycle) would work.
So I simulated the following streams (see screenshots below): 
    01010101 where 0=one 2kHz cycle  1=one 1kHz cycle
    0b0b0b0b where 0=one 2kHz cycle  b=silence for 1ms
    00bbb0b0 where 0=one 2kHz cycle  b=silence for 1ms

I think it would be much easier to implement the two tone scheme by just interrupting on the falling edge of the comparator and counting clocks until the next falling edge (0.5ms=L, 1ms=H, allow +/- 20%; interrupt latency <2us on a 16MHz ATMEGA so it's inconsequential).  Each bit is delineated so timing error doesn't accumulate over multiple bits nor would you need to determine how many "silence bits" (no tone) occurred in a repeating bit sequence or when you've reached the end of frame (stop bit; hmm... start and stop can't both be represented as a tone).   I'm not smart enough to figure out a hardware-only way to identify the two different bit timings (with flip-flops and gates) into a constant bit rate stream to feed directly into a UART.  This looks like a perfect opportunity for an ATTINY85!.

You could probably double the average data rate to 3kbps by using 2kHz/4kHz tones.

Attached you'll also find a zip of simulation details.

[saipan59]

I needed to visualize how a single tone (on/off bursts) or two tone (each bit is either a 1kHz or 2kHz cycle) would work.
. . .
I think it would be much easier to implement the two tone scheme by just interrupting on the falling edge of the comparator and counting clocks until the next falling edge (0.5ms=L, 1ms=H, allow +/- 20%; interrupt latency <2us on a 16MHz ATMEGA so it's inconsequential). 
. . .
This looks like a perfect opportunity for an ATTINY85!.

Thanks for that! I agree that many things become possible if using a modern MCU (such as using a fast ADC to perhaps process raw read data in real-time, and avoid almost all HW outside the MCU?).
But part of the goal for me (on many of my projects) is to re-live vintage technology solutions. As I mentioned in the first post, the processor here would be an MC6803 running at 1 MHz, with a 6850 UART.

That said, I also like to do projects that are a weird mix of technologies - for example, I've built a couple of clocks that combine a modern MCU with a vacuum tube time base oscillator.

Pete