From: Laze Ristoski (cybernator_at_mt.net.mk)
Date: 2005-08-15 01:20:10
Hi,
Way back when I was experimenting with tape loaders,
there was something I couldn't figure out. A normal
Turbo 250 format uses $107 (263) as a timer value, and
two types of pulses (I refer to the delay between
two clicks as a pulse):
-short: 108 cycles
-long: 163 cycles
(these might not be 100% accurate, but they are close enough)
Two short pulses represent a 0, and two long pulses represent
a 1. This is because the flag line is sensitive to negative
edge (1 to 0 transition), so every second click remains
unnoticed by the CPU. After two clicks, the CPU checks the
nr. of cycles that passed. Eg. 108+108=216 which is below
263 (the timer value), so it's interpreted as 0. Or 163+163=326
which is above 263 and is interpreted as 1.
So far so good, but what if the flag line is misaligned with
respect to the pulse combinations: SS and LL. (I'll explain in
a minute)
This is how a byte with value 2 is encoded on tape:
SS SS SS SS SS SS LL SS
(to avoid potential confusion: SS=short-short, and LL=long-long, and
the space between the pairs is not a delay, I just want it to be readable
:))
The first click in the pair makes the flag go high, the second
makes it go low, and this is where the timer is read. But in
reality you can start the tape anywhere, plus when you press
the Play button there appears some noise. This could lead to
a situation where the first click in the pair makes the flag
go low, and the second makes it go high. So our byte will be
read like this:
SS SS SS SS SS SL LS SS ... Which decoded is 00000110 = 6
Mixing two pulses makes a delay of 108+163=271 cycles (above 263, so
interpreted as 1). The worst part is that SL = LS :) And there's no
way to realign, unless you can tweak the flag input (which is,
as far as I know, impossible and no loaders do that). So in theory
it might occur that a file can not be loaded, unless you rewind
and retry. And the chances would be 50:50. But in reality this
is not an issue. Anyone has an explanation?
Btw, sometimes it's easier to understand by taking a look at a piece
of code, so here goes. :) The proggy reads the pulses from the table
and converts them into bits which are then printed. When aligned
(MISALIGN = 0), you'll get four bytes with value 2 (00000010). Now
try setting MISALIGN to 1, and you'll get the pesky 6. ;)
#include <stdio.h>
#define MISALIGN 0
typedef unsigned char BYTE;
BYTE buffer[]={108, 108, 108, 108, 108, 108, 108, 108, 108, 108, 108, 108,
163, 163, 108, 108,
108, 108, 108, 108, 108, 108, 108, 108, 108, 108, 108, 108,
163, 163, 108, 108,
108, 108, 108, 108, 108, 108, 108, 108, 108, 108, 108, 108,
163, 163, 108, 108,
108, 108, 108, 108, 108, 108, 108, 108, 108, 108, 108, 108,
163, 163, 108, 108};
int main()
{
BYTE ctr=0;
for (int i=MISALIGN; i<sizeof(buffer)-1; i+=2)
{
unsigned short int len=buffer[i]+buffer[i+1];
len>=263?printf("%d", 1):printf("%d", 0);
ctr++; ctr&=7;
if (!ctr) printf("\n");
}
printf("\n");
return 0;
}
Oh, another thing comes to mind. I tried saving some clicks
on the tape with a delay of about 3 seconds in-between, so I could
check how the cassette-read line behaves (using a volt-meter).
But I could easily recognize occasional noise there. Those
extra clicks were certainly not generated by my code. The
tape-drive was far away from any source of interference. So
how come data can be loaded successfully? Obviously this
was very low frequency, unlike data which is saved at
way higher frequency. Does this (the higher frequency) eliminate
the noise? Btw, that noise was generated during the recording process,
since it wasn't random during playback.
(that pesky analog technology :P)
--
Laze
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.