On 8/9/13 2:21 PM, Philip Pemberton wrote: that was probably what I was thinking of, with the precomp PLA shown take a look at US patent 4334250 and 5187614. I've never really looked at this, since I've never worried about low level writing of floppies. I suspect Chuck Guzis is very familiar with all of this. I also thought that on floppies precomp was only applied after tk 23 on 5" and 43 on 8"

On Fri, Aug 9, 2013 at 4:46 PM, Al Kossow <aek at bitsavers.org> wrote: The optimal precomp actually depends on the model of drive, the track number, and to a lesser extent on the medium. For commodity hardware they obviously had to come up with a compromise that would work pretty well on all drives and media. It should be possible to write software to use a DiscFerret or the like to automatically determine the optimal precomp for every track for a particular drive model. Eric

On 8/11/13 8:45 AM, Philip Pemberton wrote: Don't you just write the worst-case pattern, read it back, and measure where the flux transition actually occurs?

On Sun, 11 Aug 2013, Chuck Guzis wrote: or the disks that Wabash wouldn't buy.

On 08/11/2013 03:29 PM, John Wilson wrote: Sure, remove the cookies from the jackets, bake them at 140F for 4 or 5 hours, then apply a good-quality synthetic auto paint sealant--Klassic seems to be pretty good. No abrasive polishes, please. That seems to provide a slick enough surface to keep the heads from grabbing the oxide--at least for a few reads. The alternative is disaster. I've wondered about trying some of the dry silicone lubes, but they mostly seem to be aerosols and use some sort of solvent as a carrier. Probably not good for media, but I haven't tried. Basically, you want to prevent the heads from "grabbing" the oxide. Once that starts, you're looking at a circle that you can see through. Get yourself an old box of Wabash floppies (any size) and play around. I use perc as a head cleaner--isopropanol doesn't seem to be as effective. I'll be interested to hear of others' experiences. --Chuck

On 08/11/2013 08:22 PM, Mouse wrote: Perchlorotethylene or tetrachloroethylene--AKA dry-cleaning fluid. A barely-adequate substitute for outlawed Freon TF. Careful with it around plastic, but it gets the most gunked-up deposits off of drive heads. --Chuck

On Fri, Aug 09, 2013 at 04:00:31PM -0700, Glen Slick wrote: I was wondering the same thing (I too am working on floppy write code, but it's currently back-burnered by my day job). I've heard 43 thrown around but I wonder if it's confusing two ideas. I'm not a doctor but I would think that write precomp should be more of a progressive thing, as the track #s go up (so the total track circumference goes down and the bits are squished closer together). But maybe I'm worrying too much -- the data tracks never get that close to (or far from) the center so it's possible that two (or even one?) precomp offset(s) work for the whole disk. Certainly FDCs don't normally bother knowing anything specific about the drive and/or medium so they aren't optimizing. John Wilson D Bit

On 08/09/2013 03:46 PM, Al Kossow wrote: Reduced write current on 8" floppies after 43. TG43 *could* be used to trigger precomp, but usually isn't. As a matter of fact, I'm aware of no FDC datasheet that specifies when precomp is asserted--some allow for it to be explicitly specified. I suspect that some FDCs simply precomp all cylinders as there's no way for the controller to tell if you're writing 40 cylinders or 77 or 80. Write precompensation is a very clover scheme to, as Al observes, to get around the effects of "bit shifting" on inner cylinders, where attempting to record a flux change too close to another already written will tend to shift the one being written away from the one already written. It's usually done with MFM, because MFM is somewhat more susceptible to timing jitter, but there's no reason that it couldn't be used on, say, GCR as well. The confusing part about most descriptions of the process is that they don't make it clear that when they're talking about 1 and 0, they're not talking about the data stream being encoded, but rather the stream after encoding. So, 1 = flux change, 0 = no flux change. The actual amount of precompensation is somewhat arbitrary and differs bit cell, or, in the about 125 microseconds in the case of a 500KHz data rate. Older hard disk MFM controllers used delay lines for this, but simply deriving it from the floppy clock is usually good enough. So, you need a window into the data stream heading out to the write circuitry. You need to know what you've written, what you're about to write and what you're going to write after that. Clearly, if you're going to write a 0, i.e. no flux change, you don't need to make any decision, wince you're not doing anything. Here's a scheme that I use, and it seems to work very well. Note that what's being written is a "1" (flux change) and we'll denote "now" with a "|": Next Last (1) 010 | 000 (2) 010 | 001 (3) 100 | 010 (4) 000 | 010 Note that in MFM, you never have two flux changes ("1") immediately adjacent to each other. The first two are "late"; that is, we delay our flux change, so it's recorded closer to the "1" we're going to record next, which will shift it "backwards". The second two cases are "early". That is, if just wrote the "1" on-center, it would get shifted as if it were delayed, so we compensate by writing it earlier than usual. That's really all there is to it. This is by no means the only scheme and you can even mimic some of the hard drive logic that adjusts precomp depending on the cylinder. Generally, you apply precomp somewhere after you've reached the halfway point on a disk, but that can vary from drive to drive. You may find the ENCODE routine in the Linux Catweasel driver to be more suited to a software implementation. It accomplishes the same thing, but doesn't require lookup tables. The language, however, is a bit confusing if you're thinking about flux reversals--the author uses the terms "long pulse" and "short pulse". --Chuck

On Aug 9, 2013, at 9:41 PM, Keith Monahan <keithvz at verizon.net> wrote: I have some documentation on how the Mac SWIM chips do it... I can't recall off the top of my head whether it's restricted to MFM modes or not, but it would make sense (as SWIM does MFM iff it's doing high density). - Dave

On Aug 9, 2013 6:38 PM, "Chuck Guzis" <cclist at sydex.com> wrote: somewhat more susceptible to timing jitter, but there's no reason that it couldn't be used on, say, GCR as well. In fact, it was nearky always done with GCR on hard drives, though the GCR was usually more specifically known as (1,7) RLL or (2,7) RLL. Both codes would be unusable at normal flux densities on hard drives. It typically wasn't done with GCR on 5.25 inch floppies because the schemes in use (e.g., by Apple and Commodore) weren' t using flux density as high as the standard MFM format. (I'm not sure about the GCR on rt he Victor 9000.) Eric

I'm not absolutely certain (I don't have the schematic in front of me) but I am pretty sure there is no write precompensation in the Sirius/Victor 9000 floppy controller .The data handling circuitry is, not suprisingly, very similar to that used by Commodore, and I think I would ahve noticed an added precompensation circuit. -tony