TUHS May 2008

tuhs@tuhs.org

32 participants
86 discussions

Re: [Unix-jun72] Minor bug in sources e09-07

by James A. Markevitch

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

16 years, 7 months

[Unix-jun72] Minor bug in sources e09-07

by James A. Markevitch

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

16 years, 7 months

[Unix-jun72] Missing commands

by Warren Toomey

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

16 years, 7 months

[Unix-jun72] login prompt!

by Tim Newsham

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/

16 years, 7 months

[Unix-jun72] ... in case you wanted to play along.

by Tim Newsham

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/

16 years, 7 months

[Unix-jun72] UNIX running up to init, I think

by James A. Markevitch

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

16 years, 7 months

[Unix-jun72] OCR of PreliminaryUnixImplementationDocument_Jun72.pdf

by James A. Markevitch

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

16 years, 7 months

[Unix-jun72] Minor errors

by Hellwig Geisse

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

16 years, 7 months

[Unix-jun72] warning: 1972_stuff as!

by Tim Newsham

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/

16 years, 7 months

[Unix-jun72] cold boot tape

by Tim Newsham

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/

16 years, 7 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS May 2008