Audio Cassette to Bluetooth Interface (both ways)?

[NoLand]

We all know some vintage computers with built in cassette drives, like the original PET 2001, the Sharp MZ-80, later Sinclair Spectrum, Amstrad CPC, etc…
While data input may be easily accomplished from modern machines by the use of bluetooth cassettes for car radio, I was wondering, is there any kind of solution for the reverse, recording data to a modern device w/o an actual tape (by reading the signal from the tape head and transmitting it via bluetooth as an audio data stream)? Has anyone tried something like this?

In my particular case it’s about a Sharp MZ-80, which doesn’t feature any kind of secondary audio port, but just the internal cassette drive. So there’s no way to connect via a headphone jack or similar, short of taping into the signal going to the recoding head. (Transmission rates are rather fast, so that MP3 isn’t good enough for encoding audio files for data input, which is also why disk drives never caught on for the Sharp MZ family of machines.)

[bdk6]

Not sure if I completely understand what you are after. It seems you want to record the signals that would normally go to the cassette onto some modern recording media, or perhaps on a PC. If my understanding is wrong, please let me know.
In the Commodore world is common. There are cables that attach from the cassette port to a PC and some microcontroller devices that record the signals onto flash. Of course, the Commodores have digital cassette ports. I believe some other machines with audio in/out jacks for cassette have similar devices, typically using the sound card on a PC. I haven’t had occasion yet to do it myself.
However, with a built-in cassette it will be a bit different. You will need to “tap in” as you say to the signals inside the machine. At the tape head is probably the least desirable place. Where the signal is generated and received is probably better. How to go about that depends a lot on whether the tape is recorded as audio sounds (like most external recorders) that generate audio tones for each bit (such as 1200/2400 hz) or is digital like the Commodore machines. I’m not sure why you say MP3 wouldn’t be suitable. Audio recording data onto cassettes was almost always intended to work with cheap recorders that have nowhere near the frequency response of (typical) MP3 files. If the recording is digital, recording it as an audio signal would be way more trouble than it is worth no matter; a digital recording would be much better (such as an arduino with SD card.)
If you want a good solution, I would tap in where the serial digital data is converted to and from whatever is stored onto tape and record the serial bit stream as digital data. That would probably be easiest and most efficient, whether you store it on a small controller/sd card or on a PC.

[NoLand]

So, here’s a bit of detail: The Sharp MZ-80 uses pulse width modulation (PWM) with a clock input of 3.5 MHz (cycle period 285.7 nanoseconds). The resulting data rates are nearly comparable to a Commodore floppy drive and the common recommendation for digital audio data files for the machine is to use WAV and not MP3. (MP3 has a bit of a lag in the encoding and the fidelity may be just not good enough as this introduces parasitic modulations.) Unlike the PET 2001, the MZ-80K doesn’t feature a secondary, external cassette port or similar. (Instead, there’s just a generic port, much like the C64 userport, to connect to an external, optional I/O box, to which floppy drives, punchcard readers – yes there is one! –, etc, would be connected. However, this interface is poorly documented. That later machines of the series did away with the need for this interface doesn’t especially help.)

On the other hand, the data format for serial cassette data is well documented, cf.
https://www.sharpmz.no/articles/the-mz-series/mz-80/mz-80-knowhow/mz-80-tape-data-structure/

For a hardware interface, there had been a solution for later MZ machines and DOS, but this was for later MZ-series machines and misses specifications for the hardware side of the MZ-80K. (Moreover, having to do this in DOS may be a bit of a hassle by now and starts to resemble a Rube Goldberg device – or Heath Robinson, if you prefer the British version – more and more by adding layers of emulation and the need to traverse virtual file systems.)
Compare PC tape interface

Taping directly into the serial signal may be still an option, but I was just wondering whether there was a non-intrusive option, just like what is commonly used for input (i.e., interfacing with the tape head by a bridging device). Moreover, this would mean to go from serial/RS232 to some kind of wireless interface in order to interface with the outside world, possibly involving cutting the metal case for a DB9 connector.

(P.S.: The Sharp MZ-80K started Sharp’s tradition of “clean machines”, with just a basic monitor in ROM, requiring the user to load a language or compiled object file from tape first. Also, it was meant for both business and home use, which made fast tape I/O a requirement.)

[bdk6]

Encoding lag makes sense, but I don’t see why that would really cause a problem. Nevertheless, for the amount of data compared to modern storage it doesn’t matter anyway.
If you want to make a project of it my recommendation would be stick something like a $5 Arduino clone inside the machine, connect wires wherever you feel most comfortable. The tape head would work – you could use the A/D converter if necessary (if it’s fast enough). You could send data in/out over the USB/serial if desired or for a wireless solution get a cheap bluetooth (or other) shield and keep it all inside the machine, unseen by observers; pay no attention to the man behind the curtain.
I am only vaguely familiar with those machines, but they are interesting. I’ll be interested to see what you end up doing.

[EdS]

