Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!amiga!cbmvax!jesup From: jesup@cbmvax.UUCP (Randell Jesup) Newsgroups: comp.sys.amiga.tech Subject: Re: amiga disk drives ... Message-ID: <7226@cbmvax.UUCP> Date: 6 Jul 89 18:02:17 GMT References: <8907051954.AA04521@postgres.Berkeley.EDU> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Organization: Commodore Technology, West Chester, PA Lines: 32 In article <8907051954.AA04521@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: > I'm not sure exactly what C-A does but this is the right way > to do it (numbers picked at random) for writing a track: > > buffer: Actually, it's 830 data (1660 mfm encoded) bytes of gap written at the beginning of the track. The gap must be large enough so the track will partially overwrite it. The maximum number of data bytes that can be guaranteed to be stored on a track (including headers, sync words, etc) is about 5999 bytes, because of timing and disk speed variations. Drives are speced at +-1.5%, the amiga clock (for various reasons) is speced at +-5%, and the amiga clock is 2.5% fast nominally. The nominal number of data bytes on a 1-meg floppy in 6250. > To encode more actual data onto the drive you can try a different > encoding method. The old commodore PET/CBM drives used a form of > GCR encoding. > > -Matt True, but to use GCR on the amiga you must drop back to the slow bitrate, which cuts your storage in half to start with. There are other MFM-style encodings that would still follow the rules about clock bits correctly, but they are non-standard, and would be much harder to encode/ decode. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"