5 Feb
2009
5 Feb
'09
8:21 a.m.
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.
Obviously, this is only a solution for reading the disk
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…
5 Feb
5 Feb
12:42 p.m.
melamy at earthlink.net wrote:
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.
If I was going to do this, I'd use a PLL of some description, rigged up as a
frequency multiplier.
Your typical 3.5" drive spins at either 300 or 360 RPM. I'm going to assume
300RPM for the following, because it makes the maths easier...
300RPM is 5 rotations per second.
Say you want to emulate a disc with 20 sectors. 20*5 = 100Hz
But you also need to generate the track index pulse half-way between the
"last" and "first" sector index pulses. So design the PLL to generate
200Hz
from the 5Hz index signal.
Add a flip-flop, a counter, and a few gates. The FF toggles at 200Hz,
producing a 100Hz output. That's the index signal without the track-marker.
Use that to clock the counter, and rig some logic to reset the counter when it
counts up to 20. Also, when the value of the counter is between 19 and 20,
gate the 200Hz clock through to the output. OR that with the 100Hz output and
invert to taste.
Use a one-shot to clean up the trailing edge of the pulse if you deem it
necessary.
Probably easier with a CPLD, but just as doable with a small-ish board of TTL
(the latter being FAR easier to fix when it breaks).
I'd be a bit worried about timing jitter, though... with a reference clock as
slow as 5Hz, the PLL is probably going to take a while to reliably lock onto
the index signal.
Might be an interesting rainy-afternoon project for someone, but not me. The
disc analyser (half-done, third redesign) is eating up all my spare time as it is.
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
1:17 p.m.
melamy at earthlink.net wrote:
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
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…
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…
6:31 p.m.
On Thu, 5 Feb 2009, dwight elvey wrote:
Hi
The plan was to use a 3.5 disk on a H89 or N*, not read them
on a PC.
Some of the older drives had a flywheel. A drill, in indexing jig, a
light and photocell, any you could modify a 3.5" drive to provide 10 or 16
pulses from physically fixed positions, without being dependent on
repeatability of rotational speed.
8:36 p.m.
On Thursday 05 February 2009 09:31:19 pm Fred Cisin wrote:
On Thu, 5 Feb 2009, dwight elvey wrote:
On the ones that I've scrapped out that "flywheel" was also often a part of
the motor. Removing it from the drive showed the reverse side to be a
magnet, sometimes only around the outer edge but often for a major portion
of the radius of the thing, which would make drilling (or mounting any sort
of a sensor) a bit of a problem.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, a critter that can
be killed but can't be tamed. --Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
Hi
The plan was to use a 3.5 disk on a H89 or N*, not read them
on a PC.
Some of the older drives had a flywheel. A drill, in indexing jig, a
light and photocell, any you could modify a 3.5" drive to provide 10 or 16
pulses from physically fixed positions, without being dependent on
repeatability of rotational speed. 
6 Feb
6 Feb
2:38 a.m.
On Thu, 5 Feb 2009, Fred Cisin wrote:
Some of the older drives had a flywheel. A drill, in
indexing jig, a
light and photocell, any you could modify a 3.5" drive to provide 10 or 16
pulses from physically fixed positions, without being dependent on
repeatability of rotational speed.
I don't think that this would work, simply because the motor driver IC
has an internal PLL that controls the motor speed according to the output
of the flywheel sensor, and that PLL is crystal locked (a small resonator
of e.g. 981kHz, 1MHz or 493kHz). In order to change the speed you need to
change that ceramic resonator.
I know that because I've been trying to slightly reduce the speed of a
3.5" drive in order to write long tracks on an Amiga. That is BTW how I
found out that the driver IC I mentioned in an earlier post can do 600 and
720 RPM.
Christian
7:31 a.m.
----------------------------------------
Date: Fri, 6 Feb 2009 11:38:21 +0100
From: cc at informatik.uni-stuttgart.de
To: cctalk at classiccmp.org
Subject: RE: speaking of 3.5
On Thu, 5 Feb 2009, Fred Cisin wrote:
Hi
First we are assumming that the drive already has a switch
for 720K that works.
On the ones I'm looking at, one could glue some equally
spaced tabs on the flywheel and add a opto pickup.
The 3.5 disk always mounts the same relative to the motor
and uses a sensor on the motor to create the index.
The Mitsumi drive I have in my hand right now has
just such an exposed flywheel/motor.
I looked at the Teacs I have and don't believe one
could do this because the motor is mounted differently.
Dwight
_________________________________________________________________
Windows Live?: Keep your life in sync.
http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_022009
Some of the older drives had a flywheel. A drill,
in indexing jig, a
light and photocell, any you could modify a 3.5" drive to provide 10 or 16
pulses from physically fixed positions, without being dependent on
repeatability of rotational speed.
I don't think that this would work, simply because the motor driver IC
has an internal PLL that controls the motor speed according to the output
of the flywheel sensor, and that PLL is crystal locked (a small resonator
of e.g. 981kHz, 1MHz or 493kHz). In order to change the speed you need to
change that ceramic resonator.
I know that because I've been trying to slightly reduce the speed of a
3.5" drive in order to write long tracks on an Amiga. That is BTW how I
found out that the driver IC I mentioned in an earlier post can do 600 and
720 RPM.
Christian
1:29 p.m.
>> Some of the older drives had a flywheel. A
drill, in indexing jig, a
>> light and photocell, any you could modify a 3.5" drive to provide 10 or 16
>> pulses from physically fixed positions, without being dependent on
>> repeatability of rotational speed.
On Fri, 6 Feb 2009, dwight elvey wrote:
On the ones I'm looking at, one could glue some
equally
and uses a sensor on the motor to create the index.
The Mitsumi drive I have in my hand right now has
just such an exposed flywheel/motor.
I looked at the Teacs I have and don't believe one
could do this because the motor is mounted differently.
I was thinking more in terms of the era of the Shugart SA350.
It is true that on the integrated motor/flywheel models the marks would
have to be added or painted on, rather than drilled through the flywheel.
I've never made any modifications to "modern" drives.
In making a 3.5" drive for H80 and N*, is there any compelling reason to
NOT use older drives? (does it have to be less than 1/2" thick?)
Could a combo 3.5" and 5.25" drive be modified to do hard sector 5.25"?
(thus adding 3.5" without losing 5.25" and still fitting stock mounting
locations)
1:48 p.m.
On Friday (02/06/2009 at 01:29PM -0800), Fred Cisin wrote:
In making a 3.5" drive for H80 and N*, is there any compelling reason to
NOT use older drives? (does it have to be less than 1/2" thick?)
Could a combo 3.5" and 5.25" drive be modified to do hard sector 5.25"?
(thus adding 3.5" without losing 5.25" and still fitting stock mounting
locations)
If I can generate these fake index pulses with a circuit that sits between
the drive and the controller, then I figured I could use the approach for
either 3.5" or 5.25". You would conceivably add this adapter between
the original 5.25" drive and controller and then start using 5.25"
soft sector floppies instead of the hard sectored ones.
The really smart guy would have the adapter figure out if an original
hard sector media was in the drive and pass the index pulses straight
through vs. a soft sector media in the drive which then gets the index
pulses faked. Now you can easily copy your stuff from original media
to new even if you have only one drive.
Chris
8 a.m.
Thanks for all the comments and suggestions on this topic guys. I appreciate
it. Indeed the goal was to connect a 5.25" or 3.5" drive with soft-sector
media to an H89 and to my SWTPC 6800 which has a Pertec controller (nearly
same design as the H89, using a USRT as the floppy controller) and then
emulate the 10-hole hard sector media that each requires. The follow
on project was to emulate 16-hole hard sector for a Micropolis controller
I have in a homebrew CP/M system.
I clearly need to be much more synchronous with the speed of the media than
I had anticipated. So, the first change to my design will be to keep
the drives selected and with motor on all the time and then my microcontroller
can track the index pulses.
Dwight makes a good point about the leading edge vs the trailing edge of the
index pulse and I will explore that behavior too.
My fatal mistake so far was assuming that the 3.5" drives and media were much
more accurate in their speed than older 5.25" stuff. It's clear now that
that's not the case.
w.r.t. completely emulating the drive electronically with no moving parts,
the "SVD",
http://www.thesvd.com/SVD/
has a big following in the Heath H-8 / H-89 world and I do have a couple
of them to play with. That's certainly the most practical way to solve
this problem... But I wanted to mess around with floppies still since
they seem more authentic to the usage model of these older machines.
I went down the 3.5" path because that media is still easily obtained
and I have hundreds and hundreds of pieces on hand anyway.
Chris
1:17 p.m.
> Some of the older drives had a flywheel. A
drill, in indexing jig, a
> light and photocell, any you could modify a 3.5" drive to provide 10 or 16
> pulses from physically fixed positions, without being dependent on
> repeatability of rotational speed.
On Fri, 6 Feb 2009, Christian Corti wrote:
I don't think that this would work, simply because
the motor driver IC
has an internal PLL that controls the motor speed according to the output
of the flywheel sensor, and that PLL is crystal locked (a small resonator
of e.g. 981kHz, 1MHz or 493kHz). In order to change the speed you need to
change that ceramic resonator.
I was not trying to change the speed. I was trying to generate a well
synchronized sector pulse to make a 3.5" drive suitable for use on a "hard
sector" controller.
I know that because I've been trying to slightly
reduce the speed of a
3.5" drive in order to write long tracks on an Amiga. That is BTW how I
found out that the driver IC I mentioned in an earlier post can do 600 and
720 RPM.
Would it be any easier to slightly speed up the data transfer rate,
instead?
7 Feb
7 Feb
2:37 a.m.
On Fri, 6 Feb 2009, Fred Cisin wrote:
I was not trying to change the speed. I was trying to
generate a well
synchronized sector pulse to make a 3.5" drive suitable for use on a "hard
sector" controller.
Ok, but you have to make sure that your modifications don't interfere with
the speed controlling circuit, which in turn relies on the index pulse
and/or the pulses that come from the photocell assembly.
Would it be any easier to slightly speed up the data
transfer rate,
instead?
Alas no. The transfer rate is fixed, it can only be changed between 2us
and 4us bit cell widths, the frequency is derived from the internal clock.
Christian
5797
days inactive
5799
days old
12 comments
8 participants
participants (8)
-
ajp166＠verizon.net -
cc＠informatik.uni-stuttgart.de -
chrise＠pobox.com -
cisin＠xenosoft.com -
classiccmp＠philpem.me.uk -
dkelvey＠hotmail.com -
melamy＠earthlink.net -
rtellason＠verizon.net