Subject: Re: Nsys kernel: a possible solution

From: [email-masked]
Date: Wed, 12 Jan 2000 22:04:14 -0500

I'm going to have to digest the suggestions.  You're right
that the nominal dates in nsys are implausible by
more than 6 months.  Also that the modes are peculiar.

Do you have the structures that describe the tap formats you tried?
I will check them against the 2nd and 3rd edition documented
formats (which I might have mistranscribed, even leaving
aside possible mid-course changes).

---

From: [email-masked]
Date: Thu, 13 Jan 2000 16:20:58 -0500

> Hypothesis: at the time when the nsys-bits tape was written, tp(1) did
 > not yet exist, but at the same time you wanted to capture the current
 > system details. So, you modified tap(1)'s format to have the bottom
 > 8 bits of the new 16-bit filemode, and also stored the 32-bit tap(1) time

I think you've convinced me.  I've installed a -n flag for my tapfs.

---

From: [email-masked]
Date: Thu, 13 Jan 2000 23:46:25 -0500

I fancy that this
	nsys
        	If the decoding of the date on the tape is correct (Aug 1973),
        	this is the source for the earliest C version of Unix
        	likely to be recovered.  `nsys' meant the C version
        	rather than the assembly version, and Aug 73 is plausible for
        	a running instance of this system.
most likely refers to a date written on the paper label .
Because I don't have the tape at hand, I can't verify this.

I put tar versions of v3 and v4 in incoming.  Notes:
Total size about 1.2MB.  v4 especially depends on
a macro package I can't locate--evidently a predecessor
of -man .   (local versions of -man announce 
"wrong version of man entry macros (use -man6 if available)".
v3 especially is full of explicitly underlined things with
backspaces and _, and the _ tend to overwrite the letters
on the display.

	Dennis