New subject: New Compress -- needs bigger info flag readme whatever

6 Jun 2000

jkunz(a)unixag-kl.fh-kl.de wrote:

...
  Ahhh! Why is there no note in the distribution
directory?  
OK, I'll add one.

...
  Ehhh? And where to get the code? Why is there no hint
to it on the web
 page? Distributions/4bsd/components/compress.tar ??? 
Yes.

...
  The Web-Page says: "The strong compression code
is available as a 
 separate package in the BSD distribution archive (it is itself 
 uncompressed)." 
Hmm, I thought this was enough info for folks to figure out that
components/compress.tar is the right tarball...

...
  But the Distributions/4bsd/4.3BSD-Quasijarus0a
directory
 does not contain it. 
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.

...

4.3BSD-Quasijarus is more original CSRG than 4.3BSD-Reno. Reno doesn't follow
 the True UNIX line of V1 thru V7 thru 4.3BSD, Quasijarus does.   [...]
 Is there some documentation available about this?  
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)
...
 From Peter Zhivkov &lt;pzh(a)bia-bg.com&gt; Wed Jun  7
03:36:05 2000 
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 &lt;pups(a)minnie.cs.adfa.edu.au&gt;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 &lt;pzh(a)bia-bg.com&gt;
To: Michael Sokolov &lt;msokolov(a)ivan.Harhan.ORG&gt;
cc: pups(a)minnie.cs.adfa.edu.au
Subject: Re: 4.3BSD-Reno install on MicroVAX II
In-Reply-To: &lt;0006061447.AA13729(a)ivan.Harhan.ORG&gt;
Message-ID: &lt;Pine.LNX.3.95.1000606203205.16815A-100000(a)mmail.bia-bg.com&gt;
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:

...
  4.3BSD-Quasijarus is more original CSRG than
4.3BSD-Reno. Reno doesn't follow
 the True UNIX line of V1 thru V7 thru 4.3BSD, Quasijarus does. Reno breaks all
 traditional CSRG ideology and is not CSRG in any way other than having been
 built in Evans Hall. 4.3BSD-Quasijarus hasn't been built in Evans Hall, but is
 CSRG in every other way.

people, please administer proper dosage...and do not let patients out
of the boundaries of the asylum...

...
  --
 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)

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)
...
 From "Jason T. Miller"
&lt;jasomill(a)shaffstall.com&gt; Wed Jun  7 05:06:40 2000 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 &lt;pups(a)minnie.cs.adfa.edu.au&gt;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 &lt;pups(a)minnie.cs.adfa.edu.au&gt;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" &lt;jasomill(a)shaffstall.com&gt;
To: pups(a)minnie.cs.adfa.edu.au
Subject: RX50 on RQDX3 on 2.11BSD
In-Reply-To: &lt;200005261407.AAA44464(a)minnie.cs.adfa.edu.au&gt;
Message-ID: &lt;Pine.LNX.4.10.10006061323100.5676-100000(a)guildenstern.shaffstall.com&gt;
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