Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!qantel!ihnp4!inuxc!pur-ee!uiucdcs!uiucdcsb!kenny From: kenny@uiucdcsb.CS.UIUC.EDU Newsgroups: net.micro.cpm Subject: Re: AMPRO MULTIFMT utility Message-ID: <4800015@uiucdcsb> Date: Thu, 18-Sep-86 13:22:00 EDT Article-I.D.: uiucdcsb.4800015 Posted: Thu Sep 18 13:22:00 1986 Date-Received: Sat, 20-Sep-86 20:58:36 EDT References: <3795@brl-smoke.ARPA> Lines: 89 Nf-ID: #R:brl-smoke.ARPA:3795:uiucdcsb:4800015:000:3879 Nf-From: uiucdcsb.CS.UIUC.EDU!kenny Sep 18 12:22:00 1986 Excuse me for posting this to the net, but NOSC says that mwilson is an unknown user. Date: Thu, 18 Sep 86 12:15:28 CDT From: kenny (Kevin Kenny) To: mwilson@NOSC.ARPA Subject: Writing 48 tpi on 96 tpi drives Cc: kenny We've been through this several times before... and I am already seeing the incorrect explanations of the compatibility problems between 48 tpi and 96 tpi drives flying. Here's a legitimate, simplified explanation. Please feel free to repost to the whole net if you see enough wrong ones go by (I've only seen two so far). The 96 tpi drives place two tracks in the space where a 48 tpi drive puts one: 48 TPI 96 TPI ------------------------------------------------------------------------ ################################|################################ ################################|################################ ################################| ################################|################################ ################################|################################ | ################################|################################ ################################|################################ ################################| ################################|################################ ################################|################################ etc. A 96 TPI drive can easily read a 48 TPI disk. The narrow head sits in the wide track ######## like ############################## ######## this ############################## ############################################ or ################################ like ###### ################################ this ###### and has no problems picking up the data. The problem comes when a 96 tpi drive WRITES a 48 tpi disk. If the disk is truly blank and unformatted, the 96 TPI head will write its narrow track and the 48 TPI can read it because there isn't anything else there to read: ############################## +----+ ############################## | | |wide| |head| +----+ But, if there's ANY data on the disk (say, for example, that the disk was formatted on a 48 TPI machine), then when the 96 TPI drive writes it, we'll have something like +----+ ################################|head|$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ################################+----+$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ ###################################################################### ###################################################################### ###################################################################### so that two different streams of data appear in the area that the 48 TPI head will read. When the 48 TPI disk reads the data, it'll see some sort of bizarre average of the two and get read errors. (Don't flame, physicists and those who understand the recording format. I SAID this was a simplified explanation). Reformatting the disk on either style of drive won't help. Nor will duplicating the data on both half-tracks; they won't be precisely in sync. The only thing that can be done to REwrite a 48tpi disc on a 96tpi drive is run the whole shebang through a bulk degausser so that you again have a blank, truly blank disk. The degaussing is recommended in any case, since discs received from the manufacturer sometimes have test patterns left on them and aren't truly blank. Most 96tpi manufacturers don't want to contend with these issues, so they simply specify that you can read, but not write. () /\ .-.-. /\ Kevin Kenny ()() < > \ / (__) University of Illinois at Urbana-Champaign /\ \/ V /\ UUCP: {ihnp4,pur-ee,convex}!uiucdcs!kenny "When in doubt, CSNET: kenny@UIUC.CSNET lead trumps." ARPA: kenny@B.CS.UIUC.EDU (kenny@UIUC.ARPA)