Date : Wed, 21 Jul 2004 21:26:35 +0100 (BST)
From : Greg Cook <debounce@...>
Subject: Atom half-bits and choice of file format (Was: Re: bbcim/bbctape)
On Tue, 20 Jul 2004 00:05:08 +0000
W.Scholten wrote:
> No, the retro fitting wasn't the problem (did that a year or so ago, and
> wasn't much work). It's just a mess to keep track of where this happens
> etc, and it makes standard tape images inaccurate or compressed
> (depending on one's point of view).
But if your program has observed half bits in the audio signal, there's
nothing to stop you recording this fact somewhere (see below.)
> I don't see why Acorn did this.
> Random single 2400Hz cycles in inter-block gaps I'd say one can just
> forget (my view, see below). But systematic?
Acorn would surely have had good reason to record this half bit. I'm not
an Atom expert but I believe the cycle length is controlled by a VIA
timer, so the CPU should be idle and can run the CRC routine during the
stop bit. Therefore I assume the half-bit is deliberate; either to
improve the reliability of recording on tape, or to be compatible with an
earlier Acorn machine that lacks a VIA.
> Note that the Atom uses
> direct port reading and the only format that can really handle anything
> that an Atom can produce and read is direct wave specification (duration
> of top/bottom sections).
If Speedlock was ever ported to the Atom, that'll be a great solution -
but for 99.9% of the Atom's repertoire, there are more convenient ways and
means <:D
How much information you want to recover from the audio track is a matter
of judgement and compromise. If you are expecting only standard Acorn
blocks, .inf is perfectly fine. To store Acorn compatible cassettes at
the binary level, UEF and BBCTAPE provide several encodings. To cover all
the tape-reading computers ever made, CSW (thanks Thomas!) is the weapon
of choice, and so on.
The point is that these various formats don't have to be strict subsets of
one another. As I understand it you want to save standard ROM bytes, but
also to denote whether they were created by a BBC / Electron or an Atom.
Make it so! Define a custom chunk, or a keyword in .inf that names the
originating machine. On playback the application can insert the
appropriate number of stop bits, cycles etc. after each standard ROM byte.
> For the BBC, if the extra 1/2 bit cannot be detected reliably (for
> protection), then it still wouldn't be really useful to add 1/2 bit
> support in the tape format (I think). I'm inclined to only want to
> represent really useful stuff.
Admittedly, there are no known applications of half bits in software
protection. All instances of half bits seem to be accidents; what Fraser
Ross calls 'security waves' I always interpreted as one dummy byte
interrupted by another. Ah! Could they be generated by the following?
*FX138,0,13
SAVE "PROG"
A BBC could potentially time the interval between ACIA interrupts, to
detect half bits. Historians, though, might be interested in the IBG
length variations, as they tell apart one copy of a file from another, and
reveal whether MODE 7 was being displayed when it was recorded...
> (see BBC ML message: Thu, 03 May 2001 08:10:57 +0000)
Take that, ephemeral Message-ID! I'll be referring by date henceforth...
> Yes, that meant a BBC micro was used in a university level IT class in
> 2003! ;-)
How was it used? As a prime example of firmware design, perhaps?
Greg
___________________________________________________________ALL-NEW Yahoo!
Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com