[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Write Signal on Disk II Question

ferdimh@gmx.de wrote:

On 17 Nov., 04:00, "Michael J. Mahon" <mjma...@aol.com> wrote:


To improve reliability, you must recover the clock and adjust your
nibble framing *dynamically* during the track, as the Disk ][ Controller
does.


I think I do what the Disk ][ Controller does: Read the data multiple
times and reset the delay every time I get a change. The Disk ][ does
not have a PLL to sync to the data stream.


Actually, it does--that's the genius of the Disk ][ Controller
state machine.

It implements a digital PLL which, using the 2MHz oversampling of
the read signal, locks to a framing which has a high bit set.  This
is why you cannot use the controller to reliably read all zero bits,
since they are skipped when they are the "leading" bits of a nibble.

This zero-skipping mechanism is why sync nibbles work:  they are
written with 9 or 10 bit times, with one or two trailing zeroes.
The fact that trailing (=leading) zeroes are skipped causes the
state machine to come into frame lock with the recorded data.

If you mean that every time you detect a read pulse, you restart
a 4us timer for sampling the next pulse, then you, too, are implementing
a digital phase lock.  But if your sampling rate is not sufficiently
faster than 250KHz or your loop has timing jitter, the reliability of
maintaining lock with the bit stream is compromised.

How do you establish frame sync without post-processing?  When you
start sampling you are in random phase with the bit stream, and unless
you execute a zero-skipping protocol to sync with the frames, you will
not have nibble sync.

The fact that your sampled data shows bit slips suggests strongly
that some timing non-determinacy, like an interrupt or cache miss,
is interfering with your sampling.


I said that I didn't know why speeding up the loop helped. now I know:
The loop which reads the 7 data bits is in correct timing end ends
exactly at the right moment to get the next bit. But the data needs to
be stored before reading the next bit, which also takes some time.


Yes, this must be allowed for and made up in the next loop timing.

You will also have to ensure that your buffer is already in cache
before starting (and associativity--or the lack of it--may create
problems in keeping the track buffer cache resident throughout the
read).


That's why speeding up the read loop helped. Now I added a JMP to
skip  the loop in the last bit, increasing the reliability when
reading data with a trailing 1.


Sounds like you still are going to have reliability problems with
small variations in disk speed--which can happen *within* a track.


I know these happen, but then (I think) only some sectors would be
affected. The errors are spread over the sectors with the error rate
increasing with the track number.


In my experience, the intra-track speed variation is highest on the
*outer* tracks, where disk drag is greatest.


If I look at the read signal of my drive (on track 34) I wonder why
this noise with some data in it can be read at all.


;-)


You can do the clock recover and framing after reading, but you will
need a higher sampling frequency and a software algorithm to recover
the framing from the bit stream.


I'll never get a high enough sample rate using the parallel port.


That was my conclusion, as well.


Well, I have written arm movement code now, and managed to get the
denibbilization working by looking at the original DOS routine.
I own a copy of Beneath Apple DOS, but I didn't really understand the
scheme.


.dsk or .do: 35 tracks of 16 sectors of 256 un-nibblized data, sectors
are ordered in the track as DOS numbers them. No file or track headers.


Thank you! I just dumped the data from my games disk to a file and
wrote it back to another disk using ADT. The copy worked!
The image can be downloaded at http://sbscs.game-server.cc/appleii/disk2pc
..
You'll also find the program and its source code there.

But I think there is no possibility to write a .nib image, since there
is no way to determine if the data was read correctly. And when I read
one disk I get ~30 read errors which is definitely to much.
I still might be able to drop this value but I don't expect to get no
errors at all.
So all the work was of very little value I think.


If you learned something, then it was valuable.  There is no such
thing as a "failed experiment" from a system perspective.  ;-)


And I don't think it's possible at all to read a whole disk without
any error with the original disk ][ controller.


Actually, the Disk ][ Controller can usually read undamaged disks
without any errors.  I once patched RWTS to click the speaker when
an error was detected, and was surprised how seldom an error occurred.

If you think about it, with only an 8-bit checksum, covering only
64 combinations (6 bits) for a 256-byte sector, if data read errors
were very common, then there would be an unacceptable level of
undetected data errors.  In practice, the Disk ][ system is quite
reliable, with "silent" data corruption being quite rare.

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."