chris@mimsy.UUCP (Chris Torek) (05/16/88)
[NB: followups redirected to comp.periphs. It seems to me the only rational place for this to continue, if anywhere.] In article <218@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes a nice long article describing 2,7 RLL encoding. (Thanks, by the way, although what I really wanted to see was that table you did not reproduce :-) .) Now let me try for the intuitive description, with some nitpicky technical stuff too. First the technical nits: >I. How is data stored on a disk drive? >As magnetic flux reversals (think of it as + to -). The POLARITY of the >magnetic flux doesn't mean a thing. It is the TIMING of the flux reversals >that is used to encode data. Sort of. + to - or - to + is not important, but it is not timing, but rather presence, of reversals that encodes data. The simplest encoding ---the old `IBM format' or `FM' or how you got a whole 128K :-) on an eight-inch floppy---is simply clock+data, clock+data, ... where a data `1' is a reversal and a data `0' is a missing reversal. >II. What is RLL? What does the '2,7' in '2,7 RLL' mean? >RLL means Run Length Limited. The [numbers] refer to the >minimum and maximum time between flux reversals. (Remember this for the intuitive explanation.) >RLL codes are 'self clocking'. All common drive formats are self-clocking: that just means the timing is stored in among the data somehow, rather than on something external. An example of a non-self-clocking medium might be a paper tape (although paper tape has sprocket holes that can be used for clocking---this is how the `pull the tape through by hand' readers work---most paper tape readers relied on a constant rate of tape motion.) >... 2,7 RLL is a variable length code (e.g. 0011 maps to 00001000 but >010 maps to 100100); I don't have a simple formula for the 2,7 RLL code! This is not variable length: four bits went to eight, and three to six. In other words, n bits becomes 2n bits. I think someone just squashed equivalent table entries to make it look variable length. >P.S.: If you read all the way to here, congratulations! I don't really expect >that this stuff would really be interesting enough for people to read through >250 lines of gobbledy gook... :-) (You might be surprised.) Anyway, time for intuition. None of the following is strictly accurate, but it should give you a good feel for how these things work. When you stick flux changes (data and/or clock) onto a disk surface, they tend to `wiggle around', somewhat like paper dots dropped from a bit too high up, in a slight breeze. The better the drive, the more accurately the dots land where they were supposed to go, but they always wind up slightly out of place. Unlike the paper dots, though, those darned flux changes wiggle *more* when you put them closer together. If you put too many of them in a row, they crawl right out of where they were supposed to be: you wanted 1111: < wiggle >< wiggle >< wiggle >< wiggle > 0 1 2 3 but you got 11?0: < wiggle >< wiggl>< wig><e w>ggle 0 1 2 3 The darned things are scared of each other! We have to make sure the closest we ever put them is one wiggle-space apart, or they will get scared and wiggle away. We will represent this minimum wiggle-space with | marks below. (Note that the wiggles can see through the marks and will get scared if they are less than two | marks apart. This should make sense as soon as you get to the MFM diagram.) On the other hand, if you put them too far apart, the controller gets forgetful, as if it were counting sheep and the sheep stopped jumping: you wanted 10000001: | w | | | | | | | w | 0 1 2 3 4 5 6 7 but you got 1000..??oops | w | | | | | | | w | 0 1 2 3 ... now where was I? So the idea is that we have to put the wiggles close enough together so that the controller does not forget to keep counting, but far enough apart so that they do not scare each other away. (In engineer-ese, the flux reversals must be far enough apart not to interfere, but close enough together to keep the decoding circuit in sync.) Well, one way to do this is to use good ol' FM format, and put the clock and data wiggles fairly far apart. We always get clock+data, and clock is always 1, so we get wiggle+blank or wiggle+wiggle. If we got a whole series of wiggle+blanks, each wiggle would be two spaces apart, and if we got a whole series of wiggle+wiggles, they would be one space apart. One space has to be `far enough' and two has to be `close enough'. This is easy to arrange, but it only gives us a measly 128K on a whole eight-inch disk. So what to do? Well, how about Modified FM? We will put the clock wiggle in only if we do not have enough data wiggles to keep the controller counting. If we have two data wiggles next to each other, we can put them one space apart, because there will not be any clock wiggle to scare them away. Write it this way, with a `.' marking half-spaces. The clock wiggle is the one on the left of its dot. you wanted 11001011: | .w| .w| . |w. | .w| . | .w| .w| 0 1 2 3 4 5 6 7 The wiggles are still not too close---always at least one space apart, and sometimes one and a half spaces---yet still not *too* far apart. But maybe we can do better. And with 2,7 RLL, we do! Instead of putting in a wiggle for every `1' data bit, and a special clock wiggle if we need one, suppose we make up some tables giving whole bunches of arrangements where we wiggles are at least three dots apart, but at most eight. Using Pete's two examples: >e.g. 0011 maps to 00001000 but 010 maps to 100100 you want 0011 010 010, so write 00001000 100100 100100: | . . | .w. | . .w| . .w| . .w| . .w| . . The wiggles are still always at least one space (three dots) apart (we never get something like | . .w| .w. | where the two are only two-thirds of a minimum wiggle-space apart), and they are never more than three (really eight-ninths) spaces apart. Or again in EE-speak, the minimum flux separation is still one unit, and the maximum 8/9 units, so they will not interfere and the electronics will stay in sync. Why, then, might some drives have trouble with 2,7 RLL encoding? Well, compare an MFM picture with a 2,7 RLL picture: MFM: | . w| . w| . |w . | . w| . | . w| RLL: | . . | .w. | . .w| . .w| . .w| . . |w. . | In MFM we only have to be able to tell whether a wiggle (flux change) is to the left or the right of a whole box, but in RLL we have to tell whether it is in the first, second, or last third of the box. If the if the wiggles are wigglier than usual, or if the controller gets sloppy, one of the wiggles might wiggle in the middle instead of on the right. When that happens, you get a read error. In other words, Pete is exactly right. What a 2,7 RLL encoding demands is not that the wiggles (flux changes) be put closer together, but rather that their position within each wiggle-space be pinpointed more accurately. If you try a drive not rated for this, it might not work: Some drives just have loose wiggles. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
pete@octopus.UUCP (Pete Holzmann) (05/16/88)
In article <11508@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: }In article <218@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes }a nice long article describing 2,7 RLL encoding. (Thanks, by the way, }although what I really wanted to see was that table you did not reproduce }:-) .) Well, it is buried somewhere in my office! If you could see my office, you'd understand why I'm not going to quickly find something that I haven't looked at for years :-). When I find it, I'll post it... Now it's my turn to get picky about Chris' posting, but not before saying that I think 'wiggles' is a much more fun term than 'flux reversals'. I hope the engineers pick it up in future technical documents! }Now let me try for the intuitive description, with some nitpicky }technical stuff too. First the technical nits: }>I. How is data stored on a disk drive?... }>It is the TIMING of the flux reversals that is used to encode data. }Sort of. + to - or - to + is not important, but it is not timing, but }rather presence, of reversals that encodes data. Well, to get even nittier :-), I'd have to say that timing+presence = data. And since timing [of reversal locations] implies their presence, I didn't feel too bad about just saying 'timing'. But I'm being too picky! }>RLL codes are 'self clocking'. }All common drive formats are self-clocking: that just means the timing }is stored in among the data somehow, rather than on something }external. An example of a non-self-clocking medium might be a paper }tape... As far as I know, some self-contained drives (ESDI, SCSI, etc) use an entire surface formatted with a clocking pattern; the dedicated surface provides clocking, which enables higher density data encoding, since you don't have to worry about embedding clock wiggles in your normal data areas. }>... 2,7 RLL is a variable length code (e.g. 0011 maps to 00001000 but }>010 maps to 100100); I don't have a simple formula for the 2,7 RLL code! }This is not variable length: four bits went to eight, and three to six. }In other words, n bits becomes 2n bits. I think someone just squashed }equivalent table entries to make it look variable length. Nope! It *is* variable length. It is constant *density*, in that n bits becomes 2n bits. But just as LZW compression uses varying length codes to represent original byte sequences, 2,7 RLL uses varying size codes to represent original bit sequences. I wish I had the complete code handy; that would make it more obvious! }>P.S.: If you read all the way to here, congratulations! I don't really expect }>that this stuff would really be interesting enough for people to read through }>250 lines of gobbledy gook... :-) }(You might be surprised.) I *was* somewhat surprised. Initial returns on my 'vote' taking show rather unanimous approval of as much detailed, low level technical content in discussions as we can muster our little brains to produce. NOBODY (so far) felt that my explanation was too complicated at all. This is very reassuring to me, both about net-people, and about the PC groups. They aren't a bunch of high school kids out for a joy ride; we're mostly communicating with professional people. The few immature exceptions just leave a bad taste for everyone. Chris' "intuitive" explanation of wiggles (flux reversals) on the disk was fun! Maybe not necessary for boring technical people, but I'll take a fun explanation any day over a dry one. Thanks for re-explaining it that way, Chris! }Some drives just have loose wiggles. }In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) }Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris Pete -- OOO __| ___ Peter Holzmann, Octopus Enterprises OOOOOOO___/ _______ USPS: 19611 La Mar Court, Cupertino, CA 95014 OOOOO \___/ UUCP: {hpda,pyramid}!octopus!pete ___| \_____ Phone: 408/996-7746
pjh@mccc.UUCP (Pete Holsberg) (05/17/88)
In article <11508@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
...Anyway, time for intuition. None of the following is strictly
...accurate, but it should give you a good feel for how these things
...work.
...
...When you stick flux changes (data and/or clock) onto a disk surface,
...they tend to `wiggle around', somewhat like paper dots dropped from a
...bit too high up, in a slight breeze. The better the drive, the more
...accurately the dots land where they were supposed to go, but they
...always wind up slightly out of place.
I like simple analogies, but ... "afraid of each other"???grr@cbmvax.UUCP (George Robbins) (05/17/88)
In article <223@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes: > In article <11508@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: > }In article <218@octopus.UUCP> pete@octopus.UUCP (Pete Holzmann) writes > > As far as I know, some self-contained drives (ESDI, SCSI, etc) use an > entire surface formatted with a clocking pattern; the dedicated surface > provides clocking, which enables higher density data encoding, since you > don't have to worry about embedding clock wiggles in your normal data areas. You are confused here. Many high-dollar drives do have a "servo head" that is used to maintain accurate head position and incidentally to derive a "servo" or "write" clock. However in all cases, the "read" clock is derived from the data stream, not the servo clock. The servo clock does not represent abosolute bit position - at the linear track densities used by modern drives this would be a most difficult feat... Other drives dispense with the separate head. The lower density drives can get by with either open-loop (stepper motor) head positioning or by using an optical encoder to approximate track position. Some higher density drives use specially coded markers and/or differential detection in the read heads (embedded servo techniques) that yield an error signal when the head is not centered over a data track. -- George Robbins - now working for, uucp: {uunet|ihnp4|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
is813cs@pyr.gatech.EDU (Cris Simpson) (05/18/88)
"Intuitive and Silly" explanations often make people rethink what they believe they already know. It never hurts to have the grey cells churned up every so often. I'm all for 'em.