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.