Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!brutus.cs.uiuc.edu!apple!oliveb!amiga!cbmvax!jesup From: jesup@cbmvax.UUCP (Randell Jesup) Newsgroups: comp.sys.amiga.tech Subject: Re: Questions on the floppy drive hardware Message-ID: <7697@cbmvax.UUCP> Date: 19 Aug 89 00:57:23 GMT References: <2117.AA2117@geo-works> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Organization: Commodore Technology, West Chester, PA Lines: 43 In article <2117.AA2117@geo-works> bryan@geo-works.UUCP (Bryan Ford) writes: >First, does the WORDSYNC feature shift each bit into a compare register as >they come in, and compare it at each bit, or does it just grab a whole word >at a time and compare it at each word boundary? I would think the former, >but the manual is a little vague on this, and I've learned not to assume >anything. :-) The WORDSYNC compares at each bit. If it sees a match, it will re-sync (throwing away any partial word that has net been written). The effect of this is if there are two sync words in the input stream, say $4489 $4489, and they are on a word boundary already, the hardware will write $4489 $4489. If they were not on a word boundary (shifted some number of bits) you will get only one $4489 in the output. This is all discussed in the next issue of AmigaMail, I believe. >What affect do the PRECOMP0, PRECOMP1, and MFMPREC bits have on data input >and output? I know that the hardware doesn't automatically do >precompensation. Is this just a hook for a later hardware feature? What >does the standard trackdisk.device use for these bits? PRECOMP 0&1 determine the amount of precomp when writing, from 0ns for 00 to 560ns for 11. For floppies, you need 00 for tracks 0-79 (0-39 for 5.25" drives), 01 for the inner tracks (140ns). MFMPREC should be 0 for MFM data, 1 for GCR data. Note that to use GCR you cannot use FAST (2us/bit), you must use 4us/bit. Trackdisk uses MFM in all cases. >I know that if you use FAST mode (2 usec per bit), you can't have two 1's >right next to each other in the data stream. Is this limitation imposed by >the actual disk drive hardware, or the hardware in the Amiga, or both? Disk hardware. You need some clocking to keep track of where bits fall, and the hardware can only keep sync for so long. It causes by a combination of things, exactly what is unimportant (media, heads, electronics, etc). -- 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!"