Xref: utzoo comp.sys.ibm.pc:15577 comp.periphs:946 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!lll-lcc!pyramid!octopus!pete From: pete@octopus.UUCP (Pete Holzmann) Newsgroups: comp.sys.ibm.pc,comp.periphs Subject: Re: RLL: an intuitive (and somewhat silly) explanation Summary: Nits are no problem, and the net *like* technical detail! Message-ID: <223@octopus.UUCP> Date: 16 May 88 03:50:07 GMT References: <1255@kodak.UUCP> <638@mccc.UUCP> <216@octopus.UUCP> <650@mccc.UUCP> <218@octopus.UUCP> <11508@mimsy.UUCP> Reply-To: pete@octopus.UUCP (Pete Holzmann) Organization: Octopus Enterprises, Cupertino CA Lines: 83 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