30 Aug
2004
30 Aug
'04
2:02 p.m.
Lyle Bickley <lbickley(a)bickleywest.com> wrote:
|I'll second that.
|
|Lyle
|
|On Monday 30 August 2004 12:49, Vintage Computer Festival wrote:
|> On Sun, 29 Aug 2004, Dan Lanciani wrote:
|> > I've come up with a way to read Heath hard-sectored disks with a
|> > 1797-style controller (with some modifications). I've now archived all
|> > of my old disks with only one unrecoverable error in an unused sector
|> > (not bad for media that is approaching 30 years in age). I do seem to
|> > have run through *drives* at an alarming rate, though I hope that the
|> > cleaning disks I have on order will restore some of them. Is anyone
|> > interested in:
|> >
|> > -Technical details (the method should work for many non-standard FM
|> > formats)?
|>
|> Hi Dan.
|>
|> By all means, please post some technical details.
My plan was to read a track at a time in MFM mode to get both the clock
and data bits which I could decode in software. The first problem was
the index holes. I disconnected the index signal from the drive and
routed the 1797's index input to a bit on an i/o port. (I was doing this
on an H100 so I used the manual precomp line.) With index under software
control I could create a fake hole, read as many bytes of data as I wanted,
and the create another fake hole to terminate the command.
The next problem was clock/data synchronization. Even in MFM mode the
1797 exposes only 8 bits (that is, every other bit) of its 16-bit data
shift register to the cpu. Normally a special pattern with missing clock
pulses synchronizes the register to the bit stream, but of course there
is no such special pattern when reading FM data as MFM. I had initially
hoped that there would be enough random variation such that a few attempts
at reading any given track would result in at least one instance where the
data was in the desired position. Unfortunately, the reading process turned
out to be pretty much deterministic and if a particular run of bits was out
of phase once it was likely to remain so.
To solve the bit synchronization problem I intercepted the raw data input
to the 1797 and delayed each pulse by 2 microseconds with half of a 74123,
using the other half to produce a pulse of similar length to the original
(not that the latter is critical). I then diode-or'ed the delayed bit
stream with the original and fed the result to the 1797's raw data input.
This guarantees that regardless of the clock/data bit phase relationship
to the data shift register, all the bits are available to the CPU. Because
the 1797 uses an external clock recovery circuit the timing of my delayed
pulses does not interfere with accurate clock tracking.
With the raw bits in memory I apply a simple algorithm to separate clock
and data. I examine a bit. If it is a 0 it must be data and I shift it
to the output buffer. If it is 1 I drop it and shift the next bit to the
output buffer whether it is a 0 or a 1.
With the data bits in memory I simply mimic the H17's normal operation by
searching from sync bytes and accumulating bytes thereafter. Note that
the bits in a byte for the H17 are reversed from most other disk formats.
Dan Lanciani
ddl(a)danlan.*com