If you search for [cassette adapter for audio out] or similar - perhaps put the word ‘car’ in there too - you’ll see there are passive devices with a 3.5mm stereo jack at one end and a cassette shell at the other end, with a thin or flat wire between them. I imagine there’s not much inside other than a pair of coils to sit next to the head. The point of these is to support ‘PLAY’ but it might be that they can also support ‘RECORD’ operation.

These devices are pretty cheap. I wouldn’t be surprised if you’d need a lossless and high fidelity recording, because the PWM signal isn’t much like music (not much like my kind of music) so the lossy formats might not round-trip very well.

Here are a couple of possibly-relevant videos:

[NoLand]

I already searched for such a device, but either these do not exists or they become buried by all the passive playback devices in search results. I guess it’s the former, since – as you wrote already – these are primarily meant for car radio and there’s no recording capability in those. (I simply can’t imagine a use case outside of retro computing, and even there it’s just about a small handful of machines.)

So it would be most likely about facilitating some of my own, but my knowledge of electronics is simply not good enough for this. I would be able to follow some blueprint, but I probably can’t come up with a design of my own. Which is, why I thought, “Maybe someone has done similar already?”…

And yes, the PWD is picky, I had one (cheap) standalone playback cassette-like device (with a memory card) which didn’t work at all.

[EdS]

My thinking is that, if these cassette-proxies are passive, they should work for recording, much as a speaker can be pressed into service as a microphone.

[NoLand]

That’s my thinking, too. Probably some coil/inductor would work both ways. But then, what are the specs and how to interface with it? Do I need amplification? Multi-stage amplification? Where does distortion kick in? This is analog audio stuff! And, if I get this working, there’s still the digital transmitter part. Probably, I’d opt for local buffering of the entire file, since all modern stuff is notoriously laggy, and, I guess, accumulating the file first and transmitting/receiving it in one pass may make things simpler. But, maybe (or rather, quite likely) there’s a chip out there, which does this all for me, but I do not even know that it exists? – I’m simply not qualified for this. And I lack the equipment. (An oscilloscope will be probably required.)

On the other hand, the lowest of requirements is the simplest of telephones with an alternative speaker/mic arrangement, which shouldn’t be too much of a wizardry. People did this 100 years ago…

[bdk6]

Telephones are limited (intentionally) to 300 hz to 3000 hz frequency response. For this application you probably need a nice, flat response up to around 10,000 hz. I won’t bore you with how I came up with that number unless you ask
Any magnetic transducer (tape head, transformer, whatever) that interfaces with the head in the tape deck will need similar response. The circuit will also be dealing with two VERY different signal levels. The recording signal will be MUCH stronger than the required playback signal. Some kind of circuitry will be needed to provide and isolate those two signal levels.
I still think an arduino stuck inside the machine would be easier and cleaner. But that’s just me

[NoLand]

That I’d need more than double the clock rate producing the signal that I do know. Also that recording and playback levels are different. (Is there a common divider?) However, I happily admit that I do not know the least to know where and what to actually start worrying about.
So I’m probably not the inventor of this ingenious device…
Also, it may be one thing to come up with a minimal solution that suits the particular signal detection, but it may be preferable to come up with something that is similar to the standard WAV-files for these machines, which may be yet another story. However, it was a nice thing to have.

[EdS]

I’d just connect the tape adapter to the mic input of a PC and run Audacity to capture the waveform. You can then inspect and process the signal fairly readily. There’s a spectrogram view in Audacity which is quite good at seeing data blocks, and of course you can look at the waveform to see if the pulse trains have been well-captured.

[bdk6]

Recording the output signal should be fairly easy and accurate. But reproducing the signal expected from the playback head is a different story. I would recommend comparing the signal from an actual cassette in the drive to one played back from the PC.
Here is a paper that explains about digital recording and shows waveforms as they come back from the playback head, compared to what was sent to the record head.

EDIT: Of course, you could just try it

[NoLand]

Wouldn’t there be diodes or similar preventing the signal from feeding back into source device?

(Also, for current spacial arrangements, I’d prefer a wireless solution, where an approach like this wouldn’t work at all. However, this may be probably solved in other ways. – I like the design of the machine that much that it’s sitting on its own place, much like an exhibit, but, besides enjoying its sight, it may be worked on there too. But there isn’t much room for any other device next to it at the moment. However, there was meant to be a much longer sideboard right from the beginning and this is still the – ahem – “temporary solution”.)

@bdk6 thanks for the link to the paper (oh, Ampex)!

[bdk6]

Probably not diodes. Maybe some resistors / capacitors. But what I intended was to read the signal from the playback head as a) a real tape is being played, and b) when the tape replacement box was being used to get a signal from the PC. The signal that comes back from the playback head will most likely look a LOT different than the one you sent it. It’s the physics of electromagnetism: the head only gives a voltage when the flux on the tape changes. W/hen it is constant (either way) the voltage out will be zero. An audio recording playing back into it will most likely look considerably different. If it is different enough to cause a problem is an open question.
You might have a look at some of the Commodore solutions. The Commodore tape recording method is very similar.
Just to get one more whack at a dead horse, I still think an internal solution with microcontroller and wireless board could be buried inside the machine and solve the whole problem beautifilly.

