Loading ...
Sorry, an error occurred while loading the content.

Re: Floppy controller Pre-comp settings. Any rule of thumb for settings??

Expand Messages
  • Allison Parent
    Hi, While I m fussy on the subject of floppies that would have slid as I d have assumed from what you said it was an older/acient drive. Harsh reality is I ve
    Message 1 of 29 , Apr 28, 2006
    • 0 Attachment
      Hi,

      While I'm fussy on the subject of floppies that would have slid
      as I'd have assumed from what you said it was an older/acient drive.

      Harsh reality is I've used every precomp value from none to 250ns
      and rare was the error I could see that wasn't attributable to
      media or random error. For practical purposes it's just not an issue
      anymore.

      Allison


      --- In cosmacelf@yahoogroups.com, "Al Winfrey" <wa9hsl@...> wrote:
      >
      > I'd better correct part of that reply before Allison flames me for
      it! According to the Heath
      > manual, the precomp is actually turned off for "single density" 48
      tpi Wangco drives. I have
      > used the factory precomp setting of 300ns quite well for the
      half-height double-sided
      > "double-density" Teac drives. Sorry, I'll quit kibbitzing! :o)
      >
      > al
      > ....
      >
      >
      > --- In cosmacelf@yahoogroups.com, "Al Winfrey" <wa9hsl@> wrote:
      > >
      > > My Heath controller was salvaged from an old Z-89 computer and it
      uses the 1797 IC.
      > It's
      > > manual agrees with Lee's numbers of 275-325 ns for both 48 tpi and
      96 tpi drives but I
      > > don't think that the number is all that critical. It just enhances
      readability for the inner
      > > tracks and "ballpark" numbers are good enough.
      > >
      > > I once built a wire-wrap floppy controller and lacking a
      scope/counter, just "calibrated"
      > it
      > > by setting the pot in the middle of it's range. The computed
      values of the components
      > > guided the setting nicely and the disks were readable on other
      drives. I don't suggest
      > this
      > > to anyone else unless you are blessed with blind luck like
      me...use instruments!
      > >
      > > :o)
      > >
      > > al
      > > ....
      > >
      > > --- In cosmacelf@yahoogroups.com, "Allison Parent" <kb1gmx@> wrote:
      > > >
      > > > Likely that heathkit controller was for the older SA400/450 and
      > > > TM100-1/2 full height and similar (48tpi) drives from the late
      > > > 70s and early 80s.
      > > >
      > > > It's different for the newer drives and those running 96tpi
      > > > (80 track one or two sided drives). Generally 150 to 250ns
      > > > works. I use 187ns for FD55F and G series at 780kb formatted
      > > > for CP/M, it's sometimes called QD but it's only DD for 80
      > > > tracks two sided.
      > > >
      > > >
      > > > Allison
      > > >
      >
    • Allison Parent
      ... There are similar signals for the 765. ... Most of what follows is for 1797 or systems using analog PLLs and oneshots. While it works, sometimes very
      Message 2 of 29 , Apr 28, 2006
      • 0 Attachment
        Inline notes:

        --- In cosmacelf@yahoogroups.com, "sbirdasn" <sbirdasn@...> wrote:
        >
        > Warning, large discussion ahead...
        >
        > First, let's be more precise:
        >
        > There is only one "precompensation" adjustment, and it is for writes,
        > and ONLY in MFM recording mode (/DDEN active on 279x, as FM mode
        > ignores precompensation in 279x chips), and only when the "Enable
        > Precomp" (ENP active on 279x) is active.

        There are similar signals for the 765.

        > You can use the TG43 pin for automatic control in 80-track
        > drives/disks. Otherwise, you must control the ENP pin yourself if
        > using a 40-track drive, activating it on tracks from about 20-39,
        > which is close enough to track 43 in an 80-track drive to be about the
        > same place.

        Most of what follows is for 1797 or systems using analog PLLs and
        oneshots. While it works, sometimes very well, I'm alergic to
        oneshots. Reason, I worked with an engineer that based entire
        logic systems on onshots and critical timings. They were a pain
        to set up and frequently failed to work. So I tend to use digital
        methods and most of the 765 derivetives are digital rather than
        analog. Digital methods are easier to setup as they lack adjustments
        that can drift or require measurement. There were/are several chips
        that implement all this digitally with excellent performance, one
        being the old SMC9229(works with 765 or 1791/3) and friends though
        it can be done with about a dozen or less packages of TTL. Some
        chips this is all internal and programable an example of a one chip
        floppy solution is the WD37C65 and later devices.

        > The second pulse adjustment is the "Read Pulse Width" or RPW
        > adjustment. It is simply set at 1/8th of the data rate. Simple as
        > that. It doesn't compensate for anything. I think it just tells the
        > FDC what a minimum read pulse should look like, so it doesn't trigger
        > on noise glitchs or runt pulses.
        >
        > The rest of this discussion assumes you have an old style 250 KHz data
        > rate 5.25" drive, not a high-density 500 KHz data rate. Halve the data
        > timings if that's the case.
        >
        > For the record, my Atari 800 compatible Indus drive is using an OEM
        > Tandon (stripped down, not standard 34-pin interfacing) 1/2-height
        > drive and was found to have the following settings:
        >
        > VCO = 236.4 KHz.
        >
        > Probably ment to be 250 KHz, as that's the official data rate, even
        > for the strange Atari format disks (rotational rate was changed which
        > resulted in tighter than standard bit-densities.
        >
        > RPW = 514 nS.
        >
        > Probably ment to be 500 nS which would match with the "standard" data
        > rate.
        >
        > WPW = 260 nS.
        >
        > Probably ment to be set to about 250 nS, more or less I would guess.
        >
        > This is probably a bit higher than normal, as Atari forced the
        > bit-density a bit, which results in greater skew in the flux
        > transition edges on read back.
        >
        > This might also help a little:
        >
        > My Teac FD-55A (5.25", 40 track, single-side, 250 Kbps data rate) has
        > some timing specs as follows:
        >
        > In MFM, you can have the following flux transitions on write:
        >
        > 4 uS, 6 uS, 8 uS.
        >
        > All measured from falling-edge to falling-edge at the cable interface.
        > It's the *falling-edge* of each pulse that commands a flux transition
        > at the head.
        >
        > The minimum time between any two edges is 250 nS, so actual
        > write-pulse (active low) width is somewhat flexible.
        >
        > The accuracy of the flux transitions is about +/- 0.5%, so the drive's
        > write amplifiers are pretty accurate in their timing.
        >
        > Note: The drive itself doesn't know what precompensation is. All it
        > does is change the direction of the write current upon command, at
        > each pulse falling-edge (start of pulse) when "write gate" is active.
        >
        > That's all it knows about writing bits to the disk media.
        >
        > Reading is a different beast:
        >
        > The "Read Data" pulses generated by the drive are once again falling
        > edge based, with the width about 1 uS +/-0.5 uS (just a one-shot
        > triggered on flux reversals, read head feeds differential amp w/lots
        > of filtering to keep out the noise).
        >
        > The nominal pulse-to-pulse times are once again 4,6, & 8 uS, but have
        > a maximum skew from ideal relative to other edges in the data stream
        > of +/- 20% from nominal.
        >
        > Though the data sheet doesn't specifically state this, the skew is
        > from a variety of factors, including noise/jitter, interaction between
        > flux transitions in adjacent bit cells, signal strength, head
        > alignment, etc. However, it will be greatest in the innermost tracks.
        > It will also be when the flux transition pattern shifts between wide
        > and narrow and back to wider pulses, and the skew amount and direction
        > is predictable (more or less).
        >
        > So, since some of the read data pulse skew is predictable, we have a
        > way to adjust for it. And write precompensation is the method.
        >
        > You can set the Write Precompensation to values that have been
        > suggested, but you could empirically derive a closer solution
        > yourself, I believe.
        >
        > Technically, you can write almost any arbitrary data pattern on the
        > track when you are formatting the disk. Only a few data values cannot
        > be written due to the controller chip using them as commands to write
        > the special address/data marks and CRC's on the track. The controller
        > can't read patterns that don't follow the IBM formatting standard (or
        > close cousins), but for the test I propose, it doesn't matter.
        >
        > You can write a set of repeating bit patterns that contain each of the
        > different pulse timings and transition types (ignore special
        > address/data marks, it's not relevant here, only flux reversal timings
        > are important) in a repeating form for the entire track from index
        > mark to index mark. Then you can force the drive into read mode and
        > adjust the scope triggering to show the pattern and measure the timing
        > between edges. You may need to do some conditional triggering to sync
        > up with the index mark, but I think you could get a pretty good
        > display if you experiment with the written pattern. It could be as
        > little as one byte repeated forever to a small pattern of say, 6 bits
        > that falls on byte boundaries every 8th byte, or some such thing.
        >
        > So, here's the plan:
        >
        > 1. Write a reference pattern on track 0, and 19 in MFM without
        > precompensation.
        >
        > Then write the same MFM pattern on tracks 20, 30, and 39 *without*
        > precompensation.
        >
        > Measure the skew of the closely timed edges relative to the wide pulse
        > edges. It should get worse as you move to the inner tracks, with track
        > 39 being the worst.
        >
        > Now, write new data to tracks 20, 30 & 39 *with* precompensation. Try
        > the minimum precompensation (range in 279x is 100-300 nS), then
        > maximum precomp, and see what happens to the skew. Look for a
        > compromise value of precompensation that doesn't over-compensate too
        > much at track 20, but may not pull-in track 39's skew completely
        > (maybe track 30 or 31 is the "ideal" amount, so it may be the one to
        > monitor closely as you try various amounts of precompensation).
        >
        > Then, once you've picked a precompensation that looks like a good
        > compromise, test by formatting the entire disk with your standard
        > track patterns, and test the data recovery error rate with various
        > test data in the sectors of tracks 0,19, 20, 30, and 39.
        >
        > Use both "pseudorandom" data, and repeating data patterns that contain
        > a large number of tight, medium and narrow pulse widths (MFM) in each
        > sector.
        >
        > Also, try both write-read-write-read and write-read-read-read... tests
        > that run on a track/sector(s) for hours at a time.
        >
        > Also some tests that seek back and forth every so often (don't grind
        > continuously, as we're not looking for seek accuracy per se, but to
        > introduce some possible head positioning error). Alternate between
        > seeking from outside in to inside out to the tested track (when
        possible).
        >
        > Oh, the Teac's Error rates are as follows (seems typical, I think):
        >
        > a) Soft read error: 1 per 10^9 bits (up to 2 retries)
        > b) Hard read error: 1 per 10^12 bits
        > c) Seek error: 1 per 10^6 seeks
        >
        > That's probably a bit more work than you're likely to dive into, but I
        > think it's capable of deriving a very good result for a given drive
        > type/brand/media.

        That the problem it is drive, media and windspeed dependent if your
        slicing hairs. ;)

        > Hope that helps clear things up... Like clear as mud- ;)

        My favorite line after explanations like this, "This is more than
        you wanted to know, right?".

        Seriously many people haven't had to deal with magnetics (tape and
        disks) so things like peak shift and bit crowding are only part
        of hard disk vendor engineers day for the last dozen years maybe.
        However for those of us that did disks prior to '85ish this was
        a serious topic and part of getting things to work. If your as
        old as dirt like me the first time you heard of this it was
        pre 1980 and much of it was arcane incantation of the gods Orsted
        and real world drives like the somewhat famous SA800 or infamous
        SA400.

        There were a series of really great articles in BYTE back then
        explaining and demystifying all this.

        > All for now,
        >
        > sbirdasn.

        My $.02 is set it at the median value and don't worry it. Unless
        you are building n>100 the likelyhood of systems being on the
        borderline is nil for floppy error rate. Also with old drives before
        getting cranked on setting precomp make sure the drive even works!


        Allison
      • Robert L. Doerr
        Comments inline.... ... Ahh. The light bulbs goes on... This helps clear up some of the confusion about some of the terms. I had been incorrectly mentioning
        Message 3 of 29 , Apr 28, 2006
        • 0 Attachment
          Comments inline....

          At 08:18 AM 4/28/2006 +0000, you wrote:
          >There is only one "precompensation" adjustment, and it is for writes,
          >and ONLY in MFM recording mode (/DDEN active on 279x, as FM mode
          >ignores precompensation in 279x chips), and only when the "Enable
          >Precomp" (ENP active on 279x) is active.
          >...
          >The second pulse adjustment is the "Read Pulse Width" or RPW
          >adjustment. It is simply set at 1/8th of the data rate. Simple as
          >that. It doesn't compensate for anything. I think it just tells the
          >FDC what a minimum read pulse should look like, so it doesn't trigger
          >on noise glitchs or runt pulses.

          Ahh. The light bulbs goes on...

          This helps clear up some of the confusion about some of the terms. I had
          been incorrectly mentioning read-precomp but it really should have been
          Read Pulse Width. That makes more sense! Thank You.

          The rule of thumb for setting the Read Pulse Width was just the type of
          generic guideline I was hoping to learn.

          >The rest of this discussion assumes you have an old style 250 KHz data
          >rate 5.25" drive, not a high-density 500 KHz data rate. Halve the data
          >timings if that's the case.
          >
          >For the record, my Atari 800 compatible Indus drive is using an OEM
          >Tandon (stripped down, not standard 34-pin interfacing) 1/2-height
          >drive and was found to have the following settings:
          >
          >VCO = 236.4 KHz.
          >
          >Probably ment to be 250 KHz, as that's the official data rate, even
          >for the strange Atari format disks (rotational rate was changed which
          >resulted in tighter than standard bit-densities.
          >
          >RPW = 514 nS.
          >
          >Probably ment to be 500 nS which would match with the "standard" data
          >rate.
          >
          >WPW = 260 nS.
          >
          >Probably ment to be set to about 250 nS, more or less I would guess.
          >
          >This is probably a bit higher than normal, as Atari forced the
          >bit-density a bit, which results in greater skew in the flux
          >transition edges on read back.

          I guess I can experiment with these settings and see how they work
          and may find out that the optimal setting may be somewhere between
          these at the ones I am currently using:

          VCO = 250 Khz, RPW = 250 nS, WPW = 150 nS.

          http://www.robotworkshop.com/robotworkshop/heathkit/manuals/h2k/h2kdcb.pdf

          >This might also help a little:
          >
          >My Teac FD-55A (5.25", 40 track, single-side, 250 Kbps data rate) has
          >some timing specs as follows:
          >
          >In MFM, you can have the following flux transitions on write:
          >
          >4 uS, 6 uS, 8 uS.
          >
          >All measured from falling-edge to falling-edge at the cable interface.
          >It's the *falling-edge* of each pulse that commands a flux transition
          >at the head.
          >
          >The minimum time between any two edges is 250 nS, so actual
          >write-pulse (active low) width is somewhat flexible.
          >
          >The accuracy of the flux transitions is about +/- 0.5%, so the drive's
          >write amplifiers are pretty accurate in their timing.
          >
          >Note: The drive itself doesn't know what precompensation is. All it
          >does is change the direction of the write current upon command, at
          >each pulse falling-edge (start of pulse) when "write gate" is active.
          >
          >That's all it knows about writing bits to the disk media.
          >
          >Reading is a different beast:
          >
          >The "Read Data" pulses generated by the drive are once again falling
          >edge based, with the width about 1 uS +/-0.5 uS (just a one-shot
          >triggered on flux reversals, read head feeds differential amp w/lots
          >of filtering to keep out the noise).
          >
          >The nominal pulse-to-pulse times are once again 4,6, & 8 uS, but have
          >a maximum skew from ideal relative to other edges in the data stream
          >of +/- 20% from nominal.
          >
          >Though the data sheet doesn't specifically state this, the skew is
          >from a variety of factors, including noise/jitter, interaction between
          >flux transitions in adjacent bit cells, signal strength, head
          >alignment, etc. However, it will be greatest in the innermost tracks.
          >It will also be when the flux transition pattern shifts between wide
          >and narrow and back to wider pulses, and the skew amount and direction
          >is predictable (more or less).
          >
          >So, since some of the read data pulse skew is predictable, we have a
          >way to adjust for it. And write precompensation is the method.
          >
          >You can set the Write Precompensation to values that have been
          >suggested, but you could empirically derive a closer solution
          >yourself, I believe.
          >
          >Technically, you can write almost any arbitrary data pattern on the
          >track when you are formatting the disk. Only a few data values cannot
          >be written due to the controller chip using them as commands to write
          >the special address/data marks and CRC's on the track. The controller
          >can't read patterns that don't follow the IBM formatting standard (or
          >close cousins), but for the test I propose, it doesn't matter.
          >
          >You can write a set of repeating bit patterns that contain each of the
          >different pulse timings and transition types (ignore special
          >address/data marks, it's not relevant here, only flux reversal timings
          >are important) in a repeating form for the entire track from index
          >mark to index mark. Then you can force the drive into read mode and
          >adjust the scope triggering to show the pattern and measure the timing
          >between edges. You may need to do some conditional triggering to sync
          >up with the index mark, but I think you could get a pretty good
          >display if you experiment with the written pattern. It could be as
          >little as one byte repeated forever to a small pattern of say, 6 bits
          >that falls on byte boundaries every 8th byte, or some such thing.

          I appreciate your comments and the overview of the technology.

          >So, here's the plan:
          >
          >1. Write a reference pattern on track 0, and 19 in MFM without
          >precompensation.
          >
          >Then write the same MFM pattern on tracks 20, 30, and 39 *without*
          >precompensation.
          >
          >Measure the skew of the closely timed edges relative to the wide pulse
          >edges. It should get worse as you move to the inner tracks, with track
          >39 being the worst.
          >
          >Now, write new data to tracks 20, 30 & 39 *with* precompensation. Try
          >the minimum precompensation (range in 279x is 100-300 nS), then
          >maximum precomp, and see what happens to the skew. Look for a
          >compromise value of precompensation that doesn't over-compensate too
          >much at track 20, but may not pull-in track 39's skew completely
          >(maybe track 30 or 31 is the "ideal" amount, so it may be the one to
          >monitor closely as you try various amounts of precompensation).
          >
          >Then, once you've picked a precompensation that looks like a good
          >compromise, test by formatting the entire disk with your standard
          >track patterns, and test the data recovery error rate with various
          >test data in the sectors of tracks 0,19, 20, 30, and 39.
          >
          >Use both "pseudorandom" data, and repeating data patterns that contain
          >a large number of tight, medium and narrow pulse widths (MFM) in each
          >sector.
          >
          >Also, try both write-read-write-read and write-read-read-read... tests
          >that run on a track/sector(s) for hours at a time.
          >
          >Also some tests that seek back and forth every so often (don't grind
          >continuously, as we're not looking for seek accuracy per se, but to
          >introduce some possible head positioning error). Alternate between
          >seeking from outside in to inside out to the tested track (when possible).
          >
          >Oh, the Teac's Error rates are as follows (seems typical, I think):
          >
          >a) Soft read error: 1 per 10^9 bits (up to 2 retries)
          >b) Hard read error: 1 per 10^12 bits
          >c) Seek error: 1 per 10^6 seeks
          >
          >That's probably a bit more work than you're likely to dive into, but I
          >think it's capable of deriving a very good result for a given drive
          >type/brand/media.

          Now I can see why it would a lot of testing to determine the truely
          best adjustment for a particular controller/drive combo.

          Well, it does bring up another question. The drive alignment (or lack
          thereof) obviously causes interchange problems when moving a floppy
          from one system to another. Would the write pre-comp also end up
          being a factor in disk interchange between like systems?

          >Hope that helps clear things up... Like clear as mud- ;)

          It is an excellent write up and I hope that this could be posted on the
          web so that others can learn about this too.

          Best Regards,

          Robert

          >All for now,
          >
          >sbirdasn.

          ----------------------------------------------------------------
          Robert L. Doerr (MCNE, MCSE, A+)
          1538 Huntington Blvd
          Grosse Pointe Woods, MI 48236
          Tel: (586) 777-1313
          e-mail: <rdoerr@...>

          http://www.robotworkshop.com
          http://www.robotswanted.com
          http://www.robotgallery.com
          http://www.homerobots.com

          "Keeping Personal Robots alive!"

          Expert Robot Repairs and Upgrades available.

          Heathkit HERO robots (1, Jr, 2000, & Arm Trainer), Androbots,
          RB5X, Gemini, Hubot, Newton SynPet, MAXX STEELE & others.
          ----------------------------------------------------------------
        Your message has been successfully submitted and would be delivered to recipients shortly.