Date   : Mon, 05 Jun 2000 19:36:07 +0100
From   : Steven Flintham <steven@...>
Subject: Re: Wave level tape encoding & adfs disk format

On Fri, Jun 02, 2000 at 04:02:27AM -0700, Thomas Harte wrote:
> The next targets for my emulator are to properly support tape files and
> possibly loading over the soundcard, and to finish the dfs2adfs (it actually
> does more than that, but no matter) converter such that all the bodged
> 'Electron' games on the 'net are loadable.
> 
> However, two obstacles stand in my way - I have been unable to find out how
> the tape files are encoded at the sound wave level, and I haven't been able

I don't know if this is any help, but a friend of mine (Russell Marks)
has written some utilities (in C, written for Linux but probably
fairly portable) to do BBC (and therefore Electron) tape
reading/writing. Let me quote from an e-mail he sent me about them
(with permission):

"Feel free to post them if it helps, but be sure to point out that
they're embarrassingly quick-and-dirty hacks based on other Q&D hacks
(and that recurses another level or two IIRC) which may or may not
actually work, in a suitably moonphase-dependent manner. :-) (I think
they worked well enough when I was messing around with the Electron
though.) bbcget is particularly lame and awkward as I only wrote that
to transfer the Electron ROMs, though again it did work."

I won't post them just now, but if you're interested let me know and
I'll send them on to you. This offer is open to anyone else as well,
of course; if I get more than about two people expressing an interest
I'll probably put them on my web site or something and post a pointer
to them instead. (I could post them here but they're about 6K, which
is probably slightly too big.)

He hasn't mentioned a licence, but if you want to do anything `public'
with them I suspect he'd be willing to release them under the GPL. (A
tiny bit of the code which calculates BBC CRCs - about 10 lines - is
mine, but if that's enough to be a problem from a copyright
perspective I'd be happy to go along with whatever Rus is willing to
do.)

He also sent me a few notes on what he could figure out from
re-reading the code:

"The lead-in tone for each block is 2400Hz, and lasts 3 seconds for
the first block, and 0.6 sec for each subsequent one. The tone is
followed by a zero bit, then the header bytes, then the data bytes.
Each byte is preceded by a start bit, then sent LSB first (yes, LSB
first, this is pretty unusual IME), and followed by a stop bit. So it
goes 1,b0,b1,b2,b3,b4,b5,b6,b7,0. The (silent) gap between blocks is
0.1 sec.

Bit encoding is pretty simple - each bit lasts about 0.833ms, and a
one goes low/high/low/high in that time, while a zero just goes
low/high.

I should also note that bbcsend actually defaults to sending the bits
about 25% faster than the above, which still seems to work (though it
would probably cause problems if you tried saving the signal to tape,
rather than sending directly to the machine). Another, probably more
relevant, way of looking at it is to check what bbcget allows - bit
speeds between 0.625ms and 0.937ms."

I hope this helps.

Steven