5 Feb
2009
5 Feb
'09
6:20 p.m.
----------------------------------------
Date: Thu, 5 Feb 2009 16:17:12 -0500
From: ajp166 at verizon.net
To:
CC: cctalk at classiccmp.org
Subject: Re: speaking of 3.5
melamy at earthlink.net wrote:
Hi
The plan was to use a 3.5 disk on a H89 or N*, not read them
on a PC.
The difficulty is that the rotational speed of the 3.5 drive
is not constant enough to allow the disk to be reliably read or written,
just taking the current revolution dividing the time up and expecting
the next revolution to be the same. I believe this is what
Chris was doing.
The idea of using a PLL is not to bad but I still think the problem
can be solved with a software version of a PLL.
One would need to experiment a little with the parameters. One just
needs to understand the drives parameters. This is much easier
to do in software than a hardware PLL.
Dwight
I been "listening" to most of this
thread so, forgive me if I already mention an idea that someone has already brought up...
I seem to recollect that when I was working on hard sector floppy drives back in the
Northstar Horizon system days, that the controller only wrote a block of data for each
sector with basically nothing in between. It saw an index hole, wrote the block and then
waited for the next index hole to write the next sector. If you want to recreate index
holes for reading a hard sectored floppy, it seems you could detect the end of data from
the previous sector and then generate a accurate index hole for the upcoming sector. Use
the single index to reset the sector count if you are keeping track of that.
You can also use index for the maker of start and just count off ten
sectors at a 1/rotation rate.
Motor speed for a rotation is fairly stable but must be very close to
speed as in less than a few percent.
However that will not help you read it on a modern floppy controller as
the header and all the other marks
that FDCs (be they 765 based or 1771/1793 based) need to locate data
are not there.
That said if your really out to read NS* disks the format and controller
is fairly simple to subset
and build to be done off the parallel port of a PC for read only and
maybe write.
This is possible as the controller for the S100 had to accommodate a
slow 8080 or z80 (4mhz)
that would be pushing to write a byte every 64/32 uS and do housekeeping.
Of course having a real NS* is far more fun.
Allison
_________________________________________________________________
Windows Live?: Keep your life in sync.
http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_022…
Obviously, this is only a solution for reading
the disk
There are other solutions...
best regards, Steve Thatcher
Hi Chris
I was recently looking at my Teac drive's index pulse to see how it
worked relative to the drive going ready ( the problem of trying to
find a way to recreate the /Ready signal ).
One thing I noticed was that the leading edge of the index pulse
was as accurate as my scope could show but the trailing edge was
all over the place.
My thinking is that the drive is controlled by a servo loop.
The leading edge is when a crystal clock says the pulse is suppose
to start and the trailing edge is when the actual edge is detected.
If one timed the length of time between the two edges, one would
then know the corrective response of the loop.
As an example, if the pulse was long, you'd keep a similar software
wheel rotating that you apply a correction to by the amount the
pulse was long.
It would be this internal software generated wheel that you'd use
to create the index pulses from.
You need the code to watch the drive to determine the parameters
of the control system, gain, dampening and intertia.
If done this way, I suspect that one could get very close to
the right index pulse spacing.
Dwight
_________________________________________________________________
Windows Live?: Keep your life in sync.
http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_022…