Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!necntc!ames!oliveb!sun!cmcmanis From: cmcmanis@sun.uucp (Chuck McManis) Newsgroups: comp.sys.amiga Subject: Re: Reading MacDisks on Amiga Message-ID: <18746@sun.uucp> Date: Wed, 13-May-87 14:48:24 EDT Article-I.D.: sun.18746 Posted: Wed May 13 14:48:24 1987 Date-Received: Sat, 16-May-87 05:45:34 EDT References: <8705080543.AA18112@cory.Berkeley.EDU> <112@l5comp.UUCP> <122@l5comp.UUCP> Followup-To: junk Organization: Sun Microsystems, Inc. - Mtn View, CA Lines: 137 Summary: Will this end? Here are some comments to the ongoing Mac disk debate which has probably raged on far to long for the wrong reasons. But not being one who likes to leave a discussion in a muddy state ... :-) The Players ... '>>' Mike Farren '>' Scott Turner ' ' Moi >>News to me - could you please specify what you're talking about? I >>just put down the Hardware Ref. Manual and couldn't find such a beast. >>There IS a bit for selecting 2 or 4 microseconds/bit cell, but that >>isn't going to buy you a lot of flexibility. >Yeah but it DOES change the clock rate! Which is what we were talking about. No it wasn't what we were talking about. We were talking about changing the *motor* speed of a disk drive which is *not* possible on the Amiga. (If you try to pulse width modulate the MotorOn line it doesn't help because the drive isn't 'ready' until is comes up to speed) May grr correct me if I am wrong, but I don't think the 2/4 bit changes the clock rate at all, it changes how the bits are viewed so that you can decode FM formatted disks. >>No, it just makes it more brain damaged. If the extra speed thing is >>true, then they should have been able to get a LOT more data onto the >>disk than the 400/800K that they did. Twice the rotation speed == >>twice the data rate, after all. (Is this how IBM is getting 1.4M >>3-1/2" drives, by the way?) > Uh, twice the rotational speed at the same data rate := half the data at a > 1X rotational rate. The laws of nature win out, grin. Take for example a > phonograph record. Which record stores the most music: 33 1/3, 45, or 78 RPM? > The faster rotational speed does one thing, decreases rotational latency. First the change in disk speed is marginal and second they slow it down rather than speed it up. I'll get into that in a moment but first ... Actually a faster speed can increase your effective bandwidth because for a given signal you have more media to put it on, the quantity of signal that is present goes down. Scott failed to mention that on disks (unlike records) you can move the 'grooves' closer together which complicates the issue. As for the IBM disks, they got 1.4 Meg the exact same way they got 1.2 Meg on a 5-1/4" disk they went with a 500Khz clock rate rather than the 250Khz rate which is standard on other 5.25" interfaces (and 3.5" interfaces) Both Sony and 3M sell '2M' 3.5" diskettes that can be used by the IBM drive. > And actually considering that Apple is using SINGLE DENSITY data rates I think > they do a rather nice job of packing the data on the disk. Yup, but they are using Group Coded Recording which cannot extract the data clock the way Modified FM can so they are 'stuck' at single density. As it turns out the data density of GCR is fairly close to that of MFM so it isn't a loss on their part, the big win is that the Integrated Woz Machine can easily decode GCR data and it is inexpensive to build. > Data density is a function of three things: Media's ability to record X number > of flux changes per inch. Drivehead's ability to produce X number of flux > changes per inch. And the drives ability to position the head in tracks > per inch. This is in essence true, I would phrase it a bit differently. Given a drive whose head can resolve 'n' tracks on the disk and a data clock rate of 'c' clocks/second and whose speed of revolution is 'r' revolutions/second. Raw data capacity can be calculated with : [(clks/sec * bit/clk)/(revolutions/sec * bits/byte)] * tracks * heads Which for a 3.5" drive at a constant 300 RPM (5 rps) is [(250000 * 1) / (5 * 8) ] * 80 * 2 = 1000000 bytes. Note that MFM encodes 1 bit/clock, and FM encodes .5 bits/clk. This is the difference between single and double density on most drives. Now you lose some of those bytes to formatting information like sector headers, intersector gaps, and end of track gaps (to account for variations in disk speed) Another note : Most computers like the Atari and IBM use dedicated floppy disk controllers that work on a sector by sector basis. These computers leave gaps between the sectors to allow for variations in disk speed, and before the sector, usually write a 'sync' pattern that locks the controllers phase locked loop onto the data stream. Since the Amiga writes entire tracks it can eliminate those gaps and use the recoverd space for data. That results in the 'extra' 80K of space/disk or one 512 byte sector/track. Now back to our story ... > Rotational speed has very little to do with anything except rotational latency > and the EFFECTIVE fci (FluxChangeInch) being laid down. If a constant speed > is used for rotation and fci being sent to the drive, the actual fci will vary > from the inner most track to the outer most track. This is because no matter > which track you are you always go round in the same amount of time, but the > length of track that goes round varies from the inside to the outside. Thus > on the outer tracks the bits are "fatter" because more track goes under the > head during a fluxchange in the head. So what Apple did was have the drive > change speed so that the effective fci laid down is pretty much the same from > the inside track to the outside track. What Scott fails to do here is relate this to the real world. Real disks are rated at a given fci. And like he says flux changes becomes bits as the head goes over them. Since most disk drives are constant speed the worse case condition occurs on the inner track with whose circumference is the smallest, and consequently has the bits packed as closely as possible. Apple was and is constrained by a constant speed clock to their phase locked loop but they realized that the disks were underutilized on the outer tracks so they came up with the rather clever scheme of slowing down the drive as the heads stepped further out. In our capacity formula above, this means that the (revolutions/sec * bits/byte) term will vary according to the track number. Thus, assuming there is a function for rotational speed given the track number the formula for capacity becomes the following integral instead : _ tracks / heads * / [(clks/sec * bit/clk)/(revolutions/sec(tracks) * bits/byte)] dtracks 0 _/ What this also points out is that the exact same effect could be achieved if you vary the clks/sec as a function of the track as opposed to the speed of the drive. Electronically this is a bit more difficult but certainly possible. However since the Amiga is constrained by *both* clock speed and drive speed you cannot change it to read Mac disks. The infamous 2 msec/ 4 msec bit is there to 'switch' between MFM decoding and FM decoding as these are the respective bit-times for these recording methods. > The trouble with Apple is that they've never gone double density :-). Well it is impossible to represent some GCR codes in an MFM bit stream however as I said earlier GCR does yield about the same *data* density as the 'double density' MFM technique so the conversion would not achieve the desired effect of doubling the data capacity :-) -- --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses. But you knew that, didn't you.