...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
-~----------~----~----~----~------~----~------~--~---