TUHS

tuhs@tuhs.org

16 participants
6536 discussions

by Warren Toomey

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

17 years, 1 month

Re: [Unix-jun72] UNIX V1 bootstrap

by James A. Markevitch

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

17 years, 1 month

Re: [Unix-jun72] UNIX V1 bootstrap

by James A. Markevitch

> > 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(a)magic.com / 5/17/08 jam(a)magic.com -- hacked to copy 407-format a.out files / b bos 1700 / u warm unix 1704 / 1 cold unix 1734 / 2 unassigned 1764 mov sp,r5 mov (r5)+,r3 / argc cmp $3,r3 / must be 3 bne badcmd / else error tst (r5)+ mov (r5)+,r4 / get first arg cmpb (r4),$'b bne 1f mov $1700,r3 mov $4,r4 br 2f 1: cmpb (r4),$'u bne 1f mov $1704,r3 mov $30,r4 br 2f 1: cmpb (r4),$'1 bne 1f mov $1734,r3 mov $30,r4 br 2f 1: cmpb (r4),$'2 bne badcmd mov $1764,r3 mov $14,r4 2: / open file mov (r5),r5 mov r5,0f sys open; 0:..; 0 bes error mov r0,r1 sys seek; 20; 0 bes error / open rf0 and seek to correct block sys open; disk; 1 bes error mov r0,r2 mov r3,0f sys seek; 0:..; 0 bes error / copy file from file to disk one block at a time 1: mov r1,r0 sys read; buf; 512. mov r0,r5 mov r2,r0 sys write; buf; 512. bes error dec r4 beq 3f tst r5 bne 1b 3: sys exit error: mov $1,r0 sys write; 1f; 2 4 sys exit 1: <?\n> badcmd: mov $1,r0 sys write; 1f; 2 4 sys exit 1: <?\n> disk: </dev/rf0\0> .even buf: .=.+512.

17 years, 1 month

[Unix-jun72] UNIX V1 bootstrap

by James A. Markevitch

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

17 years, 1 month

[Unix-jun72] early C library source found

by Warren Toomey

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

17 years, 2 months

[Unix-jun72] s1 fragments are now in the svn repository

by Warren Toomey

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

17 years, 2 months

Setting System V up for local echo TTYs?

by Derek Peschel

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

17 years, 2 months

[Unix-jun72] I recovered 100% of the s1 src code fragments

by Doug Merritt

FYI I recovered 100% of the s1 src code fragments; I presume this is of interest to y'all on this list, yes? Actually I started to do so years ago, got distracted, and just started again April 18, purely by coincidence, just days before this list started -- quite a coincidence! Then I went off trying to chase down the Multics source that Ken and Dennis and Doug and Joe et al wrote, which eventually lead me to discover the V1 source listing at bitsavers, and googling *that* lead me to this (apparently stealth-mode) list. (I have no gmail, btw, so I haven't requested to join, nor to svn.) And reading the archived messages, wow, you guys got an amazing amount done in a very short time! Congrats! (Boy am I glad I don't have to do all that by myself after all...) To give you an idea of what I got out of those frags, here's the file listing of the result: acct.s cc.c fed2.s ar.s chmod.s fed3.s as11.s chown.s form1.s as12.s cmp.s form2.s as13.s colon.s form3.s as14.s cp.c form4.s as15.s date.s form5.s as16.s db1.s form6.s as17.s db2.s fstrip.s as18.s db3.s getty.s as19.s db4.s glob.c as21.s dc1.s goto.c as22.s dc2.s if.c as23.s dc3.s init.s as24.s dc4.s ld1.s as25.s dc5.s ld2.s as26.s df.s ldx.s as27.s dsw.s ln.s as28.s dusg.s login.s as29.s ed3.s ls.s bas0.s exit.c unknown_frag64.c bas1.s fc.c cat.s fed1.s (Warren's "Missing commands" missive in the list archive said "maki" is present as a v2 binary, but don't forget that its *source* is present also, in /usr/ken/maki.s and also /usr/sys/maki.s) Note that ed1.s and ed2.s are missing. Their source code simply wasn't in any of the fragments (which means, was not on the s1 disk image). The "unknown_frag64.c" is almost certainly just a random useless C program, not part of the actual Unix source (it doesn't look like interesting code, and the indentation is random -- it's not written in The One True Style). Warren's frag68 and frag69 are not true fragments, so given all the above, the reconstitution of s1 is complete (but needs double checking, e.g. by people trying to assemble and run the source). NOTE: I am not sure of precisely when s1 dates to, but many of these source files use the "jsr r5, 0: <buffer>" calling convention that requires writable code segments -- did that go away sharply with the pdp11/20 to pdp11/45 move, or no? Also note that these source files have both 0405 *and* 0407 types of preludes, and that is also true of some of the binary disk blocks on the s1 image that happen to contain executable commands (I've taken only a brief look at the latter so far). On the subject of the TEK graphics display, don't forget that good old xterm(1) has a Tektronix 4014 mode! I don't remember how much variation Tektronix had between different models (I may still have some manuals somewhere, not sure), but conceivably that's a starting point. P.S. Since doing the above, I've been working on a disassembler; it works ok, and emits of course 'as'-syntax asm, and accepts a markup- command file to allow e.g. introduction of human-chosen labels for octal addresses -- and I'm nearly done adding the ability to produce "1f" "1b" style branch labels -- I created a bunch of bugs in the process of doing that. When I get that settled down better, I intend to use it for very much the same purpose that Warren was talking about in the list archives. I also wrote a tap-format unarchiver from scratch to re-extract s2, but unsurprisingly that was a wasted effort; Ken's extraction did in fact recover everything in s2 that there is to recover. I should have known. :-) P.P.S. While you're asking Ken and Dennis for more listings, ask them for any "Unics" PDP 7 listings they may have, too! I suspect Ken even has a Space Travel listing lying around, although I don't think he has ever mentioned it over the decades. P.P.P.S. The Computer History Museum is opening its exhibit of the second Babbage engine replica tomorrow; I'm looking forward to it. Doug Merritt -- Professional Wild-eyed Visionary Member, Crusaders for a Better Tomorrow

17 years, 2 months

[Unix-jun72] boot_080511.tar.gz -- UNIX V1 bootstrap

by James A. Markevitch

17 years, 2 months

[Unix-jun72] organization of fs tree

by Tim Newsham

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/

17 years, 2 months

Jump to page:

2025

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