Re: 4.3BSD-Reno install on MicroVAX II

jkunz(a)unixag-kl.fh-kl.de wrote: OK, I'll add one. Yes. Hmm, I thought this was enough info for folks to figure out that components/compress.tar is the right tarball... It's in the components directory, as opposed to the tape distribution directory for any particular release, because it's a grabbed-out BSD component that can be used with any release. The tape distribution directories have exactly what goes on the tape in the format it goes there, nothing more, nothing less. I have something along these lines on the front page of the Quasijarus project. But sure, I should elaborate. I will when I respond to Warren's PUPS/TUHS reorg thing, which I'm still procrastinating on. :-) -- Michael Sokolov Harhan Engineering Laboratory Public Service Agent International Free Computing Task Force International Engineering and Science Task Force 615 N GOOD LATIMER EXPY STE #4 DALLAS TX 75204-5852 USA Phone: +1-214-824-7693 (Harhan Eng Lab office) E-mail: msokolov(a)ivan.Harhan.ORG (ARPA TCP/SMTP) (UUCP coming soon) Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id EAA16405 for pups-liszt; Wed, 7 Jun 2000 04:39:39 +1000 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.edu.au) Received: from mmail.bia-bg.com (qmailr(a)mmail.bia-bg.com [212.116.129.29]) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with SMTP id EAA16400 for <pups(a)minnie.cs.adfa.edu.au>; Wed, 7 Jun 2000 04:39:28 +1000 (EST) (envelope-from pzh(a)bia-bg.com) Received: (qmail 16852 invoked by uid 0); 6 Jun 2000 17:36:05 -0000 Received: from mmail.bia-bg.com (pzh(a)212.116.129.29) by mmail.bia-bg.com with SMTP; 6 Jun 2000 17:36:05 -0000 Date: Tue, 6 Jun 2000 20:36:05 +0300 (EET DST) From: Peter Zhivkov <pzh(a)bia-bg.com> To: Michael Sokolov <msokolov(a)ivan.Harhan.ORG> cc: pups(a)minnie.cs.adfa.edu.au Subject: Re: 4.3BSD-Reno install on MicroVAX II In-Reply-To: <0006061447.AA13729(a)ivan.Harhan.ORG> Message-ID: <Pine.LNX.3.95.1000606203205.16815A-100000(a)mmail.bia-bg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk On Tue, 6 Jun 2000, Michael Sokolov wrote: people, please administer proper dosage...and do not let patients out of the boundaries of the asylum... P.S. please take me off the quasijarus list Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id FAA16600 for pups-liszt; Wed, 7 Jun 2000 05:10:46 +1000 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.edu.au) Received: from guildenstern.shaffstall.com (cisdn-2.on-net.net [206.229.84.2]) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) with ESMTP id FAA16596 for <pups(a)minnie.cs.adfa.edu.au>; Wed, 7 Jun 2000 05:10:41 +1000 (EST) (envelope-from jasomill(a)shaffstall.com) Received: from localhost (jasomill@localhost) by guildenstern.shaffstall.com (8.9.3/8.9.3) with ESMTP id OAA05700 for <pups(a)minnie.cs.adfa.edu.au>; Tue, 6 Jun 2000 14:06:40 -0500 X-Authentication-Warning: guildenstern.shaffstall.com: jasomill owned process doing -bs Date: Tue, 6 Jun 2000 14:06:40 -0500 (EST) From: "Jason T. Miller" <jasomill(a)shaffstall.com> To: pups(a)minnie.cs.adfa.edu.au Subject: RX50 on RQDX3 on 2.11BSD In-Reply-To: <200005261407.AAA44464(a)minnie.cs.adfa.edu.au> Message-ID: <Pine.LNX.4.10.10006061323100.5676-100000(a)guildenstern.shaffstall.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk Does anyone have experience using the RX50 floppy drive under 2.11BSD? I patched my FreeBSD kernel to handle RX50-format (80 cyl / 1 hd / 10 sec) diskettes, and noticed what seemed to be some sort of logical sector interleave (I also have hardware that does physical diskette reads / dumps, which assured me that I was getting the physical data off the disk in the order prescribed by the sector ID address marks); so, back to the old '11 for another round of test-disk making. My test data was simple enough: 512 bytes of 16-bit unsigned integer one, followed by 512 bytes of UINT16 2, usw. to UINT16 800; the easier to figure out the interleave, my precious... But I didna even get that far: observe (testrx50.img is 409,600 bytes): $ dd if=testrx50.img of=/dev/ra12a 800+0 records in 800+0 records out $ dd if=/dev/ra12a of=test 800+0 records in 800+0 records out $ diff testrx50.img test Binary files testrx50.img and test differ WHOA! This shouldn't happen, should it? In my late-night screwings-around, I recall the following Additional Facts: - Disks formatted with my PC floppy drive (using my kernel hacks - available on request [although until I get them working, no guarantees in re: their applicability to this or any other use; although I will attest that they won't make your kernel crash, at least not in 4.0-STABLE]) usually work okay, but sometimes give hard errors. - Disks formatted with the aforementioned Custom Hardware (a Shaffstall 6000 media conversion system, for the curious) for a) DEC Rainbow, b) RT-11, and c) DECmate II, seem to work flawlessly, at the physical level, but exhibit the below-mentioned quirks, logically. I'll note at this point that the media I'm using is 3M DS/DD 96tpi (_not_ high density), and disks formatted with the 6000 (RT-11) worked perfectly under RSX-11. Also: - The '11/2.11BSD never seem to write the first two sectors, although no error is returned to this effect; in fact, the data in sector three is from offset 1024 in the input data (0x0003 in the above example). Is this due to disk label support or something? The raw (character) device reports itself as read-only, even for root. - The remaining data sometimes (but not always; the specific circumstances involved I have not yet figured out conclusively -- physical interleave, preexisting data (!), or, something else?) carries an interleave, though I admit I haven't figured it out yet (meaning I haven't sat down and done it, not that I don't know how). Finally, I noticed there is no floppy-specific code in the MSCP driver, so all the gory details of floppy control (along with the gory details of the above) must be dealt with by the RQDX3. Anybody got documentation for this little slice 'o heaven? And, er, _really_ finally, is it really true that I can put any HD AT drive (well, any one that sports DS jumpers) on the RQDX3 and it'll function as an RX33? Does this void my field service contract, as my field service engineer is growing bored with staying up all night trying to understand funky DEC floppy hardware, as Parts currently has Guinness on a 180-day lead and it is a neccessary part of such an operation? Wonder what DEC would think of allowing (providing?) old PDP hardware docs for the archive? JasoMill