3

I got interested in writing my own code to parse tape cassette formats for a few platforms. I did OK with both Spectrum and Apple 2 tapes based on info I could find online.

Speccy and Apple 2 seem to be relatively similar, both using frequency modulation where I can measure the intervals between the places the sound wave crosses 0, with different sized intervals representing things such as leader tone, sync pulse, and 0 bits and 1 bits.

But I've had no such luck with TRS-80 tape audio. I'm focusing on Model 1 Level 2 BASIC saved in .wav format for starters.

I can find info on the layout of the bytes in the tape data, but I can't find detailed info on how the bits are encoded as audio, but it seems use a technique somewhat different to what Apple and Sinclair used.

How can I parse the audio? I'm basically asking the same as has been asked about the Apple ][ in this question.

Here's part of the waveform of a very tiny program with a bit of the leader and all of the data loaded in Audacity:
TRS-80 tape audio waveform in Audacity

Improve this question
5
  • So what data bytes creates that waveform? Looks like just one pulse per bit of some logic state and two pulses per bit for the other logic state.
    – Justme
    Sep 24, 2022 at 13:17
  • @Justme I also have trouble finding an emulator that works with both .wav and .cas or a tool to convert the former to the latter. MAME only supports .wav and the current version trs80gp seems to produce bad .cas files. I sent a message to the author/maintainer. I forget if that waveform is a save of the null program, just doing CSAVE with no program lines, or if it's the program that's just 1 PRINT
    – hippietrail
    Sep 24, 2022 at 13:47
  • 1
    Here is the best detailed description of the format and it's very modern. And it also has an online interactive decoder!
    – hippietrail
    Sep 25, 2022 at 4:40
  • 1
    What an awesome project. Please consider adding Atari support. Complete details available here: atariarchives.org/dere/chaptC.php
    – Maury Markowitz
    Oct 1, 2022 at 15:31
  • @MauryMarkowitz: There is an existing one but even though the code is very clean I can't always follow it plus I wanted to do it just to satisfy my curiosity. Let me find you a link... cassette nibbler and it does already support Atari 8-bit. It's in Java but I didn't try to run it.
    – hippietrail
    Oct 2, 2022 at 8:13

1 Answer 1

Reset to default
5

My initial guess was right.

Many resources on the net says the same thing.

Each bit can be thought to contain a clock pulse and a data pulse. The data pulse is present for a logic 1 bit and it is absent for a logic 0 bit.

So each bit starts with a pulse.

If there is a long period to next pulse, it's a logic zero bit because the data bit is absent, and the next pulse is start pulse of next bit.

If there is a short period to next pulse, it's a logic one bit, and next pulse is again start of a next bit.

Basically, that's approximately the same method how FM is used on floppy controllers. Similar to differential Manchester encoding.

The data stream is: ...00000010100101 110100111101001111010011010001010000000000000000...

Improve this answer
5
  • Ah that makes sense. I saved the same BASIC file twice with just a one-byte change and it changed the number of zero-crossings. I must be getting bad at Googling this stuff because I spent hours hunting. It would be great if you could include one or more links. That 10100101 is the signature I was looking for. I'm surprised you could make out the image well enough. I was worried it wasn't detailed enough to be useful.
    – hippietrail
    Sep 24, 2022 at 13:42
  • I was able to Google some good pages using the keywords "clock pulse" and "data pulse". Interestingly, the first bit in the file and the 8th bit in every byte has a bigger gap between zero-crossings.
    – hippietrail
    Sep 24, 2022 at 16:11
  • 1
    That was actually why I included the space there, because I encountered a mysterious gap I was not sure how to explain, but your finding makes sense. It looked like gap for zero bit but it was after the "data" pulse so it was basically too long gap between data and clock pulse. But yes, the waveform is likely output with software loops, and likely it runs an interrupt or just loads a new byte to transmit, the data stream does not need to be that accurate.
    – Justme
    Sep 24, 2022 at 16:55
  • 1
    I never got to see the waveform, but I wrote routines to write and read this format, and this matches what I remember. Self clocking, one clock bit followed by a data bit or no data bit.
    – Wayne Conrad
    Sep 27, 2022 at 1:04
  • Oh yeah, and no interrupts running to my recollection. Just bit banging in a tight loop with software delays.
    – Wayne Conrad
    Oct 4, 2022 at 0:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.