[xmanmonk]

I just saw an ad yesterday for a walkman-style cassette player with bluetooth. Not sure if it records, tho, and I can’t remember any details. Sucks getting old.

[EdS]

Nice paper @bdk6! There are two kinds of differences that might be worth making explicit: the difference between using audio equipment for tape storage, versus using data-only equipment; the difference between pulse-coded tape storage systems like Sharp’s, Apple’s and Commodore’s, versus the tone-coded tape storage used by Acorn and (I think) Ohio Scientific, as Kansas City standard or variations thereof.

According to beebwiki, the signal path from computer to write head to tape to read head to waveforms will typically include several differentiations, which at any given frequency show up as phase shifts. It might be that pulse-timing systems like Commodore’s or Sinclair’s are immune to such considerations: they look for a flux change, wait a bit, then look for a second flux change. If an edge becomes a pulse that might not be detectable.

[NoLand]

So, for everyone interested (I guess, for the moment it’s more an intellectual exercise), here are the relevant parts of the Sharp MZ-80K service manual.

Turns out, the tape unit is connected handily by a cable with read, write, motor and sense wires, which should allow to tap into this. Some pragmatics are not documented, e.g., is the tape verified after write (I don’t think so – there’s no connection to rewind)? What does the sense signal sent back from the tape unit look like (this is for detecting button presses)?

Generally, there are two copies of the data written to tape and on read the computer will stop after the first copy, if there’s no error. Transfer speed is 1200 bits/sec, pulse width modulated (PWM).

Here are the general specs:

And this is the schematic on the CPU board side (mind the 4 signals):

And this is the tape unit’s side of things, regarding the interface:

These are the waveforms for the various points (for tapping into this, we may be interested in 7 for write and 6 for read):

If we were trying to listen to the tape head, it’s all about waveform 10.

Finally, here’s what’s on the tape unit, a single amplification stage for recording and a 3 stage amplifier for playback (the waveforms on the left should be 6 and 7 as above), the sense signal is +5V:

I guess, it should be possible to interface with this using an Arduino and connecting from there by normal serial to a PC/Mac. The interface would have to listen for the +12V motor signal and answer by the +5V sense signal (apparently, this is just continuously HI), from there, it’s serial by PWM square waves. (If I’m reading this right, 1.5V peak to peak for write and 5Vpp for read.)

Edit: It may be tempting to communicate just by serial, however, we’d still need to send normal audio for loading programs from WAV files. (Otherwise, we would have to write a decoder for this and then send the bits over serial.)

P.S.: Source, https://original.sharpmz.org/mz-80k/download/sm80k.pdf

[NoLand]

@xmanmonk

I just saw an ad yesterday for a walkman-style cassette player with bluetooth. Not sure if it records, tho, and I can’t remember any details. Sucks getting old.

Yes, I’ve seen this too, but it’s for playback only. But it made me think about this again…

[bdk6]

The hardware interface is extremely simple. The “sense” input most likely let’s the computer know when the “play” button has been pressed/is down. The bitstream in and out is square waves of approximately 1000 / 2000 Hz for ones and zeros. An Arduino or similar could easily record this and play it back directly, up to whatever memory resources it had (an sd card would provide more storage than you could ever use.) But if you want to send it to a PC, there are plenty of ways to do that. Bluetooth is one. I’m not sure why you are focused on .wav or audio type files. If you are recording the sounds produced and expected by those computers that used standard audio cassette recorders then sound recordings make sense. But for a digital recorder, not so much. It would be really simple to have the Arduino send a “1” character for a 1 bit, and a “0” character for a zero bit, and save it in a text file on the PC. Any terminal program could do it. Then when the text file is played back over the connection, the arduino puts out one pulse length for a “1” and the other for a “0” character.

[NoLand]

See also my remarks at the bottom of that lengthy post. The beauty of the sense wire is, BTW, that this would allow us to communicate with the PC and to bring up a file dialog, before sending the ack to the CPU board.

Why WAV? Because this is how programs (and languages – there are several versions of BASIC, Fortran, etc – and mine came without any cassettes at all) are typically shared. Remember that this is a “clean machine” with practically nothing in ROM and we have to bring in some software to make any use of it. However, it may be still preferable for its simplicity to go all digital and decode or encode this to and from audio as needed on a PC/Mac. As an enhancement, we may even add some storage in place on the interface board and have some facility to select a file and save the roundtrip to the PC.

An other argument for WAV: I’ve an old 32-bit iPad, which is slowly falling out of use as more and more websites aren’t serving compatible code and there’s no way to upgrade the browser. This would make for a great and comfortable file store and selector as long as it’s all audio. With digital/text via serial terminal, I’m not so sure. (Also there’s no iOS version with general file access for 32 bit, this came only later.)