From: Laze Ristoski (cybernator_at_mt.net.mk)
Date: 2005-08-16 02:25:34
> First of all, the
> amplitude of the actual data far exceeds the noise. The output of the
> tape head is run through a filter which helps reduce out-of range freqs.
Uhm... I'd have to learn how filters really work. Till then, case dismissed.
> Usually a 0 is twice the frequency of a 1.
It really depends on the format but yes, usually a 0 is twice the frequency
of a 1.
> Since only the transitions matter, frequency is being measured, not pulse
> width.
Well, Turbo 250 does it this way: the timer is in one-shot mode and is
restarted
after each _received_ click (each second that is). Then it's checked whether
the timer reached 0 meanwhile. If it did, then the pulse was longer than 263
cycles,
otherwise it was shorter than 263 cycles. So I'm measuring the pulse width
here, not
the frequency, right? Although the frequency depends on the pulse width,
it's
kinda more difficult to measure.
> A byte is usually padded with zeros, to get the clock to
> synchronize.
Not necessarily, Turbo 250 doesn't do that. The format is explained below.
> This is also why the bits are repeated twice.
I still think this is because every second pulse remains unnoticed by the
CPU.
> Check here for a more detailed discussion of magnetic data storage (meant
> for cards,
> but as I said, the process is very very similar.)
> http://www.phrack.org/phrack/37/P37-06
Is this _our_ Count Zero? :)
Ok, the Turbo 250 format. It starts with a bunch of bytes with value 2
(100+),
which are used to synchronize (byte-align). Then follows a count down:
9,8,7,6,5,4,3,2,1, which is used to check if synchronization was achieved.
And then goes the data itself. (note that I didn't mention header blocks,
checksums,
etc. since they are irrelevant to this topic). Every byte is saved as
a stream of SS and LL pairs representing the bits. There's nothing for
control
in-between bits/bytes.
Now the loader reads bit-by-bit and shifts these bits. After every bit, it's
checked whether the value of the byte is 2. If not, repeat. Once it detects
value 2, it starts reading byte-by-byte (nothing is checked until a group of
8 bits is read). If this value is 2, it reads again, and again until
something
different than 2 is read. (this is done in order to skip the synchronization
part). Now bytes are read and they are compared against the countdown.
If the countdown sequence is correct, that means the synchronization was
successful, and the loader continues to read data (again, no control
pulses in-between). Otherwise, the loader goes into bit-by-bit mode
again, and the process is repeated.
Apparently, every extra (noise) click would cause a load error.
Say I've got a byte with value 255 recorded.
163,163 163,163 163,163 163,163 163,163 163,163 163,163 163,163 (lots of
LL's :))
Now assume an extra click appears between the first pair. Say the pulse
width is
80. We end up with: 163,80 83,163 etc...
163+80=243, which is below 263 and is interpreted as a 0. Then 83+163=246,
another
0. Apart that we read some wrong bits, this extra click will cause
misalignment later.
So any kinda of noise must be COMPLETELY eliminated. Nothing in the encoding
really
does anything to compensate for the noise.
As for the first issue, I'm still unsure. Maybe recording the signal from
the
tape (as a WAV or something), and having a look at it could reveal some
clue.
I'll give it a shot.
Regards.
--
Laze
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.