18 Apr
2009
18 Apr
'09
7:13 p.m.
...and tricking the computer into thinking it's a 5.25" hard sectored
disk...in an H8..
[This is from the sehbc Heathkit list - I figured there may be some
interested in what he's done]
-------------------
On Friday (04/17/2009 at 07:12PM -0700), dwight elvey wrote:
Hi Chris
How did you solve the problem of the speed changes
while the disk is spinning? Several people have tried
to do this so we are all wondering.
Also, have you checked several different drive
manufactures. Each has a little different quality
of speed control. Most all 3.5s are crystal or resonator
controlled so the average speed is usually right on
but the speed caqn drift from revolution to revolution
around that value.
Hi Dwight...
I will admit that this little project took a lot more effort than I
initially expected-- and Carroll W can confirm that!! We were both
working on the problem from different directions. He provided a lot of
info in the beginning which laid the ground work for me.
I use an ATMEL ATTiny2313 microcontroller and make heavy use of one of the
timer/counter units. I have the counter running at 8 MHz/64 = 8uS period.
Then, each time MOTOR ON goes true, I waste two revs of the media
"figuring things out". The first rev is completely ignored as I assume
the media is probably not up to speed yet. The second rev is used to
calculate the speed of the media. I count the total number of 8uS ticks
that occurred over that rev, divide by 200 (one rev should take 200mS)
and the result is the number of ticks per mS in "floppy time".
I then use this value to stage the pseudo pulses starting at the next
real index pulse.
The code is as simple then as,
PulseAt00();
PulseAt10();
PulseAt10();
PulseAt20();
PulseAt20();
PulseAt20();
PulseAt20();
PulseAt20();
PulseAt20();
PulseAt20();
PulseAt20();
where each of those is a simple delay that counts the number of ticks
of the timer/counter to equal the required number of milliseconds and
then it generates an index pulse. The timing is done in the hardware
by the timer/counter unit and I am simply clearing and then polling that
counter to determine when its the right time to move on.
I have tested with three different brands of floppy drives. Two were
a success and one was an abysmal failure. Sony MPF920 work real nice.
Teac FD-235F also work great and Samsung SFD-321B are useless-- because
they have made them so cheap that they do not even support 720K media
any more. The density sense switch is completely missing from the drive,
and they are forced to always run in 1.44M (500kbps MFM) mode. That's a
show stopper since for the H-17/H-88-1 we need 250Kbps MFM mode which is
what 720K 3.5" media uses. I use 1.44M floppies but then cover up the
high-density hole with a piece of tape, which makes them 720K media then.
Anyway, I did a lot of testing... a lot of scoping-- with my digital
scope and logic analyzer and I'm pretty confident this is a reliable
solution. The success with "TEST17" on HDOS was the final sign-off and
that is consistent now with either of the good drives and exchanging the
media between them.
I make no attempt to support multiple drives with one microcontroller--
because they are so cheap, I just put one per drive and then I don't
have to manage state tables for more than one, etc.
I just use the RC oscillator as the clock for the micro too-- so there's
no crystals or osc to wire up. Since it recomputes the tick counter
each time the motor turns on, if the processor clock has drifted, that
gets accounted for in the recalculation-- but my experience is that
these AVRs are pretty stable across typical room temp conditions anyway.
I think the thing that stumped me the longest was that I was not
disabling my INDEX output fast enough when the drive was deselected.
I ended up with a 74LS38 external to the micro to solve this problem--
which then also gives me lots of drive back to the controller and a true
open collector output which can be bussed on the floppy cable just like
any other drive.
Chris
--
Chris Elmquist
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"SEBHC" group.
To post to this group, send email to sebhc at googlegroups.com
To unsubscribe from this group, send email to sebhc+unsubscribe at googlegroups.com
For more options, visit this group at http://groups.google.com/group/sebhc?hl=en
-~----------~----~----~----~------~----~------~--~---
18 Apr
18 Apr
11:54 p.m.
Hey! That's me! and I'm on this list too :-)
Chris
On Saturday (04/18/2009 at 04:13PM -0700), Gene Buckle wrote:
...and tricking the computer into thinking it's a
5.25" hard sectored
disk...in an H8..
[This is from the sehbc Heathkit list - I figured there may be some
interested in what he's done]
-------------------
On Friday (04/17/2009 at 07:12PM -0700), dwight elvey wrote:
--
Chris Elmquist
Hi Chris
How did you solve the problem of the speed changes
while the disk is spinning? Several people have tried
to do this so we are all wondering.
Also, have you checked several different drive
manufactures. Each has a little different quality
of speed control. Most all 3.5s are crystal or resonator
controlled so the average speed is usually right on
but the speed caqn drift from revolution to revolution
around that value.
Hi Dwight...
I will admit that this little project took a lot more effort than I
initially expected-- and Carroll W can confirm that!! We were both
working on the problem from different directions. He provided a lot of
info in the beginning which laid the ground work for me.
I use an ATMEL ATTiny2313 microcontroller and make heavy use of one of the
timer/counter units. I have the counter running at 8 MHz/64 = 8uS period.
Then, each time MOTOR ON goes true, I waste two revs of the media
"figuring things out". The first rev is completely ignored as I assume
the media is probably not up to speed yet. The second rev is used to
calculate the speed of the media. I count the total number of 8uS ticks
that occurred over that rev, divide by 200 (one rev should take 200mS)
and the result is the number of ticks per mS in "floppy time".
I then use this value to stage the pseudo pulses starting at the next
real index pulse.
The code is as simple then as,
PulseAt00();
PulseAt10();
PulseAt10();
PulseAt20();
PulseAt20();
PulseAt20();
PulseAt20();
PulseAt20();
PulseAt20();
PulseAt20();
PulseAt20();
where each of those is a simple delay that counts the number of ticks
of the timer/counter to equal the required number of milliseconds and
then it generates an index pulse. The timing is done in the hardware
by the timer/counter unit and I am simply clearing and then polling that
counter to determine when its the right time to move on.
I have tested with three different brands of floppy drives. Two were
a success and one was an abysmal failure. Sony MPF920 work real nice.
Teac FD-235F also work great and Samsung SFD-321B are useless-- because
they have made them so cheap that they do not even support 720K media
any more. The density sense switch is completely missing from the drive,
and they are forced to always run in 1.44M (500kbps MFM) mode. That's a
show stopper since for the H-17/H-88-1 we need 250Kbps MFM mode which is
what 720K 3.5" media uses. I use 1.44M floppies but then cover up the
high-density hole with a piece of tape, which makes them 720K media then.
Anyway, I did a lot of testing... a lot of scoping-- with my digital
scope and logic analyzer and I'm pretty confident this is a reliable
solution. The success with "TEST17" on HDOS was the final sign-off and
that is consistent now with either of the good drives and exchanging the
media between them.
I make no attempt to support multiple drives with one microcontroller--
because they are so cheap, I just put one per drive and then I don't
have to manage state tables for more than one, etc.
I just use the RC oscillator as the clock for the micro too-- so there's
no crystals or osc to wire up. Since it recomputes the tick counter
each time the motor turns on, if the processor clock has drifted, that
gets accounted for in the recalculation-- but my experience is that
these AVRs are pretty stable across typical room temp conditions anyway.
I think the thing that stumped me the longest was that I was not
disabling my INDEX output fast enough when the drive was deselected.
I ended up with a 74LS38 external to the micro to solve this problem--
which then also gives me lots of drive back to the controller and a true
open collector output which can be bussed on the floppy cable just like
any other drive.
Chris
--
Chris Elmquist
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"SEBHC" group.
To post to this group, send email to sebhc at googlegroups.com
To unsubscribe from this group, send email to sebhc+unsubscribe at googlegroups.com
For more options, visit this group at http://groups.google.com/group/sebhc?hl=en
-~----------~----~----~----~------~----~------~--~---
19 Apr
19 Apr
12:24 p.m.
On 18 Apr 2009 at 22:54, Chris Elmquist wrote:
I use an ATMEL ATTiny2313 microcontroller and make
heavy use of
one
> of the timer/counter units. I have the counter
running at 8 MHz/64
> = 8uS period.
Chris, I did the same thing with a Microchip 12F629 (another 8 pin
uC) but applied to 5.25" drives, passing sector marks through when
present, but otherwise generating 10 sector simulation. I kept my
sampling to 16 bits using roughly that precision for a 167 msec rev
and even timed each rev for the next one as I generated pulses for
the current one to keep track of any long-term speed variations.
Sector pulses were exactly 4 msec in length.
My finding (with the help of Andrew Lynch) was that the rev-to-rev
speed variation on old 5.25" 100 tpi drives was nowhere near stable
enough; if the speed error from rev to rev varied by more than a few
msec., you were dead. With the old open-loop DC tach circuit found
on old 5.25" drives, this was more than likely.
I don't have any systems using HS diskettes here; if someone wants my
code, they're welcome to it; it's PIC assembly and will do both 300
and 360 RPM drives with the ability to generate 32, 16 or 10 sector
marks. The same chip also generates a READY signal for drives that
don't have them.
It was a work in progress and I'm happy that you found a solution
using modern 3.5" drives. My evaluation of 5.25" drives indicates to
me that it would be a far better idea to physically mark sectors on
the hub flywheel, use a sensor to grab them and then use a PIC to
delay them to conform with the positon of the index hole.
--Chuck
1:57 p.m.
My finding (with the help of Andrew Lynch) was that
the rev-to-rev
speed variation on old 5.25" 100 tpi drives was nowhere near stable
enough; if the speed error from rev to rev varied by more than a few
msec., you were dead. With the old open-loop DC tach circuit found
on old 5.25" drives, this was more than likely.
Random though (I've not tried anything like this..) Most of those speed
control circuits used an AC tachogenerator built into the drive motor.
Provided the beld doesn't slip, or you have a direct-drive motor (common
in half-height drives) you should get a constant number of cycles from
that generator per revolution. Could you divide that down to produce hard
sector pulses?
Another random thought.... Most of these hard-sector drives were
single-sided. Most modern drives are double-sideed. How about recording
timing pulses on the normally unused side of the disk and adding extra
electronics to the drive (basiclaly just a second read amplifier chain)
to pick them up and produce sector pulses? Some hard drives used
divided-down signals from the sevo surface for this sort of thing.
-tony
2:55 p.m.
On 19 Apr 2009 at 18:57, Tony Duell wrote:
Random though (I've not tried anything like
this..) Most of those
speed control circuits used an AC tachogenerator built into the drive
motor. Provided the beld doesn't slip, or you have a direct-drive
motor (common in half-height drives) you should get a constant number
of cycles from that generator per revolution. Could you divide that
down to produce hard sector pulses?
It's a possiblility, although it would be drive-specific. As I've
mentioned, I don't have any systems that require HS drives; I just
did this as an exercise.
Another random thought.... Most of these hard-sector
drives were
single-sided. Most modern drives are double-sideed. How about
recording timing pulses on the normally unused side of the disk and
adding extra electronics to the drive (basiclaly just a second read
amplifier chain) to pick them up and produce sector pulses? Some hard
drives used divided-down signals from the sevo surface for this sort
of thing.
Certainly, but again, drive-specific rather than a general solution.
I suspect that there's also considerably more "drag" caused by a
5.25" drive jacket and that it's less constant than what one would
find in a 3.5" rigid-jacketed drive. All in all, a 3.5" is probably
a better choice, but doesn't address the issue of using either HS or
SS media in the same drive.
I also considered an "embedded sector" solution wherein a disk would
be pre-formatted with a unique pattern) that could be easily detected
by external circuitry, conditioned by a timing window. (Isn't that
called an "Address Mark? :) )
Whether or not the system using it would over-write the pattern is
another issue.
But there's more than one way to skin a cat, eh?
--Chuck
3:13 p.m.
Chuck Guzis wrote:
I also considered an "embedded sector"
solution wherein a disk would
be pre-formatted with a unique pattern) that could be easily detected
by external circuitry, conditioned by a timing window. (Isn't that
called an "Address Mark? :) )
The issues as I see them are:
- If you use the B-side of a 5.25" DSDD disc, you need something to write
that formatting
- If you add something to sync to the index marks and generate a
hard-sector "emulation" index pattern from that, you can't put a HS disc in
that drive
What about just detecting the speed of the input index pulse? If they're
turning up faster than, say, once every quarter-second, then bypass the
index-pulse multiplier. Basically have a multiplexer that allows the output to
be sourced from /Index_In, or /Index_Generated.
Whether or not the system using it would over-write
the pattern is
another issue.
True. You'd probably have to jack into WRGATE and force-disable it to stop the
address mark getting overwritten.
And you still need to build something to format these crazy discs. And I'd
appreciate it if someone was kind enough to document the format :)
But there's more than one way to skin a cat, eh?
Depends if you want the skin, the meat, or just a Mythbusters-style big
explosion... <very_big_grin> :)
--
Phil.
classiccmp at philpem.me.uk
http://www.philpem.me.uk/
6:17 p.m.
On 19 Apr 2009 at 20:13, Philip Pemberton wrote:
- If you add something to sync to the index marks
and generate a
hard-sector "emulation" index pattern from that, you can't put a HS
disc in that drive
Not so--it'd work the same way my PIC solution does--while it's
sampling the drive speed (and not passing index pulses) it's looking
for sector holes. If it finds them, it hangs back and allows index
pulses to flow through. If it sees an index pulse every 166/200 msec
or so, it knows to start generating sector pulses on the next rev.
What about just detecting the speed of the input index
pulse? If
they're turning up faster than, say, once every quarter-second, then
bypass the index-pulse multiplier. Basically have a multiplexer that
allows the output to be sourced from /Index_In, or /Index_Generated.
Exactly what my PIC code does. But the base issue is really the ISV
characteristics of the drive's speed control. Direct-drive 3.5"
drives are probably much better than old 5.25" belt-drive drives. I
suspect that consistent speed control issues may have originally
been the reason for NEC specifying 8x512 format for a "360K"
diskette.
--Chuck
20 Apr
20 Apr
1:26 p.m.
I made no attempt to solve this problem for 5.25" media. I went straight
to the 3.5" domain simply because the drives are still readily available
and I have a large stock of the media.
I have tested my solution only with the Heath H-88-1/H-17 hard sector
controller too... so it's possible that that controller is less sensitive
to any speed variation the drive may be introducing. Soon, I'll be
trying a 16-hole variation with a very old Micropolis controller (for
the 1015-II drives) and we'll see if the reliability is repeatable.
I did consider leaving the drive selected all the time, with the motor
running and then continuously watching the speed and using the previous
rev to time the next... but in the end, it seemed I didn't need that
complexity and I am able to let the drive spin down when MOTOR ON goes
false and it still seems to work.
In any case, I make no claim of a universal solution here... just
something that works for the H89 and eliminates a dependancy on the
10-hole 5.25" media. I've got two 3.5" drives in half-height 5.25"
adapters sitting in the same opening as the one full-height 5.25" drive
used to occupy and it looks and works pretty good.
Chris
On Sunday (04/19/2009 at 03:17PM -0700), Chuck Guzis wrote:
On 19 Apr 2009 at 20:13, Philip Pemberton wrote:
--
Chris Elmquist
- If you add something to sync to the index
marks and generate a
hard-sector "emulation" index pattern from that, you can't put a HS
disc in that drive
Not so--it'd work the same way my PIC solution does--while it's
sampling the drive speed (and not passing index pulses) it's looking
for sector holes. If it finds them, it hangs back and allows index
pulses to flow through. If it sees an index pulse every 166/200 msec
or so, it knows to start generating sector pulses on the next rev.
What about just detecting the speed of the input
index pulse? If
they're turning up faster than, say, once every quarter-second, then
bypass the index-pulse multiplier. Basically have a multiplexer that
allows the output to be sourced from /Index_In, or /Index_Generated.
Exactly what my PIC code does. But the base issue is really the ISV
characteristics of the drive's speed control. Direct-drive 3.5"
drives are probably much better than old 5.25" belt-drive drives. I
suspect that consistent speed control issues may have originally
been the reason for NEC specifying 8x512 format for a "360K"
diskette.
--Chuck
5606
days inactive
5608
days old
7 comments
5 participants
participants (5)
-
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
chrise＠pobox.com -
classiccmp＠philpem.me.uk -
geneb＠deltasoft.com