# What format was used for Exidy Sorcerer cassette tapes?

The Exidy Sorcerer personal computer could use audio cassette tapes for program storage. In what format were programs (and data?) stored on tape? What was the data rate?

I seem to remember the tape format was a bit squirrelly, cassettes could be read on some tape recorder-players, but not others. Or one had to play data on the same recorder that was used for recording it. What could cause this problem?

• The reliability of the tape routines in the ROM monitor program was really pretty good. Yes, you had to find the right volume level on the cassette drive, but after that I didn't have any problems on either the stuff I recorded myself or on commercial programs. However, the tape routines within the Microsoft BASIC ROM cartridge sucked to the point I found them unusable. I also had the assembler PAC and the word processor PAC, and both of those had reliable tape routines as well (or maybe used the ROM monitor ones). – RichF Jul 21 '17 at 16:24
• To clarify about the Exidy ROM Pac BASIC, it was fairly reliable in loading and saving programs. The weakness was the tape access routines within programs. I forgot the exact keywords, something like INPUT$and OUTPUT$. (IIRC, we were also supposed to have GET$and PUT$, but I'm guessing those were so unreliable for tape, they were dsabled.) One could write and later reread data to/from tape, but you could expect to have to try multiple times for good data back. Microsoft's response to users was, "You aren't our customers. Exidy is.". That was when my initial dislike of M\$ started. – RichF Jul 22 '17 at 22:39

A quick glance at the 'Theory of Operation, Tape Interface' section of the Exidy Sorcerer Technical Manual reveals that at 300 baud a 0 is encoded as four cycles of a 1200Hz square wave and a 1 is eight cycles at 2400Hz. At 1200 baud a 0 is half a cycle at 600Hz and a 1 is one cycle at 1200Hz tone. Or, if you prefer, at 1200 baud the output level is always toggled once at the start of the bit, and if the bit is a 0 then it is toggled again halfway through.

There is built-in circuity to soften the sharp edges of the square wave before it gets to the tape recorder when heading outwards, and filters to remove low-frequency and high-frequency noise when audio is coming inwards. It uses a bi-directional edge detector to recognise waves — so it's looking for zero crossings. It's timing between each transition of the input signal from high to low or vice versa; whether high or low is factored out.

It doesn't expand on how bytes are encoded in bits other than to say that the bit stream is assembled by an AY-3-1015 UART, and its data sheet advertises that "all characters contain a start bit, 5 to 8 data bits, one or two stop bits ... and either odd/even parity or no parity". So at least one start bit and one stop bit in addition to byte contents plus potentially a parity bit.

From the written material, that sounds like it should all be pretty robust. Bytes are framed, reading isn't relying on phase, there's an attempt not to send square waves directly to the recorder (sending directly can produce function-of-frequency phase errors), what amounts to bandpass filtering of input, and the three frequencies involved — 600, 1200 and 2400Hz — are neither very low nor very high.

The same document's suggestions for troubleshooting suggest that problems can arise from noise in the tape recorder from its own power source, and that "marginal performance may be due to out of tolerance parts in the input filtration train, especially the second order linear phase high-pass filter". That's a filter that attempts to eliminate any signal below 300Hz. Given that electricity is 50Hz in the UK, one would dare imagine that both together imply that low-frequency noise is a problem.

So as to the second part of your question, I'm going to answer that different tape players have different power-source background noise, and that the high-pass filter the electronics were built around perhaps wasn't as reliable as it should have been.

• It strikes me a few hours later: the 1200 baud format is exactly the FM/single density encoding scheme for floppy disks. Always a clocking transition, with or without an additional intermediate transition as per the value of the bit. Left as a comment, as not directly relevant. – Tommy Jul 21 '17 at 0:22

Much useful and relevant information is here:

https://www.toptensoftware.com/tapetool/

"""Tape Tool 2 (aka tapetool2) is a command line utility for converting and repairing Microbee, TRS-80 and Sorcerer audio tape recordings.

TapeTool2 might also be useful for other retro tape recordings - especially those that are similar to the Kansas City standard but hasn't been tested in these cases."""