Needed: 1 IBM 8" alignment disk.

From: Richard Erlacher <edick_at_idcomm.com>
Date: Tue Nov 30 15:41:33 1999

Please see embedded remarks below.

Dick
-----Original Message-----
From: Tony Duell <ard_at_p850ug1.demon.co.uk>
To: Discussion re-collecting of classic computers
<classiccmp_at_u.washington.edu>
Date: Tuesday, November 30, 1999 2:16 PM
Subject: Re: Needed: 1 IBM 8" alignment disk.


>> It's search algorithm is really funny too:
>>
>> Read Sector <-------------
>> If requested Sector <> address then |
>> If CRC not okay then ---------------------|
>>

It's not as odd as you may think. The CRC is for the ID field, so it's got
to keep trying to read the ID before it can determine whether it should read
the following data field. The controller doesn't have a fixed number of
retries, since the infinite loop, in the designers' opinion, allowed you to
poke around with your instruments looking for the problem, and is probably
as good as any other alternative. Remember, there's a CRC field after the
ID field, AND one after the data field. They both must pass check before
you get a valid sector.

This behavior is, however, quite consistent with a misadjusted PLL, or
whatever other mechanism they're using to extract the clock e.g. one-shots.
If someone has fiddled with the pots on the device, all bets are off as to
its ability to lock on the data. Since the data is synchronized differently
on every sector, it should be easy enough to determine whether lock occurs
just by triggering on the data stream while observing the PLL's oscillator.
Each sector should show a discrete and easily visible acquisition window.
Of course, that won't be the case with a naked but formatted diskette, since
its data and ID fields were written in one fell swoop, with no asynchronism
between sectors. However, if you format a new diskette on some OTHER and
WORKING compatible machine, writing a file to it will be a sector-by-sector
operation which will ostensibly have at least a short transient of phase
change reflecting the difference in phase between the relative position of
the diskette during formatting and during writing not to mention the minor
speed variations. In any case, you should, with your oscilloscope set up
properly, be able to watch a consisten acquisition of the data for each
sector. If you're not getting that, which is what I suspect, then your
error lies in that, the most basic task of a disk interface, without which
NOTHING else having to do with data transfer will work properly.

>> (you get the idea.. and infinite loop for most errors)
>
>Well, assuming it's getting into that loop, there's something to look at.
>Does it find a sector address? Does it match (and should it match --
>don't overlook a possible comparator problem). Does the CRC match? Should
>it? (again, don't overlook a possible problem with the logic here).
>
>Basically, you're in a loop (presumably stuck in some state(s) of a state
>machine). You should be thinking about the following :
>
>What signals can get it out of those states?
>Are they ever asserted?
>
>What events would cause them to be asserted?
>Do those events ever occur?
>What about the logic that detects said events and turns them into signals?
>
>-tony
>
Received on Tue Nov 30 1999 - 15:41:33 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:32:31 BST