[sebhc] hard sector substitute

[melamy at earthlink.net]

*You might find it worthwhile to study how PLLs work. They are not
*digital circuits; they *do* make corrections dynamically, within one
*rotation. It is usually digital systems that have trouble matching the
*performance of a PLL, rather than vice versa.

the PLL still does not have feedback to adjust ANYTHING between index
holes. All it can do is keep things constant until the next index hole
which is hardly adjusting things dynamically during a single rotation

> the PIC could adjust it's time base on data coming from the drive
> too so index hole position would be more accurate even during a
> single rotation

*This is a good idea, and may work for reads. But there's a catch-22
*here: You need to know the speed to read the data accurately.

You still know what the optimum speed of the disk should be.

*the saving grace for the Heath H17 format is that it is single-density;
*the pulses alternate clock-data-clock-data; while the data pulses may or
*may not be present (depending on whether it is a 1 or 0), the clock
*pulses are always present. So, it might be possible to extract the clock
*during reads (coasting over the sector gaps), and use it to figure out
*the rotational speed to create the sector holes.

a clock/data separator is quite doable and could supply feedback for speed
adjustments. Won't be there for a blank disk though...

>> Except that soft-sector disk controllers extract the clock from
>> the data

> non-issue for hard sector disks - the only issue is when the
> index hole happens and data starts being read or written.

*If your PIC is trying to create fake hard-sector holes so a Heath H17
*controller can read them even from a physically soft-sector disk, then
*the rotational speed of the disk drive is *still* a problem. If it's a
*newer 5.25" or 3.5" drive that only rotates at the faster speed, how are
*you going to slow down the data so the H17 controller can read it? The
*only option is to read the data with the PIC, and then re-transmit it at
*a slower rate -- possible, but a real software challenge.

The task was not focused on making new floppy drives work (not to say that
the drive itself could not be modified...).


> same idea as serial data streams used in RS232

*Except that RS-232 uses crystal-controlled clocks, so speed is
*extrememly accurate.

there are still variations between machines. The idea is the same in that a
clock deviation will manifest itself into bit errors (after so many bits)
during a synchronous data stream being received by something that has a
slightly different rate.

> at least for N* that we are talking about, the controller gives
> the drives more than a second to come up to speed, so the lock
> time is not a problem.

*Suppose you are copying files from one H17 to another H17 disk. The
*device that is creating the fake sector holes has to wait for a pair of
*index holes (one full revolution) each time it switches disks. So, while
*my hardware circuit worked, it was slower than real disks because of the
*extra time the H89 spent waiting for the disk to get "up to speed"
*(really, for the PLL circuit to lock in and start producing valid sector
*pulses).

that would certainly be the case if you had one PLL for all the drives in
the system. It would be interesting to use a PIC for each drive and
incorporate a little logic to keep the drive active and synched for some
default time as long as at least one drive is still being accessed in the
system. Of course, a few extra parts to "isolate" drive signals that could
disrupt a drive that isn't being "really" accessed.

>> I'm sure a PIC could do it, but it is a *challenging* software
>> problem in real-time control!

> that is what makes it fun to do and quite up my alley so to speak
> given my decades of hardware and software development in real-time
> control.

*Great! That is just the sort of experience you'd need. Too many
*programmers are clueless about real-time control.

Not a programmer... electronics engineer - a couple of reasons why:

I was interviewing with Mentor Graphics for a Field Representative for
their CAE design systems. They needed someone who knew hardware and
software. When I was asked if I was a programmer, I responded yes. I
certainly had the software background at that time to write any type of
software. I was told later by a friend that I had blown the interview. If I
had said software engineer, then that would have been acceptable. It seems
Mentor had this idea that being just a programmer was not the type of
person they needed.

The first "programmer" I met had no clue that software took time to execute
(1978 - 8080 based system). He had written a complex program to control a
big hardware machine with a stepper motor, print head, solenoid, CRT
display, and a few other things. I walked in when he was testing the system
and he could not understand why the motor was advancing paper in a jerky
fashion. I perused his code for a few hours to get a handle on what he had
written and then I asked him how long his interrupt routine took to execute
and how often it was being called (pretty standard stuff for real-time
control). He had this blank expression on his face and said he didn't know
about how long, but an interrupt was generated every 200us. I got out a
scope and proceeded to find out that his interrupt routine was taking 300us
to execute, so of course it was missing interrupts at a pseudo random rate.
I rewrote his routine to get it below 200us and then everything worked fine.

best regards, Steve Thatcher

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



--
Delivered by the SEBHC Mailing List