- TUHS - www.tuhs.org

by David Evans

Yanked a SCSI disk and the penguin could manage dding the simh image on to it. The PDP-11 booted quite happily. -- David Evans (NeXTMail/MIME OK) dfevans(a)bbcr.uwaterloo.ca Ph.D. Candidate, Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/ University of Waterloo "Default is the value selected by the composer Ontario, Canada overridden by your command." - Roland TR-707 Manual

22 years, 5 months

1
0
0 0

Re: [pups] Making a TK50 2.11BSD boot tape for an 11/73

by norman＠nose.cs.utoronto.ca

If all that is needed is to concatenate three files into a single tape file, with each new file aligned on a block boundary, isn't (for f in f1 f2 f3; do dd <$f conv=sync; done) >/dev/rmt0 sufficient? The only time I had to do anything like this, the target system was a MicroVAX; hence the tape had to have ISO labels, and the program to be booted a particular tape filename. I don't remember how I handled that; probably I used one of the several public-domain tape-label-writing programs. But that was a VAX; I would assume an 11/73 doesn't have so much enforced complexity in its firmware.

22 years, 5 months

1
0
0 0

[pups] Making a TK50 2.11BSD boot tape for an 11/73

by David Evans

Howdy. I'd like to confirm that somebody has successfully made a TK50 boot tape for 2.11BSD using a TK50Z attached to some other Unix box. In my case it will likely have to be Linux, though IRIX might be doable. It *should* work, after all, but, well, you know. :) -- David Evans (NeXTMail/MIME OK) dfevans(a)bbcr.uwaterloo.ca Ph.D. Candidate, Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/ University of Waterloo "Default is the value selected by the composer Ontario, Canada overridden by your command." - Roland TR-707 Manual

22 years, 5 months

5
17
0 0

Re: [TUHS] unsigned division in V7's C

by Wolfgang Helbig

Warren replies: >Not sure if: > >http://www.tuhs.org/Archive/PDP-11/Bug_Fixes/Net.v7bugs/0017 > >is a bug fix for this. And Dennis replies: >Does > http://www.cs.bell-labs.com/who/dmr/odd.html#muldiv >suffice to explain the behavior Thanks for the replies, but the bug I found is about unsigned int's and not long int's. The V7 C code simply the DIV instruction for unsigned division. The dividend is put in the low word of a register pair with the upper word cleared. When the divisor is >= 2^15, DIV interprets it as a negative integer and produces the result (N = 2^16): N - a/(N-b) instead of a/b, and a%(N-b) instead of a%b. This explains the bug I've sent yesterday. I is easily fixed, since when b >= N/2 and a < N, then a/b is either zero or one. And there is another bug when using DIV for unsigned integers: If b = 1 and a >= N/2, then a/b >= N/2, that is a signed overflow. With V7 on Bob Supniks simulator (2.10), I get 60000/1: 0, 60000%1: 60000 DIV did not change the dividend because of overflow. Again a fix is easy: With unsigned ints, don't use DIV to divide by one. In all other cases, DIV produces the correct unsigned results, if the dividend is less N, that is its high word is zero. I wonder why these bugs went unnoticed. Greetings Wolfgang

22 years, 6 months

1
0
0 0

re: unsigned division in V7's C

by Dennis Ritchie

Helbig observed > while wondering how unsigned integer division is implemented in C > I found a bug in V7: a/b and a%b with b >= 2^15 does not give the expected > results, if a and b are unsigned int's. Does http://www.cs.bell-labs.com/who/dmr/odd.html#muldiv suffice to explain the behavior? Dennis

22 years, 6 months

1
0
0 0

unsigned division in V7's C

by Wolfgang Helbig

Hi, while wondering how unsigned integer division is implemented in C I found a bug in V7: a/b and a%b with b >= 2^15 does not give the expected results, if a and b are unsigned int's. Was this bug ever noticed or even fixed? Greetings, Wolfgang Here is a program showing the bug: main() { unsigned int a, b; a = 60000; b = 40000; printf("a/b: %u, a%%b: %u\n", a/b, a%b); b = 25000; printf("a/b: %u, a%%b: %u\n", a/b, a%b); } The above program prints a/b: 65534, a%b: 8928 a/b: 2, a%b: 10000 The first line should be of course a/b: 1, a%b: 20000

22 years, 6 months

1
0
0 0

Re: Patches to improve 6th Edition

by norman＠nose.cs.utoronto.ca

A belated rejoinder to: This bug existed from (at least) the Fifth up until the Eighth editions from 1127 (BTL research). The Ninth edition had much rewrites in the kernel and the algorthim was changed at that point. You're welcome. I can't remember, though, whether I fixed it on purpose or as part of the many general cleanups and restructurings I did at that point. And I didn't do enough of it; recently I discovered a dumb problem that I probably introduced in the same cleanups, wherein the i-node allocated for a file that couldn't be created because the file system was full and the directory entry couldn't be written was left allocated but nameless ... Norman Wilson Toronto ON

22 years, 6 months

1
0
0 0

Re: [pups] Mail delivery failed: returning message to sender

by pete＠dunnington.u-net.com

On Jan 6, 19:01, Wolfgang Helbig wrote: > Richard L. Hamilton searches: > >The files > > > >http://minnie.tuhs.org/UnixTree/V7/usr/sys/dev/rl.c > >http://minnie.tuhs.org/UnixTree/V7/usr/sys/conf/mkconf.c > > > >don't seem to match - mkconf.c wants to generate references to > >rlopen() and rlclose(), which don't exist in that version of rl. > >What I'm really looking for is the right version of driver(s) etc. > > It seems that a version of the rl driver that matches > mkconf, was never supplied by the bell labs. > > As a workaround delete the rl entry in cdevsw and the line > "int rlopen,..." from c.c. This will give you a block device of the rl disk, > but no raw device. Hmm... my 7th Edition distribution /usr/sys/dev/rl.c certainly *does* have rlopen() and rlclose(). If you want them, I can send rl.c and the matching mkconf.c to you, or to Warren, along with the rl1conf and rl2conf (for RL01 and RL02 disks) from /usr/sys/conf/ and any other files needed (if someone can tell me what might be required -- it's a long long time since I looked at any of this. The distribution came for an 11/23 with 2 x RL02, and it also has some special source files for 11/23, 11/34, etc ("small machines") including tests for recovery from segmentation traps in floating point (which isn't the same on all PDP-11 models), and an RK driver from the Boston Children's Museum which handles overlapped seeks on multiple drives. I'll be away for a couple of days so don't expect a prompt reply, but the source is online here so I can easily copy a few files when I get back. -- Pete Peter Turnbull Network Manager University of York

22 years, 6 months

1
0
0 0

[pups] Mail delivery failed: returning message to sender

by Wolfgang Helbig

Richard L. Hamilton searches: >The files > >http://minnie.tuhs.org/UnixTree/V7/usr/sys/dev/rl.c >http://minnie.tuhs.org/UnixTree/V7/usr/sys/conf/mkconf.c > >don't seem to match - mkconf.c wants to generate references to >rlopen() and rlclose(), which don't exist in that version of rl. >What I'm really looking for is the right version of driver(s) etc. It seems that a version of the rl driver that matches mkconf, was never supplied by the bell labs. As a workaround delete the rl entry in cdevsw and the line "int rlopen,..." from c.c. This will give you a block device of the rl disk, but no raw device. Greetings, Wolfgang

22 years, 6 months

1
0
0 0

[pups] V7 RL02 driver questions

by Richard L. Hamilton

The files http://minnie.tuhs.org/UnixTree/V7/usr/sys/dev/rl.c http://minnie.tuhs.org/UnixTree/V7/usr/sys/conf/mkconf.c don't seem to match - mkconf.c wants to generate references to rlopen() and rlclose(), which don't exist in that version of rl.c. What I'm really looking for is the right version of driver(s) etc. so that I can regenerate the rl2unix kernel in the V7 image available for use with simh, so that I can add or tweak drivers, eventually adding the dz driver so I can run multiple "terminals" with telnet access. -- mailto:rlhamil@mindwarp.smart.net http://www.smart.net/~rlhamil

22 years, 6 months

1
0
0 0

db(I) in Unix V6

by Wolfgang Helbig

Hi, tinkering at V6--now I need db(I). It works fine, but three features that are described in its manual page seem to be missing: - The names of the general registers (r0, ...) are not build in, at least db only responds with `?' to `r0'. I can examine the registers via the `$' command though. - The '*' feature doesn't work, i.e. `*_main' gives me a `?'. - I can't specify a number being relocatable, i.e. '10r' gives me a `?'. Is this an exercise to the user? Did anyone solve the exercise. Or did I just not understand the manual page? Greetings, Wolfgang

22 years, 6 months

1
0
0 0

Re: [pups] V7 setjmp/longjmp

by Wolfgang Helbig

Michael Davidson distrusted: >Note that this means that r4, r3 and r2 get restored to the values >that they had at the time that the next stack frame was established >(ie when the "next" function down was called from the original context) >and that these are not necessarily the values that they had at the >moment when the original call to setjnp returned. Hence the various >caveats about not relying on the value of any register variables >after returning via longjmp. You can trust register variables when setjmp() returns the second time. Then the registers are restored to the values they had when the "next" function was called, that is the "values as of the time longjmp() was called" (quoted from longjmp(3)'s man page. Thus any variable behaves the same, regardless of its storage class. By the way, this is not the case in V6. The register variables-- and only the register variables-- are restored to the values as of the time setexit() was called. (In V6 "setjmp()" is named "setexit()" and "longjmp()" is named "reset()"). Thus the value of a variable depends on its storage class. If it is register, you get the value when setexit() was called, if it is not register, you get the value when reset() was called. This might be considered a bug. Greetings Wolfgang

22 years, 6 months

2
1
0 0

[pups] V7 setjmp/longjmp

by bwc＠coraid.com

Looking thru the code for setjmp/longjmp (/usr/src/libc/gen/setjmp.s), and have a question. Longjmp seems to make an attempt at restoring register two through four, but setjmp doesn't save them. Where do these register get saved from? Brantley Coile

22 years, 6 months

2
1
0 0

Re: Patches to improve 6th Edition

by Wolfgang Helbig

some hours ago I wrote: >I ask this, because my system crashes ones in a while. But I changed it >here and there, so it might be my fault. It *was* my fault! So far, I have only found one bug in V6: The size of swapmap and coremap are configured too small, so they might overflow. The sizes don't take account of shared text segments, that produce extra chunks of free memory. In V6 there are 19 pure executables, so their minimal size should be (NPROC+19)*2, or better yet (NPROC+NTEXT)*2, where NTEXT should be set to 20 instead of 40 as distributed in param.h . I don't think this bug ever showed up. It is very unlikely. In V7 these sizes are choosen to be even smaller than NPROC and even with its many pure executables, I don't think V7 ever crashed because of this bug. So, with the only exception reported by Brian S. Walden, there seem to be no bugs in V6 that crash systems. Greetings Wolfgang

22 years, 6 months

1
0
0 0

Re: [TUHS] Re: Patches to improve 6th Edition

by Wolfgang Helbig

> >In article by Mirian Crzig Lennox: >> This reminds me that I fixed a couple of "bugs" (some outright bugs, >> and some mere behaviours which I didn't quite like) in playing with my >> V6/simh environment, and I'm wondering if there is a place I should >> submit them in case others might be interested. [ .. ] Mirian, I'd love to see your fixes! By the way, you might want to look at http://www.tuhs.org/Archive/PDP-11/Bug_Fixes/V6enb for some changes I applied to V6. Thanks to Warren and Mirian for helping me to undig the "50 bugs tape"! But the "bugs fixes" look more like performance enhancements. Do you know any real bugs in V6? By "real" I mean a bug, that might crash the system. I ask this, because my system crashes ones in a while. But I changed it here and there, so it might be my fault. Greetings, Wolfgang > >P.S Does anybody want to backport vi to 6th & 7th Edition?! :-) Hmm. It's less work to learn ed, so I took that path :-).

22 years, 6 months

1
0
0 0

Re: Patches to improve 6th Edition

by Mike Haertel

In article by Warren Toomey: > P.S. Does anybody want to backport vi to 6th and 7th Edition?! :-) The 2BSD tape contains vi source code that can *definitely* be built on 7th edition (I've done it, it was easy) and supposedly can also be used to build a 6th-edition "native" vi if you're willing to backport the V7 C compiler (I haven't done that yet). Since many people in 2BSD's time frame would not have had access to V7 systems or V7-ish C compilers, the 2BSD tape also contains a vi binary for V6 systems. I think 2BSD was released around the same time as V7, and had an assumption that many people would not yet have access to V7, and so would want to use 2BSD as an add-on to V6 systems. Since 6th edition didn't have environment variables, the 2BSD/V6 version of vi would get the terminal type from a file that mapped hardwired serial lines to terminal type names. I think it was called /etc/htmp. By the way, does anybody else think that vi should have been upgraded to vii when V7 came out? :-)

22 years, 6 months

1
0
0 0

Re: Patches to improve 6th Edition

by Brian S Walden

Yes there are other bugs you will want to fix as well if you are using v6 heavily and not on slow hardware (e.g. a simulator). In the inode allocation route (ialloc()) in /usr/sys/ken/alloc.c there is a bug in the placement of the loop: tag. You just have to move it up two line to above the while() loop. See the diff below. This rare Ken Thompson bug was found in 1988 on an Amdahl UTS machine that the hardware finally became fast enough that it caused us panics. This bug existed from (at least) the Fifth up until the Eighth editions from 1127 (BTL research). The Ninth edition had much rewrites in the kernel and the algorthim was changed at that point. Since it was in UTS, it must have been in the porting base of System V Release 2. This code is the basis for the System V filesystem, so it probably didn't exist in BSD releases since they used their fast filesystem (cylinder groups, et al.) which became UFS. It's amazing thet with the amount of eyes on it (via Lions Commentary, etc.) it was not spotted earlier. It would be good to get a collection of all "unreleased" bug fixes that others may have. *** alloc.c.orig Fri Dec 27 23:23:30 2002 --- alloc.c Fri Dec 27 23:23:30 2002 *************** *** 163,171 **** int i, j, k, ino; fp = getfs(dev); while(fp->s_ilock) sleep(&fp->s_ilock, PINOD); - loop: if(fp->s_ninode > 0) { ino = fp->s_inode[--fp->s_ninode]; ip = iget(dev, ino); --- 163,171 ---- int i, j, k, ino; fp = getfs(dev); + loop: while(fp->s_ilock) sleep(&fp->s_ilock, PINOD); if(fp->s_ninode > 0) { ino = fp->s_inode[--fp->s_ninode]; ip = iget(dev, ino); In article by Mirian Crzig Lennox: > This reminds me that I fixed a couple of "bugs" (some outright bugs, > and some mere behaviours which I didn't quite like) in playing with my > V6/simh environment, and I'm wondering if there is a place I should > submit them in case others might be interested.

22 years, 6 months

1
0
0 0

Re: Re: [TUHS] Re: Patches to improve 6th Edition

by John Holden

> P.S Does anybody want to backport vi to 6th & 7th Edition?! :-) 'vi' definately works with I+D space under edition 7 (11/44/45/50/53/55/70/73) There was also an overlayed version for I space only under BSD 2.?, but it was sooooo slow as to be almost useless

22 years, 6 months

1
0
0 0

V6: 50 bugs tape

by Wolfgang Helbig

Hi, someone on this list mentioned a '50 bugs tape', which contains bug fixes to Unix V6. Is this list somewhere in the archive? Thank you, Wolfgang

22 years, 6 months

4
5
0 0

Re: [TUHS] In V6 exit(): wakeup(&proc[1])) unnecessary?

by Wolfgang Helbig

>>When a process terminates (in sys1.c/exit()), it explicitly wakes up >>the init process. In light of the fact, that every process has a parent, >>this extra wakeup(&proc[1]) seems unnecessary. > >I believe this is meant to handle the case where a process exits >without having called wait() on its children. > >Imagine two processes, A and B, where A is B's parent and A's parent >is some process other than init. B calls exit(), becomes a zombie, >and awakens A. Some time later, A calls exit() without ever having >called wait(). This will cause B to become a child of init, and as B >is a zombie, init should awaken so that B can die. However, A might >have any number of zombie children, and it would be redundant to call >wakeup(&proc[1]) for each one. Therefore, the wakeup call to init is >done up front, whether it is needed or not. This does result in some >unnecessary wakeup calls but on the whole it seems a good tradeoff for >code simplicity. Oh, I see! So the condition to wakeup init would be "Do I have any zombie children"? The code as it is is simpler. But harder to understand. Thank you very much for your help! Greetings Wolfgang Helbig

22 years, 6 months

1
0
0 0

In V6 exit(): wakeup(&proc[1])) unnecessary?

by Wolfgang Helbig

Hi, encouraged by the profound answers I thankfully recieved to my previous question about the Unix V6 kernel, here is another one: When a process terminates (in sys1.c/exit()), it explicitly wakes up the init process. In light of the fact, that every process has a parent, this extra wakeup(&proc[1]) seems unnecessary. Furthermore, the "goto loop:" at the end of exit() will never be executed. So is this just defensive programming, or did I miss something? Greetings, Wolfgang Helbig

22 years, 6 months

2
1
0 0

[pups] 11/34

by Robin Birch

Dear All, There is a complete 11/34 for sale on EBay (1 day to go). It comes with a complete V6 with source. Somebody buy it please. This is nothing to do with me, I just saw it tonight. It's in Pontypridd South Wales Cheers Robin -- Robin Birch

22 years, 6 months

2
1
0 0

RE: [TUHS] re: Raise of interrupt level necessary

by Ian King

Yes, I have v6 running on an 11/34; it's amazing how easy it is to corrupt the filesystem. :-) One of these days, I need to dd another fresh system disk (RK05) off my "sacred copy" of a PUPS image (tediously transferred via 9600 baud serial using Warren's excellent vtserver tools). In any case, why do you ask? - Ian -----Original Message----- From: Wolfgang Helbig [mailto:helbig@Informatik.BA-Stuttgart.DE] Sent: Saturday, December 14, 2002 12:48 AM To: tuhs(a)minnie.tuhs.org Subject: Re: [TUHS] re: Raise of interrupt level necessary [snip] I also removed IPL protection from the return sequence of the trap routine, still works. Testing was done on Bob Supnik's SIMH PDP-11 simulator with only one terminal. By the way, is anyone running V6 on a real PDP-11? [snip]

22 years, 6 months

1
0
0 0

re: Raise of interrupt level necessary

by Wolfgang Helbig

>Date: Sat, 14 Dec 2002 15:27:40 -0800 Michael Davidson wrote: >If you think that the "rule" is "no ISR can touch user space while >interrupting a kernel process", then it is display() that breaks >the rule. The point is, that this rule leads to somewhat simpler and therefore better code -- breaking the rule calls for some justification. Calling display() from the clock-ISR is the only place where an ISR does not conform to this rule. Greetings Wolfgang Helbig

22 years, 6 months

1
0
0 0

Re: [TUHS] re: Raise of interrupt level necessary

by Wolfgang Helbig

Dennis, I greatly appreciate your reply. What amazes me most, is the fact that after 20 odd years you still remember those tricky details: >For example, the clock interrupt routine can inspect user >space (for display(), for example, though this is inactive >on the 11/40), and even change it (for profiling). >It does appear that other things (checking for >a direct-from user-mode interrupt) in the clock routine >already guard against these particular problems. To see what happens, I just removed those IPL raising instructions from gword, pword,_savu, _aretu, _copyseg, and _clearseg in m40.s. In fact, it didn't crash the system. At least on my configuration, ISRs don't touch user space while interrupting a kernel process. This rule is broken by the clock ISR, which calls display() unconditionally. Just curious: Is there any other reason beside seeing blinking lights that justifies calling display() 60 times per second and breaking the rule? I also removed IPL protection from the return sequence of the trap routine, still works. Testing was done on Bob Supnik's SIMH PDP-11 simulator with only one terminal. By the way, is anyone running V6 on a real PDP-11? Here is the diff of my modifications to m40.s: # diff m40.s.6 m40.s 44d43 * bis $340,PS 455,456d453 * mov PS,-(sp) * bis $340,PS 472,473d468 * mov PS,-(sp) * bis $340,PS 480d474 * mov (sp)+,PS 485d478 * mov (sp)+,PS 539d531 * bis $340,PS 548d539 * bis $340,PS 594c585 * mov $30340,PS --- . bis $30000,PS 621c612 * mov $30340,PS --- . bis $30000,PS Greetings, Wolfgang Helbig

22 years, 6 months

2
1
0 0

qbus scsi controllers

by Robertdkeys＠aol.com

I know it causes one to salivate like Pavlov's dogs, even thinking about them, but, anyone know of any qbus scsi controllers that might someday come available at anything like reasonable sorts of guildern de realme? (running and ducking for cover....(:+]].....) Just thought I would check. Thanks Bob

22 years, 7 months

1
0
0 0

Re: [TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

by Robertdkeys＠aol.com

The particular webster wqesd4 I have looks like about an '86 or so board, from chip dates, and the main chip that is socketed is marked with "ENGR-SAMPLE"...doh.... Maybe I do have a very early board that won't run with a faster cpu. The rom is a part no. 080469-01 REV 01, if that means anything to anyone, as marked on its paper label. The later sigma board does not have the problem. Oh, well, if I have to run it with a KA630 at slo-poke gait, so be it....(:+\\... There are two diodes, one looks like an ordinary silicon rectifier and one looks like a zener of some sort, possibly, off pin 19 of the 74ls240 at position V2 on the board. Those come off the J6 pin 10 of 10, and are in parallel. Thanks Bob

22 years, 7 months

1
0
0 0

flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

by John Holden

Early ROM revisions on the Webster MSCP controllers were too slow for the KA650 and would often loose interrupts (amoungst other things). Signals such as NPR and BR grants were polled from a pseudo microcode loop which took too long. The RS232 interface doesn't use standard receivers. Check for a 5 volt zener on the input of an 74LS240 (from the 10 pin i/o connector) and add a schottky in parallel (a 1N5818 would do) if one isn't there

22 years, 7 months

1
0
0 0

flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

by norman＠nose.cs.utoronto.ca

If you can read this, the 4-port Wombat (Webster/Sigma ESDI controller) in the KA650 system through which this mail must pass on its way out is working fine, as it has since I installed it in that system a year and a half ago. According to my notes, I had no trouble communicating with the onboard diagnostic monitor (with the board in another KA650 reserved for system testing). I used the monitor quite a bit, starting it many times, first because it took me a long time to realize that the terminator had been left installed backwards in one of the drives (so the drive wasn't visible to the controller no matter what I did to the cables). I don't think I tried the serial port on the back of the Wombat board; instead I uttered the magic commands to load and run the Wombat communication program on the VAX itself. I'd expect this to be more timing-sensitive than the hardware port. In any case it worked fine. Once the controller could see the disks (and I'd done some formatting and some testing with the diagnostics), I tested the Wombat under my oddball version of UNIX, and found what may be an MSCP implementation botch. A UNIBUS/QBUS MSCP storage port gets only one interrupt vector; it is supposed to set one of two flags to indicate whether it is interrupting because there were no command slots and it freed one, or because there were no messages waiting to be read and it supplied one. The Wombat appeared often to be tardy in setting the `message waiting' flag; my port driver often received an interrupt, checked the flags, found nothing to do, and of course dismissed the interrupt without realizing that the controller had in fact reported an I/O completion. (And of course if I halted the system and took a crash dump I found the flag set. It took some real-time tracing to uncover the problem.) It is easy to work around this--instead of relying on the flag, one can go look at the message descriptors to see if there's a new message-- so that is what my driver now does. I have a vague memory that the original Ultrix MSCP driver, whence the current BSD one is probably descended and the current Ultrix one more distantly, already did it that way. Silly me, I programmed from the protocol spec rather than just blindly copying someone else's unexplained code ... None of this explains why Bob Keys is having trouble, but it does suggest to me that the Wombat firmware might have other subtle bugs that are tickled by particular systems, perhaps even timing-dependent problems. (I haven't checked, but it could well be that the interrupt- flag bug would be invisible to a KA630 because it took a little longer to get to that part of the interrupt routine.) I have two Wombat boards with slightly different firmware. (One is labelled RQD11-EC and its diagnostic monitor calls itself WOMBAT; the other is branded by SpectraLogic, I forget what model it calls itself, but the monitor calls itself SLEUTH.) My notes don't say whether they both displayed the interrupt botch. I do know that communications with the diagnostic monitor worked fine with both. The RQD11-EC claimed to have firmware (or perhaps diagnostic monitor) version 2.38. Norman Wilson Toronto ON

22 years, 7 months

1
0
0 0

Re: [TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

by Carl Lowenstein

> From: msokolov(a)ivan.Harhan.ORG (Michael Sokolov) > To: tuhs(a)tuhs.org > Subject: Re: [TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650??? > Date: Thu, 12 Dec 02 23:29:58 PST > > Robertdkeys(a)aol.com wrote: > > > Is there an endemic problem with this style 4 > > port controller running too fast with a KA650 > > compared to a KA630 cpu? > > I have no explanation for your problem, but it has nothing to do > with speed. Q-bus is Q-bus, and it follows Q-bus timing, which is > completely independent of the VAX CPU timing. Yes but there might be CPU spin-loop timing to run the serial maintenance port from the ROM bootstrap code of the controller. Not considered good form -- but such things happen. Some early version of the Sigma RQD11 would work in an 11/73 but not a KA630. I no longer remember the exact symptoms, but I was glad that at the time Sigma was only an 80-mile drive from here. carl -- carl lowenstein marine physical lab u.c. san diego clowenst(a)ucsd.edu

22 years, 7 months

1
0
0 0

Re: [TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

by Robertdkeys＠aol.com

I found out what the problem was.....(sheepishly ducking...(:+\\...). At 3 in the morning I had a typeo in the config file that the old eyeballs did not catch. I had typed in the partitions to allocate to root and swap, as opposed to just the the disks. It compiled fine, but when run, it paniced and dumped itself all over the floor. So much for myopic eyes programming at 3 in the morning..... (:+{{..... Bob

22 years, 7 months

1
0
0 0

Re: [TUHS] flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

by msokolov＠ivan.Harhan.ORG

Robertdkeys(a)aol.com wrote: > Is there an endemic problem with this style 4 > port controller running too fast with a KA650 > compared to a KA630 cpu? I have no explanation for your problem, but it has nothing to do with speed. Q-bus is Q-bus, and it follows Q-bus timing, which is completely independent of the VAX CPU timing. Is the new CPU board firmly seated? Nothing broken or disturbed in the backplane when swapping the boards? > Ultrix seems to handle it better than Tahoe. > It might be speed in the hardware and slight > differences in drivers? Ultrix' MSCP code is vastly superior to anything we've ever had in BSD. I plan to lift the MSCP/SCA framework from Ultrix wholesale in Quasijarus down the line. MS

22 years, 7 months

1
0
0 0

re: Raise of interrupt level necessary

by Dennis Ritchie

Wolfgang Helbig wondered, > While studying the V6 kernel, I search for some rules as when to raise > the interrupt priority level (IPL). I came up with something like this: > A kernel process needs to raise the IPL if a change of data must be atomic and might > be accessed (not necessarily changed) by an IRS. > In light of this rule, some raising of interrupts seem unnecessary: > - In m40.s changes of the user space segmentation registers are bracketed by raising > and lowering the IPL, although these registers are never accessed by an ISR. > - Likewise, in m40.s, just before the trap routine checks the runrun flag and > restores r0, r1 and the user stackpointer, it raises the IPL. I can't see what > possibly should go wrong, if being interrupted while restoring the values. It's quite possible that the code is unnecessarily cautious. In general one does not want an interrupt while something sensitive is in a half-changed state (for example, some of the addressing registers changed, or a stack half-switched). For example, the clock interrupt routine can inspect user space (for display(), for example, though this is inactive on the 11/40), and even change it (for profiling). It does appear that other things (checking for a direct-from user-mode interrupt) in the clock routine already guard against these particular problems. It's been a long time since I've looked at this, however. Dennis

22 years, 7 months

1
0
0 0

flaky webster or sigma WQESD4 and RQD11 controllers on KA650???

by Robertdkeys＠aol.com

I upgraded my MVII KA630 critters to MVIII KA650 critters. The disk controllers in them are the old Webster or Sigma WQESD/4 and SCD-RQD11/EC (same boards). When I upgraded the cpu/ram on one of the machines, and tried to use the onboard formatter rs232 port, the port gave crazy spaces and backspaces continuously after the initial boot signon msg into the controller formatter prom. Changing it to a DQ696 controller and the problem went away. On a second machine, with KA650, it has a tendency to give uda controller initialization errors about 50% of the time when booting. Is there an endemic problem with this style 4 port controller running too fast with a KA650 compared to a KA630 cpu? It sure feels like that. It would be a bummer to have to use the slower cpus on these machines....(:+{{..... Anone else run into these kinds of problems? Ultrix seems to handle it better than Tahoe. It might be speed in the hardware and slight differences in drivers? Any suggestions or thoughts appreciated. Thanks Bob

22 years, 7 months

1
0
0 0

Re: [pups] 2.11BSD images for Simh

by Andru Luvisi

>From Warren: > > These file are now in the Unix Archive on minnie.tuhs.org in > PDP-11/Boot_Images/2.11_on_Simh > > The mirror sites should pick them up soon. >

22 years, 7 months

2
1
0 0

Re: [TUHS] Re: non-broken 4.3BSD set?

by msokolov＠ivan.Harhan.ORG

Robertdkeys(a)aol.com wrote: > I am wondering if > a dd image of a working few start blocks on a > disk could be copied over to a raw formatted > disk from the tape copy, before the miniroot > went on, as part of the boot/install process? This should work. > Michael, what are your thoughts on setting up > the disks, reasonably? Well, every time I need to do this, I do some history reenactment, as this is how Quasijarus Project was originally bootstrapped. I first install Ultrix on the VAX, then write a Tahoe/Quasijarus disk label to the boot disk (by compiling disklabel under Ultrix), and then do the normal 4.3-QJ0a install, at which point the standalone system sees the label and is happy. MS

22 years, 7 months

1
0
0 0

Re: [TUHS] Re: non-broken 4.3BSD set?

by msokolov＠ivan.Harhan.ORG

Robertdkeys(a)aol.com wrote: > Great! Keep me in mind for any testing if you > need it. I currently don't need any testing that I can't do myself, but thanks anyway. > I still am curious as to how many on the lists > are actually running such critters, currently, > on Quasijarus or on Ultrix. Well, Harhan is still up as you can see, despite the incessant bills... Pretty much all my work on Quasijarus since 4.3-QJ0a has been on operational issues, i.e., issues that don't matter much for hobbyists but become important when you use it operationally for your mission-critical computing. All my VAXen are running current unreleased code. The Internet feed is WorldCom/UUNET with a Quasijarus-based router. I wrote all the code for the latter, which will hopefully appear in 4.3-QJ1. I also have an MV3100 running Ultrix whose sole purpose is to interface an Exabyte 8 mm SCSI tape drive to my cluster. Doing backups on TK50s is prohibitively expensive. Some day I hope to find time to port 4.3-Quasijarus to it. > Did you arrive at any reasonable way to do the > initial disklabels and boot blocks so one can > install Quasijarus directly? That was and still is planned for 4.3-QJ1. 4.3-QJ0a and 4.3-QJ0b "officially" support bootstrap only on DEC RA disks. Two of my running MicroVAXen are equipped with the latter (RA72s). I also run one with ESDI disks, as I have equipped many MicroVAXen in the past. I bootstrap the latter via Ultrix (see my other reply). MS

22 years, 7 months

1
0
0 0

Re: [TUHS] Re: non-broken 4.3BSD set?

by Robertdkeys＠aol.com

That is what I do. After several failures, I find that using first NetBSD-1.4.1 boot to both label and install boot blocks, followed by second, NetBSD-1.2 boot and edlabel to trim the labels back to something akin to a Tahoe style label, seems to be the only way that works reliably. The label 1.4.1 writes is different from the Tahoe label, in that it computes incorrect c partition sizes. It does write something that I think is bootblock related that seems to must be there for Quasijarus to boot on my hardware. I am not sure exactly what it is, but using just the 1.2 edlabel does not seem to work reliably. The 1.2 edlabel seems to write a correct c size partition, though, after the 1.4.1 bits are put on. I ought to dd off the binary bits and see what is actually being written. But, the above seems to work, for me, and got my crashed disks back up a few minutes ago, after hours of prom formatting....(:+{{..... Anyway, that is how I get the machine up. If there is a better or easier way, someone holler. I am wondering if a dd image of a working few start blocks on a disk could be copied over to a raw formatted disk from the tape copy, before the miniroot went on, as part of the boot/install process? An undersized disk label with reasonably sized a and b partitions and a small but installable h partition (big enough for the usr tarball to fit on) should allow a bootable system to be installed. From that it could be set up on a second disk with correctly sized labels. Or, when the tape was written, a selection of disk boot/label images could be set up and a correct one written to the boot tape for the target disk install. What other ways could this be done? Michael, what are your thoughts on setting up the disks, reasonably? Thanks Bob

22 years, 7 months

1
0
0 0

Re: [TUHS] Re: non-broken 4.3BSD set?

by Robertdkeys＠aol.com

Great! Keep me in mind for any testing if you need it. I have 4 Qbus VAXentoyz that mostly just sit and play, when the HD's stay up. Of late ESDI drives have been giving me fits, but maybe I can scrounge up a few more in the local MooU surplus feeding frenzy diving pits. Maybe, someday, some scsi mscp cards might float up from the depths! (dream on.....(:+}}...) I still am curious as to how many on the lists are actually running such critters, currently, on Quasijarus or on Ultrix. I mostly play with mine, doing some roffing and TeXing, and porting a few minor tidbits. Did you arrive at any reasonable way to do the initial disklabels and boot blocks so one can install Quasijarus directly? The only clean way I can do it is to use two other OS installs that put enough bits there that Quasijarus is happy. There ought to be an easier way. Anyway, keep me posted as to when Quasijarus 0b might become reality. Thanks Bob Keys

22 years, 7 months

2
1
0 0

Re: [TUHS] Re: non-broken 4.3BSD set?

by msokolov＠ivan.Harhan.ORG

Robertdkeys(a)aol.com wrote: > It was Q0A. Has there been any later development > of it, of interest? Yes, there has been. The only problem is that I still haven't managed (in 3 years) to find time to spin it into a release. :-( There is some hope, though, that I'll find a bit of time (enough to spin out the 4.3-QJ0b release) this winter. MS

22 years, 7 months

1
0
0 0

Re: [TUHS] Re: non-broken 4.3BSD set?

by Robertdkeys＠aol.com

It was Q0A. Has there been any later development of it, of interest? Thanks Bob

22 years, 7 months

1
0
0 0

Oops.

by Andru Luvisi

Sorry. Wrong list. That was meant for PUPS. Andru -- Andru Luvisi, Programmer/Analyst Quote Of The Moment: Just once, I wish we would encounter an alien menace that wasn't immune to bullets. -- The Brigadier, "Dr. Who"

22 years, 7 months

2
2
0 0

Re: [TUHS] Re: non-broken 4.3BSD set?

by msokolov＠ivan.Harhan.ORG

Robertdkeys(a)aol.com wrote: > [...] I just used the quasijarus > 0a source tarball (that is supposed to be Tahoe) [...] It is. > Out of curiosity, anyone still running a 4.3BSD > box? I had a couple microVAXes up with it until > my ESDI drives went bellyup a few days back. Do you mean the plain original 4.3 or enhanced versions like 4.3-Quasijarus? The plain original 4.3 doesn't run on MicroVAXen, so if you had 4.3 on yours, it must have been *some* enhanced version. MS

22 years, 7 months

1
0
0 0

Re: [pups] 2.11BSD images for Simh

by Andru Luvisi

>From Warren: > > These file are now in the Unix Archive on minnie.tuhs.org in > PDP-11/Boot_Images/2.11_on_Simh > > The mirror sites should pick them up soon. >

22 years, 7 months

1
0
0 0

Re: non-broken 4.3BSD set?

by Robertdkeys＠aol.com

The src tarball in the archives is only 35k or something like that, so it is mostly gone. At one time, I thought it was more there. Since I was only needing the dwb section out of the sources, to power up a dwb suite on an ancient ultrix box, I just used the quasijarus 0a source tarball (that is supposed to be Tahoe) for the bits I needed. It worked. But, for the record, it might be nice to have a complete, unbroken set, if it still exists, and the bits can be rounded up. Out of curiosity, anyone still running a 4.3BSD box? I had a couple microVAXes up with it until my ESDI drives went bellyup a few days back. (Ice storms and power glitches ate the drives.) I have maybe 30mb of ports of this and that (gzip, gmake, psroff, TeX, and other things) that I would donate to the archives if there was any interest. MicroVAXen are a cheap way of playing old BSD....(:+}}... Thanks Bob

22 years, 7 months

1
0
0 0

RE: [pups] Boot_Images and the networking activated version of Simh

by Fred N. van Kempen

Warren, Oh, I see Andru already uploaded it to Minnie as well.. OK.. Thanks, Andru! --fred > -----Original Message----- > From: Warren Toomey [mailto:wkt@minnie.tuhs.org] > Sent: Saturday, December 07, 2002 6:08 AM > To: Andru Luvisi > Cc: pups(a)minnie.tuhs.org > Subject: Re: [pups] Boot_Images and the networking activated > version of > Simh > > > In article by Andru Luvisi: > > All righty. I have: > > A working boot image for a networked 2.11BSD system inside simh. > > Some perl scripts for working with simh tape images. > > simh startup script for booting the networked image. > > simh startup script for booting from the install tape. > > Some basic instructions for how to get the thing going > (not a substitute > > for reading the simh docs and knowing something about UNIX). > > > > I emailed Warren but he seems to be unavailable right now. > > > > So, who's got an archive I can upload it to? > > Try anonymous ftp to minnie.tuhs.org, directory incoming/unix. > > Sorry, I've been busy! > Warren > _______________________________________________ > PUPS mailing list > PUPS(a)minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/pups >

22 years, 7 months

1
0
0 0

raise of interrupt level necessary

by Wolfgang Helbig

Hi, While studying the V6 kernel, I search for some rules as when to raise the interrupt priority level (IPL). I came up with something like this: A kernel process needs to raise the IPL if a change of data must be atomic and might be accessed (not necessarily changed) by an IRS. In light of this rule, some raising of interrupts seem unnecessary: - In m40.s changes of the user space segmentation registers are bracketed by raising and lowering the IPL, although these registers are never accessed by an ISR. - Likewise, in m40.s, just before the trap routine checks the runrun flag and restores r0, r1 and the user stackpointer, it raises the IPL. I can't see what possibly should go wrong, if being interrupted while restoring the values. I'd appreciate any help from someone with more experience in kernel programming. Greetings, Wolfgang Helbig

22 years, 7 months

1
0
0 0

RE: [pups] Boot_Images and the networking activated version of Simh

by Fred N. van Kempen

People, DO note that the Ethernet operations of SimH heavily depend on the proper workings AND configuration of a Packet Filter driver for your platform, so, something like BPF, EFILT, NetFLT or WinPCAP (for Win32). Try running a test app for that stuff BEFORE trying to run SimH/ENET stuff.. if the test app works OK, you can start figuring out why SimH/ENET doesn't work on your system. I have *three* network cards the drivers of which DO NOT support promisc mode. Which obviously results in WinPCAP (they're PCI cards under Win2K) not functioning properly, and, thus, same for SimH/ENET. --fred > -----Original Message----- > From: Andru Luvisi [mailto:luvisi@andru.sonoma.edu] > Sent: Friday, November 29, 2002 8:02 AM > To: gregg(a)levine.name > Cc: pups(a)minnie.tuhs.org > Subject: Re: [pups] Boot_Images and the networking activated > version of > Simh > > > On Thu, 28 Nov 2002, Gregg C Levine wrote: > > Hello from Gregg C Levine > > Just out of curiosity, can the boot images stored in the > folders that > > are under that name, actually support this new version of > Simh? That is > > the PDP-11 emulator. What would be necessary to enable that > function? It > > looks as if one of them, is aware of the device, since I believe the > > image was made on a machine which has the appropriate card > installed in > > it, but after that I'm lost. > > I would be happy to share mine, but it doesn't work. ;-) > > The thing that strikes me as really weird is that I know a guy who is > running VMS with networking on the simh VAX emulator. As I > understand it, > the the VAX and PDP-11 emulators use the same code for the ethernet > controller. > > Andru > -- > Andru Luvisi, Programmer/Analyst > > Quote Of The Moment: > Truth is hard to find and harder to obscure. > > _______________________________________________ > PUPS mailing list > PUPS(a)minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/pups >

22 years, 7 months

3
3
0 0

Re: [pups] 2.11BSD networking on simh

by Steven M. Schultz

Hi - > From: Andru Luvisi <luvisi(a)andru.sonoma.edu> > I have gotten 2.11 installed on simh, I have it recognizing the simulated > ethernet card, and everything appears correct except the packets just > aren't getting in and out. The simh documentation says that the DELQA > card is better than the DEQNA, but I was unable to get the DELQA (qt) > driver to recognize the card. When I compiled the kernel to use the DEQNA There are TWO variants of the DELQA as I recall. One was referred to as the "turbo" verion (I think it was called the DELQA-YM) and the if_qt driver was developed and tested specifically for, and only for, that variant. The normal DELQA and DEQNA should use the if_qe driver. > I have configured 2.11BSD with: > A valid IP address on the network the host is on. > The same netmask, broadcast, and gateway as the host. > I am running the emulator as root. > > The docs say you won't be able to talk between the host and the emulated Hmmm, that seems strange. Using P11 I talk between the host (the machine running the emulator program) and the "PDP11" all the time. Ah, it has to do with ARP handling I suspect. I know that with P11 it's IP only and thus ARP packets do not traverse the emulated ethernet card. If that is the case with simh as well then on the PDP11 side you might have to do what I did and install arp entries for everything on the local lan with which the PDP11 is going to communicate. That way the 11 already knows the 'mac' address and does not need ARP (which doesn't work thru the emulated ethernet) at all. > machine, so my test for each configuration has been pinging the gateway, > which I know responds to pings since I can ping it from the host. Ah, but on the host did you publish an ARP entry so that the host will arp for the PDP11? I think that is required. I would tinker around with installing published/proxy arp entries and seeing what happens. Cheers, Steven Schultz sms(a)2bsd.com

22 years, 7 months

2
2
0 0

[pups] Boot_Images and the networking activated version of Simh

by Gregg C Levine

Hello from Gregg C Levine Just out of curiosity, can the boot images stored in the folders that are under that name, actually support this new version of Simh? That is the PDP-11 emulator. What would be necessary to enable that function? It looks as if one of them, is aware of the device, since I believe the image was made on a machine which has the appropriate card installed in it, but after that I'm lost. ------------------- Gregg C Levine hansolofalcon(a)worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda )

22 years, 7 months

2
1
0 0

[pups] 2.11BSD networking on simh

by Andru Luvisi

I have gotten 2.11 installed on simh, I have it recognizing the simulated ethernet card, and everything appears correct except the packets just aren't getting in and out. The simh documentation says that the DELQA card is better than the DEQNA, but I was unable to get the DELQA (qt) driver to recognize the card. When I compiled the kernel to use the DEQNA (qe) driver and set the card up in DEQNA mode, the emulated card and its ethernet address were correctly detected. I have configured 2.11BSD with: A valid IP address on the network the host is on. The same netmask, broadcast, and gateway as the host. I am running the emulator as root. I have attached the DEQNA to the appropriate ethernet card. I can see the ethernet card go into promiscuous mode when I start the emulator. I have tested it with SANITY=ON and SANITY=OFF. The docs say you won't be able to talk between the host and the emulated machine, so my test for each configuration has been pinging the gateway, which I know responds to pings since I can ping it from the host. I have been over both the 2.11BSD docs and the simh docs several times and as far as I can tell I am doing everything correctly. I would appreciate any hints that any of you can offer. Thanks, Andru Quote Of The Moment: Appel's method avoids making a large number of small trampoline bounces by occasionally jumping off the Empire State Building. -- Henry G. Baker, "Cheney on the M.T.A."

22 years, 7 months

2
3
0 0

Re: [pups] Looking for binary distribution of v7

by Mario Premke

Thanks a lot - it works ... I am delighted !!! ---------- > Von: Frank Wortner <frank(a)wortner.com> > An: Mario Premke <Mario.Premke(a)epost.de>; pups(a)minnie.tuhs.org > Betreff: Re: [pups] Looking for binary distribution of v7 > Datum: Montag, 18. November 2002 03:59 > > on 11/17/02 1:24 PM, Mario Premke at Mario.Premke(a)epost.de wrote: > > > Nevertheless, mounting the file and boot dl0: leads to the boot-prompt @ > > After typing unix the boot-prompt appears again - does the kernel have a > > different name ? > > boot dl0 > @boot <- you type "boot" and press "enter" or "return" in reply > New Boot, known device are hp ht rk rl rp tm vt > : rl(0,0)rl2unix <- you type "rl(0,0)rl2unix" and press return > mem = 177856 > # <- you are now in "single user" mode > <- press "control-d" to go to multiuser mode > <- (the normal mode of operation) > Restricted rights: Use, duplication, or disclosure > is subject to restrictions stated in your contract with > Western Electric Company, Inc. > Thu Sept 22 06:26:09 EDT 1988 > > login: root <- login as "root" > # <- Have fun ... > <- You did make a backup of the disk image before you started, > <- right? ;-) > > If you want to make things easier, your first command should be: > > # cp /rl2unix /unix > > Now you will be able to type "rl(0,0)unix" instead of "rl(0,0)rl2unix". Ps > and other commands that need to read the system namelist also expect the > kernel image to be named /unix. > > Enjoy! > > > > -- > Frank > > "Plez cnoke if an rnsr is not reqid." > Sign on Owl's Door, "Winnie the Pooh" > > > _______________________________________________ > PUPS mailing list > PUPS(a)minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/pups

22 years, 7 months

1
0
0 0

Re: [pups] Looking for binary distribution of v7

by Frank Wortner

on 11/17/02 1:24 PM, Mario Premke at Mario.Premke(a)epost.de wrote: > Nevertheless, mounting the file and boot dl0: leads to the boot-prompt @ > After typing unix the boot-prompt appears again - does the kernel have a > different name ? boot dl0 @boot <- you type "boot" and press "enter" or "return" in reply New Boot, known device are hp ht rk rl rp tm vt : rl(0,0)rl2unix <- you type "rl(0,0)rl2unix" and press return mem = 177856 # <- you are now in "single user" mode <- press "control-d" to go to multiuser mode <- (the normal mode of operation) Restricted rights: Use, duplication, or disclosure is subject to restrictions stated in your contract with Western Electric Company, Inc. Thu Sept 22 06:26:09 EDT 1988 login: root <- login as "root" # <- Have fun ... <- You did make a backup of the disk image before you started, <- right? ;-) If you want to make things easier, your first command should be: # cp /rl2unix /unix Now you will be able to type "rl(0,0)unix" instead of "rl(0,0)rl2unix". Ps and other commands that need to read the system namelist also expect the kernel image to be named /unix. Enjoy! -- Frank "Plez cnoke if an rnsr is not reqid." Sign on Owl's Door, "Winnie the Pooh"

22 years, 7 months

1
0
0 0

Re: [pups] Looking for binary distribution of v7

by pete＠dunnington.u-net.com

On Nov 17, 21:09, M E Leypold wrote: > > Mario Premke writes: > > Nevertheless, mounting the file and boot dl0: leads to the boot-prompt @ > > After typing unix the boot-prompt appears again - does the kernel have a > > different name ? > > Thanks in advance > > Mario Premke > > rlunix? It should look something like this (from my 7th Editon on a real PDP-11): @boot boot : rl(0,0)unix The "@" is the bootstrap prompt, and the first "boot" is what you type. The second "boot" is from the boot program itself; the colon ":" is boot's prompt. "rl(0,0)" is what you type to name the device, unit, and partition, and "unix" is the kernel name. YMMV if you have a different kernel. BTW, to shut down an old system like this, you should (as root) type # kill -1 1 to stop user processes and return to single-user mode; then type "sync" a couple of times, to make sure any disk buffers are written out, and then stop the processor. -- Pete Peter Turnbull Network Manager University of York

22 years, 7 months

1
0
0 0

Re: [pups] Looking for binary distribution of v7

by M E Leypold ＠ labnet

Mario Premke writes: > Thanks a lot !!! > That was what I was looking for ... > Nevertheless, mounting the file and boot dl0: leads to the boot-prompt @ > After typing unix the boot-prompt appears again - does the kernel have a > different name ? > Thanks in advance > Mario Premke rlunix? Regards -- Markus

22 years, 7 months

1
0
0 0

Re: [pups] Looking for binary distribution of v7

by Mario Premke

Thanks a lot !!! That was what I was looking for ... Nevertheless, mounting the file and boot dl0: leads to the boot-prompt @ After typing unix the boot-prompt appears again - does the kernel have a different name ? Thanks in advance Mario Premke ---------- > Von: Bill Gunshannon <bill(a)cs.scranton.edu> > An: Mario Premke <Mario.Premke(a)epost.de> > Cc: Gregg C Levine <hansolofalcon(a)worldnet.att.net>; pups(a)minnie.tuhs.org > Betreff: Re: [pups] Looking for binary distribution of v7 > Datum: Samstag, 16. November 2002 23:34 > > On Sat, 16 Nov 2002, Mario Premke wrote: > > > Hello Gregg, thanks for your immediate response ! > > I recently found the article 'Booting 7th Edition UNIX Images' on the > > 'vmsnet.pdp-11'-Newsgroups: > > > > <--- SNIP ---> > > > > ftp://ftp.digital.com/pub/DEC/sim/sources/ > > ftp://minnie.cs.adfa.oz.au/pub/PDP-11-sims/Supnik_2.2d/sources/ > > > > Try http://simh.trailing-edge.com > > bill > > -- > Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves > bill(a)cs.scranton.edu | and a sheep voting on what's for dinner. > University of Scranton | > Scranton, Pennsylvania | #include <std.disclaimer.h>

22 years, 7 months

1
0
0 0

Re: [pups] Looking for binary distribution of v7

by Bill Gunshannon

On Sat, 16 Nov 2002, Mario Premke wrote: > Hello Gregg, thanks for your immediate response ! > I recently found the article 'Booting 7th Edition UNIX Images' on the > 'vmsnet.pdp-11'-Newsgroups: > > <--- SNIP ---> > > ftp://ftp.digital.com/pub/DEC/sim/sources/ > ftp://minnie.cs.adfa.oz.au/pub/PDP-11-sims/Supnik_2.2d/sources/ > Try http://simh.trailing-edge.com bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill(a)cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include <std.disclaimer.h>

22 years, 7 months

2
1
0 0

Re: [pups] Looking for binary distribution of v7

by Mario Premke

Hello Gregg, thanks for your immediate response ! I recently found the article 'Booting 7th Edition UNIX Images' on the 'vmsnet.pdp-11'-Newsgroups: <--- SNIP ---> ftp://ftp.digital.com/pub/DEC/sim/sources/ ftp://minnie.cs.adfa.oz.au/pub/PDP-11-sims/Supnik_2.2d/sources/ Once you get it, you have to compile the simulator. You also need to fetch the 7th Edition UNIX disk images as well; they are available from the above ftp sites in the software directory (i.e replace sources with software. Unpack the 7th Edition tarball in the same directory as the one you built the simulator. The only file you require is disks/unix_v7_rl.dsk <--- SNIP ---> What I wanted to say is that the above ftp-links are dead. You are right, I should look for the compressed tarball, but I don't know how the tarball is called and looking for 'unix_v7_rl.dsk' on google only leads to other dead links ... Any hints ? Mario Premke ---------- > Von: Gregg C Levine <hansolofalcon(a)worldnet.att.net> > An: pups(a)minnie.tuhs.org > Betreff: RE: [pups] Looking for binary distribution of v7 > Datum: Samstag, 16. November 2002 14:50 > > Hello from Gregg C Levine > How do you mean by that? " The links pointing to the 'unix_v7_rl.dsk' > image I found are dead ... :-(" You said. How so? As I recall, that file > that's in there, for unix_v7_rl.dsk" is there, it's a totally different > UNIX_v7 file name, you need to call it that for the E11 product. For > SIMH, the full name as rendered by the extraction process from the > compressed file works. > ------------------- > Gregg C Levine hansolofalcon(a)worldnet.att.net > ------------------------------------------------------------ > "The Force will be with you...Always." Obi-Wan Kenobi > "Use the Force, Luke." Obi-Wan Kenobi > (This company dedicates this E-Mail to General Obi-Wan Kenobi ) > (This company dedicates this E-Mail to Master Yoda ) > > > > > -----Original Message----- > > From: pups-admin(a)minnie.tuhs.org [mailto:pups-admin@minnie.tuhs.org] > On > > Behalf Of Mario Premke > > Sent: Saturday, November 16, 2002 8:25 AM > > To: pups(a)minnie.tuhs.org > > Subject: [pups] Looking for binary distribution of v7 > > > > Hello, > > I just read the instructions of how to boot a binary version 7 disk > image > > on a ersatz11 pdp11 emulator. > > The links pointing to the 'unix_v7_rl.dsk' image I found are dead ... > :-( > > Are there any other sites where I can download this binary > distribution ?? > > > > BTW their are disk dumps of version 7 in the Caldera ancient unix > archive > > .. is it possible to boot > > them on ersatz11 as well ? I tried it a few times without success ... > > I simply tried it with the following e11.ini (from a newsgroup > discussion), > > because I heavily lack > > PDP 11 hardware knowledge. Nevertheless trying this ini-file and many > > variations I made of it all > > end up in a blank emulator screen ... > > > > Any ideas will be appreciated > > > > Mario Premke > > > > ; Set up some terminal devices > > assign tt0: f1 > > assign tt1: f2 > > set scroll hard > > ; Make the CPU like an 11/45 > > set cpu dspace > > set cpu dualregset > > set cpu mmtraps > > set cpu pirq > > set cpu spl > > set cpu supmode > > set cpu cpuerr > > set cpu csm > > set cpu tstset > > ; Get rid of unneeded device > delays > > set delay dl11 0=0 1=0 > > set delay rl11 0=0 1=0 2=0 3=0 4=0 5=0 6=0 7=0 > > ; Mount the RL02 disk image > > mount dl0: v7_rl.dsk > > ; and boot > > boot dl0: > > > > > > _______________________________________________ > > PUPS mailing list > > PUPS(a)minnie.tuhs.org > > http://minnie.tuhs.org/mailman/listinfo/pups > > _______________________________________________ > PUPS mailing list > PUPS(a)minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/pups

22 years, 7 months

1
0
0 0

RE: [pups] Looking for binary distribution of v7

by Gregg C Levine

Hello from Gregg C Levine How do you mean by that? " The links pointing to the 'unix_v7_rl.dsk' image I found are dead ... :-(" You said. How so? As I recall, that file that's in there, for unix_v7_rl.dsk" is there, it's a totally different UNIX_v7 file name, you need to call it that for the E11 product. For SIMH, the full name as rendered by the extraction process from the compressed file works. ------------------- Gregg C Levine hansolofalcon(a)worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda ) > -----Original Message----- > From: pups-admin(a)minnie.tuhs.org [mailto:pups-admin@minnie.tuhs.org] On > Behalf Of Mario Premke > Sent: Saturday, November 16, 2002 8:25 AM > To: pups(a)minnie.tuhs.org > Subject: [pups] Looking for binary distribution of v7 > > Hello, > I just read the instructions of how to boot a binary version 7 disk image > on a ersatz11 pdp11 emulator. > The links pointing to the 'unix_v7_rl.dsk' image I found are dead ... :-( > Are there any other sites where I can download this binary distribution ?? > > BTW their are disk dumps of version 7 in the Caldera ancient unix archive > .. is it possible to boot > them on ersatz11 as well ? I tried it a few times without success ... > I simply tried it with the following e11.ini (from a newsgroup discussion), > because I heavily lack > PDP 11 hardware knowledge. Nevertheless trying this ini-file and many > variations I made of it all > end up in a blank emulator screen ... > > Any ideas will be appreciated > > Mario Premke > > ; Set up some terminal devices > assign tt0: f1 > assign tt1: f2 > set scroll hard > ; Make the CPU like an 11/45 > set cpu dspace > set cpu dualregset > set cpu mmtraps > set cpu pirq > set cpu spl > set cpu supmode > set cpu cpuerr > set cpu csm > set cpu tstset > ; Get rid of unneeded device delays > set delay dl11 0=0 1=0 > set delay rl11 0=0 1=0 2=0 3=0 4=0 5=0 6=0 7=0 > ; Mount the RL02 disk image > mount dl0: v7_rl.dsk > ; and boot > boot dl0: > > > _______________________________________________ > PUPS mailing list > PUPS(a)minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/pups

22 years, 7 months

1
0
0 0

[pups] Looking for binary distribution of v7

by Mario Premke

Hello, I just read the instructions of how to boot a binary version 7 disk image on a ersatz11 pdp11 emulator. The links pointing to the 'unix_v7_rl.dsk' image I found are dead ... :-( Are there any other sites where I can download this binary distribution ?? BTW their are disk dumps of version 7 in the Caldera ancient unix archive .. is it possible to boot them on ersatz11 as well ? I tried it a few times without success ... I simply tried it with the following e11.ini (from a newsgroup discussion), because I heavily lack PDP 11 hardware knowledge. Nevertheless trying this ini-file and many variations I made of it all end up in a blank emulator screen ... Any ideas will be appreciated Mario Premke ; Set up some terminal devices assign tt0: f1 assign tt1: f2 set scroll hard ; Make the CPU like an 11/45 set cpu dspace set cpu dualregset set cpu mmtraps set cpu pirq set cpu spl set cpu supmode set cpu cpuerr set cpu csm set cpu tstset ; Get rid of unneeded device delays set delay dl11 0=0 1=0 set delay rl11 0=0 1=0 2=0 3=0 4=0 5=0 6=0 7=0 ; Mount the RL02 disk image mount dl0: v7_rl.dsk ; and boot boot dl0:

22 years, 7 months

1
0
0 0

[pups] Looking for binary distribution of v7

by Mario Premke

Hello, I just read the instructions of how to boot a binary version 7 disk image on a ersatz11 pdp11 emulator. The links pointing to the 'unix_v7_rl.dsk' image I found are dead ... :-( Are there any other sites where I can download this binary distribution ?? BTW their are disk dumps of version 7 in the Caldera ancient unix archive . is it possible to boot them on ersatz11 as well ? I tried it a few times without success ... I simply tried it with the following e11.ini (from a newsgroup discussion), because I heavily lack PDP 11 hardware knowledge. Nevertheless trying this ini-file and many variations I made of it all end up in a blank emulator screen ... Any ideas will be appreciated Mario Premke (Please, send a return mail to my E-Mail address, since I am not on the list ..) ; Set up some terminal devices assign tt0: f1 assign tt1: f2 set scroll hard ; Make the CPU like an 11/45 set cpu dspace set cpu dualregset set cpu mmtraps set cpu pirq set cpu spl set cpu supmode set cpu cpuerr set cpu csm set cpu tstset ; Get rid of unneeded device delays set delay dl11 0=0 1=0 set delay rl11 0=0 1=0 2=0 3=0 4=0 5=0 6=0 7=0 ; Mount the RL02 disk image mount dl0: v7_rl.dsk ; and boot boot dl0:

22 years, 7 months

1
0
0 0

RE: [TUHS] port of old unices to i386?

by Ian King

I recall a thread about this only a few months ago. Check out the TUHS mail archive - I seem to recall that someone had ported V7 to the x86 architecture. Me, I have a PDP-11/34 in my basement.... -- Ian ________________________________ From: Jesper Jacobsson [mailto:jesperjacobsson@yahoo.se] Sent: Sat 11/9/2002 2:18 PM To: tuhs(a)minnie.tuhs.org Subject: [TUHS] port of old unices to i386? Hi there. I am a linux-user and I came across TUHS for the first time today actually when I was searching google for old unices. I love linux and am very interested in the history of unix. For some time I have wanted to try out some early versions of unix as I am in my early 20's and was born too late to have been around those days :( I havn't found any people to ask about this till today :) Anyway, I browsed the filearchive and I guess the distributions there surely won't work on my computer. Is there a way to get them work on a i386 computer? Have someone made any ports of an early unix system to i386 out of nostalgia? If not, could someone take it on as a hobbyproject so that new generations of unix-like-OS-users can explore it? It would be both fun and also very educational to play around with I am sure. I hope this email gets through and that I didn't annoy you guys. I have not signed up for this list I just emailed tuhs(a)minnie.tuhs.org directly and hoped it would get through :) Please send replies to jesperjacobsson(a)yahoo.se Answers would be very appriciated! Thanks in advance, Jesper ===== _____________________________________________________ Gratis e-mail resten av livet på www.yahoo.se/mail Busenkelt! _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/tuhs

22 years, 8 months

4
3
0 0

port of old unices to i386?

by Jesper Jacobsson

Hi there. I am a linux-user and I came across TUHS for the first time today actually when I was searching google for old unices. I love linux and am very interested in the history of unix. For some time I have wanted to try out some early versions of unix as I am in my early 20's and was born too late to have been around those days :( I havn't found any people to ask about this till today :) Anyway, I browsed the filearchive and I guess the distributions there surely won't work on my computer. Is there a way to get them work on a i386 computer? Have someone made any ports of an early unix system to i386 out of nostalgia? If not, could someone take it on as a hobbyproject so that new generations of unix-like-OS-users can explore it? It would be both fun and also very educational to play around with I am sure. I hope this email gets through and that I didn't annoy you guys. I have not signed up for this list I just emailed tuhs(a)minnie.tuhs.org directly and hoped it would get through :) Please send replies to jesperjacobsson(a)yahoo.se Answers would be very appriciated! Thanks in advance, Jesper ===== _____________________________________________________ Gratis e-mail resten av livet på www.yahoo.se/mail Busenkelt!

22 years, 8 months

3
2
0 0

Re: [pups] 2.9BSD and Simh

by helbig＠informatik.ba-stuttgart.de

Hi Mitch, you'll find the program enblock.c at http://www.ba-stuttgart.de/~helbig/os/v6/ that I wrote to prepare the v6 distribution tape for SIMH. With v7, you need to apply different block sizes like (f0, f1, ... f6 from Keith Bostic): enblock <f0 >dist.tap enblock <f1 >>dist.tap ... enblock <f4 >>dist.tap enblock 10240 <f5 >>dist.tap enblock 10240 <f6 >>dist.tap enblock </dev/null >>dist.tap Enblock puts an EOF tapemark at the end. The last invocation puts an EOT mark. Have fun, Wolfgang

22 years, 8 months

1
0
0 0

[pups] 1978 Tynix? (fwd)

by Warren Toomey

----- Forwarded message from Jorn Barger ----- From: jorn(a)enteract.com (Jorn Barger) Date: Tue, 5 Nov 2002 04:09:15 -0700 I'm not a PUPS subscriber, but I've been browsing the archives and I wonder if you know anything about this? In an old Byte (Jan 1981, p200) Sol Libes wrote: > "UNIX-Like Operating Systems Increasing In Popularity: > Several software suppliers are now offering UNIX-like > operating systems that may rival CP/M. The first > UNIX-like software package, called TYNIX, was released > for LSI-11 and Heath H-11 systems in 1978 by the > Boston Children's Museum..." My guess is that this was Heinz Lycklama's unreleasable LSI-Unix (LSX), and I've written him to enquire, but haven't heard back yet. [ you're probably right, but I'd assume that it was a binary-only release - Warren ] I'm working on a detailed timeline of Linux prehistory, so I'm also following your Xenix explorations. I'd really like to know who did the first x86 Xenix, HCR or MS? [ I thought it was HCR too, but I could be wrong - Warren ] ----- End of forwarded message from Jorn Barger -----

22 years, 8 months

3
3
0 0

[pups] 2.9BSD and Simh

by mitch wright

Hi Folks, Does anyone know how to build a full distribution tape in Simh format? Or am I over looking something simple? I can boot and run the root RL02 image but would like install the full system. Would like to do the same for the 4.3 and the VAX Simh. Thanks, Mitch

22 years, 8 months

1
0
0 0

Re: [TUHS] license

by msokolov＠ivan.Harhan.ORG

"Greg 'groggy' Lehey" <grog(a)lemis.com> wrote: > I'll leave it to others to describe the early days. The Berkeley > Software License Agreement, generally called the BSD license, is > pretty straightforward, though. Wrong. The Berkeley Software License Agreement and what is known today as the "BSD license" are two different things. The latter is the liberal header Berkeley started prepending around 1988 to files that were totally theirs without any Bell Labs code. The former was the paper license that went with the 4.3BSD and earlier tapes where Bell, Bell/Berkeley, and pure Berkeley parts were not distinguished and the entire system could be used only by holders of UNIX source licenses from AT&T. Although I've never seen it myself, the Berkeley Software License Agreement could not have been like the liberal header, it surely had stuff in it telling you that if you share it with anyone, you must first verify that the recipient has a UNIX source license from AT&T, etc. MS

22 years, 8 months

1
0
0 0

Re: [TUHS] license

by msokolov＠ivan.Harhan.ORG

Marco Robado <mar.roba(a)videotron.ca> wrote: > I would like > to give examples of a license on which the source of a software was > delivered in the 70's. I have the paper license for System V issued by AT&T to Case Western Reserve University, the famous UNIX source license. I have it buried somewhere in my papers. If you want it, I can dig it up and fax or snail-mail you a copy. (Sorry, no scanning. I use the computing technology from the days in question exclusively.) > For BSD I found in the > source of 2.11BSD a reference to "The Berkeley software license > Agreement" Yep, same for 4BSD. > but I don't have a copy of that document. I don't either. MS

22 years, 8 months

1
0
0 0

license

by Marco Robado

Hi, I am curently writing an article about the history of open source. I know all you can find on the Internet about the history of unix and BSD and the conflict between these two when BSD decided to opensource. But I could never find a copy of both licenses in the early days. I would like to give examples of a license on which the source of a software was delivered in the 70's. I browsed thru the sources of unix v5 and the only copyright I found was in the code of the c compiler and it just stated that it was copyrighted by Bell labs in 1972. I would think that there was some kind of hard copy copyright that came with the tape on wich the sources were originaly delivered. For BSD I found in the source of 2.11BSD a reference to "The Berkeley software license Agreement" but I don't have a copy of that document. I would appreciate if someone would communicate with me by e-mail or thru this list to give me some info about all that. -M.R.-

22 years, 8 months

2
1
0 0

[pups] this list

by Richard Snow

This was for older PDP's like the 11, wasn't it? I have a Vaxstation 3100. I do have the SIMH PHP simulator running which can simulate an 11, but I haven't done anything with it. Richard.

22 years, 8 months

2
1
0 0

Try Our New Demos

by Quality Computer Training

You can now view the latest demos of our quality, fully-interactive computer training products. Try our product for Free. Microsoft Office, A+, i-Net+, MCP & hundreds more. http://www.aarons-computer-training.com/demo_downloads.htm Call us for an additional 10% off any order with this email. Computer Training for Your Future - Success Guaranteed

22 years, 8 months

1
0
0 0

re: C reference manual

by Dennis Ritchie

The original question (from Ian KIng) was > I'm looking for a copy of the C reference manual from some time between > the 6th Edition (1975) and the first version that came with 4.3BSD > (1986). Some offered pointers to the 6th edition version (which is around both at TUHS and also on my own home page.) Norman observed that the standard V7 tapes omitted the C manual from the documentation set, because of the publication of K&R 1. However, it turns out that in our own paper-published version of the 7th edition, the then-current spec (very nearly what became Appendix A of K&R 1) was indeed printed. Probably some of these manuals were distributed to people who got the tapes at that point. The printed 7th edition also included a 1-page "Recent Pages to C" addendum, describing the enum type, and also confirming that structure assignment plus passing and receiving structures to functions (promised for the future in K&R 1) were available. At some point there may have been an updated version of this--I don't have it--confirming that the compiler now, indeed, treated same-named members of different structures as distinct and non-interfering. I retyped this addendum, and it's now on my home page. More lately, Aharon pointed out that SCO had offered a (for-fee) fairly complete distribution of System III under an Ancient Unix license, and was kind enough to send it to me. It includes (under the name c_man) a version that looks to be just about the same as the version with the internal 7th edition. This also includes the "Recent Changes" as an addendum. (Amusingly, the enum example switches a color in its example: "winedark" to "puce". I don't know who did this; it could have been me!). Another interesting complication I turned up in investigating this is that Brian and I seem to have lost the machine-readable source for the actual Appendix A of K&R 1! (The rest of the text is still around). But to turn back to the original question: aside from the "Recent Changes" page, and perhaps some tweaking of the table of supported machines and perhaps a few other fairly minor things, there wasn't any significantly differing local C Reference Manual between 7th ed / K&R 1, up to the ANSI 1989 standard. However, I should try to retrieve what went into 4.3BSD-- I don't have a complete copy of it. Dennis

22 years, 8 months

1
0
0 0

re: Can someone advise me regarding a gui for UNIX

by Dennis Ritchie

Norman Wilson recalled > 22. Pike, R. "The Blit: A Multiplexed Graphics Terminal". _AT&T Bell > Laboratories Technical Journal 63_, 8 (Oct. 1984). > Rob described an earlier version of the Blit work in a USENIX talk > at USENIX in January 1982 (Santa Monica CA). So far as I know it > was just a talk, no paper, though he showed a canned demo on video > tape. By coincidence, one of the two videos made about early Blit work is newly available in .mpg format: look near the bottom of Rob Pike's page under Movies: http://www.cs.bell-labs.com/who/rob/index.html This was just now done by Gerard Holzmann. Be aware that it is 43MB in size. This version is spoken by actors, although the script is Rob's. The other Blit video is in Betacam format, and we don't currently have a player for it, so it's not digitized. I think it's silent, and presumably Rob talked during its showing. This might be what accompanied the Usenix talk. (By the way, there are two other, twice-as large videos there: the Labscam tape, and Rob's appearance on the David Letterman TV show with Penn and Teller.) Dennis

22 years, 8 months

3
2
0 0

Re: [TUHS] C reference manual

by Aharon Robbins

If anyone has one of the SCO Ancient Unix licenses and a copy of the archive that went with it, then they legally have the source to System III. If such a person extracts sys3.tar.gz and looks in usr/src/man/docs they'll find a file named `c_man' with the actual manual in it. I quote: ... .SH "1. INTRODUCTION" .PP This manual .FS .ps +1 \(dg This manual is reprinted, with minor changes, from .I "The C Programming Language" by Brian W. Kernighan and Dennis M. Ritchie, Prentice Hall, Inc., 1978. .ps .FE describes the C language ... What the legalities are of redistributing this, and/or generating postscript from it, are, I don't know. Similar questions apply to scanning in the ref man from a copy of K&R-I, which is now out of print. (I wish Caldera had included System III in their releasing of Ancient Unix. Sigh.) I hope this helps, some. Arnold P.S. Completely unrelated, but I find it really cool how much of the System III doc refers to C and Unix on the System/370... > Subject: Re: [TUHS] C reference manual > From: norman(a)nose.cs.utoronto.ca (Norman Wilson) > To: tuhs(a)minnie.tuhs.org > Date: Thu, 17 Oct 2002 09:13:22 -0400 > > To forestall those who haven't looked: the good news is that > the papers from Volume 2 of the manual were included in /usr/doc > on the V7 tape; the bad news is that the C Reference Manual was > omitted. Here is /usr/doc/cman in its entirety: > > Sorry, but for copyright reasons, the source > for the C Reference Manual is not distributed. > > Presumably the problem was that the Reference Manual was published > as part of the a real book in 1978. > > I forget just what Tony was after in the first place, but maybe > some of the stuff on Dennis Ritchie's home page will help: > http://www.cs.bell-labs.com/who/dmr/index.html > In particular the Sixth Edtion version of the C Reference Manual > is there. > > Norman Wilson > Toronto ON

22 years, 8 months

2
1
0 0

[pups] Minnie mail down over the weekend

by Warren Toomey

The machine which hosts this mailing list is scheduled to be down over the Australian weekend due to power problems. It should be up on Monday morning Australian time. Warren

22 years, 8 months

1
0
0 0

Re: [TUHS] C reference manual

by norman＠nose.cs.utoronto.ca

To forestall those who haven't looked: the good news is that the papers from Volume 2 of the manual were included in /usr/doc on the V7 tape; the bad news is that the C Reference Manual was omitted. Here is /usr/doc/cman in its entirety: Sorry, but for copyright reasons, the source for the C Reference Manual is not distributed. Presumably the problem was that the Reference Manual was published as part of the a real book in 1978. I forget just what Tony was after in the first place, but maybe some of the stuff on Dennis Ritchie's home page will help: http://www.cs.bell-labs.com/who/dmr/index.html In particular the Sixth Edtion version of the C Reference Manual is there. Norman Wilson Toronto ON

22 years, 8 months

1
0
0 0

Re: [TUHS] C reference manual

by Ian King

I have an original (in print) of the C reference manual from Unix 6th Ed, as part of a multipart binder titled "Documents for Use With the Unix Timesharing System", as well as the "UNIX Programmer's Manual", which is a print copy of the man pages. I could probably scan the C ref in my copious spare time, if you're not in a hurry. Warren, do you want to archive stuff like this? -- Ian -----Original Message----- From: Tony Finch [mailto:dot@dotat.at] Sent: Wednesday, October 16, 2002 1:10 PM To: tuhs(a)minnie.tuhs.org Cc: dot(a)dotat.at Subject: [TUHS] C reference manual I'm looking for a copy of the C reference manual from some time between the 6th Edition (1975) and the first version that came with 4.3BSD (1986). The stuff in the TUHS archive mostly seems to be missing the documentation sets, or in the case of the earlier BSDs they are ommitted for copyright reasons. There are some tutorials dating from about 1979 but they aren't much use. Any help would be appreciated. Tony. -- f.a.n.finch <dot(a)dotat.at> http://dotat.at/ DOGGER: NORTHEAST 6 TO GALE 8 BACKING NORTHWEST 4 OR 5. RAIN OR SHOWERS. MODERATE OR GOOD. _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/tuhs

22 years, 8 months

2
1
0 0

Re: [TUHS] C reference manual

by helbig＠informatik.ba-stuttgart.de

Hallo, Most, if not all, of the V6-docs was distributed with V6 as troff sources. At http://www.ba-stuttgart.de/~helbig/os/ you'll find postscript versions of these docs. Have fun, Wolfgang

22 years, 8 months

2
1
0 0

Re: Weinberger stencil? (was: rtm)

by norman＠nose.cs.utoronto.ca

This is certainly non-technical UNIX history, which is not to say it isn't interesting. I can sharpen up a few details of Dennis's account. Peter was already a department head when I first visited the Labs in early 1984. I believe his face was already a favourite test image for various graphics experts, but the cult of the face didn't really get started until the following year. In particular I think it was in the summer of 1985 that Tom Duff thought of the deathstar transform (turning a picture into variable- width horizontal stripes, as the AT&T logo to a highlighted sphere). Certainly it was later that year that the much-bigger-than-life image appeared on the water tower: my calendar file still says sep 16 btl water tower 1985 Peter was still a department head at that time; he didn't climb further into management until about 1990. As I recall, the water tower remained painted for a couple of days. A two-man team from the Physical Plant department finally covered it over: one man in overalls wielding paint, another in suit and tie watching to be sure no trace remained. Lest people get the wrong idea, Peter took no offense at the overuse of his face. In fact a few years later he agreed to have a plaster cast made. Someone (Duff?) then made a latex positive from the plaster negative, intending to digitize it somehow into a three-dimensional model. I don't know if that ever happened, but I did borrow the latex one day, used it to generate another negative in ice, and cast a large chocolate truffle which I then set out in the UNIX Room (as the group's common terminal room was called) for all to enjoy. That may have been the only really interesting use of the 3d face. In any case the plaster cast was presented to me when I left the Labs in 1990, and I still have it, though I haven't done anything with it since. There were also some smaller stencils made of the same deathstar- Peter face. (In fact I have it on good authority that the big one was made by projecting one of the smaller ones on a wall.) When Bell Labs bought a Cray X-MP in 1986 or 1987 (my records aren't that complete), one of our group made several visits to Cray to get a head start on a special network interface we would need. He took along one of the small stencils and put a few Peter faces on panels that were normally covered up when the machine was running. (The Cray was to be shared by Research and the Comp Center, and the Comp Center were a bit stuffier.) To everyone's surprise, when the machine arrived it bore no extra decorations. Presumably Cray shipped the painted system to another customer; we never found out who. The Computing Science Research Center was a fun place to work. Norman Wilson Toronto ON

22 years, 8 months

1
0
0 0

Re: Weinberger stencil? (was: rtm)

by Dennis Ritchie

Lehey wondered: > .... can > you shed any light on the "Peter Weinberger stencil" incident? ... > Somebody came across the idea of > making a large stencil of his face in death-star like technology, > and used it to paint an image of him on a nearby water tower. > Allegedly the costs were charged to Peter's department. > Some years later, this stencil arrived in Greg Rose's office in > Australia from an anonymous sender. Greg has a suspicion who the > sender was, but no proof, so he doesn't want to comment. He gave it > to our own Warren Toomey, who still has it in his garage. > At some point, Peter Salus suggested that the image was of Rob Pike... I could recover some of the dates, but not accurately from memory. Weinberger was promoted, first to department head, then to being director of a newly-created but next-door center, then to our own executive director. This would have been mid-late 80s, early 90s. He was being groomed, it appears. Shortly before trivestiture, 1994ish, he went to the business part of AT&T, possibly in preparation for coming back to a higher management position at the Labs. When the Lucent/AT&T split occurred he was somewhat caught on the AT&T side. He ended up leaving AT&T and going to a financial quant company. His image was particularly striking, and was used to kid him in various ways, e,g, as a default image in mail icons. The image rendering his face with the Deathstar styling was done by Tom Duff, and it appeared, for example, on T-shirts worn publically at venues like Usenix and elsewhere. Other versions of it appear inscribed in concrete now buried beneath floors at the Labs. There is a bitmap version (rendered in 1cm magnets) of the full image, not death-starred, high on a steel wall above a landing on a nearby stairwell. The large stencilled image of the Deathstar/PJW rendition did indeed appear suddenly one day on a water tower; it must have been about 10 feet tall. Kernighan had a photo of it, and Gerard Holzmann just scanned it: http://www.cs.bell-labs.com/who/dmr/pix/watertower.jpg It was painted over quite rapidly, a couple of days at most. (The tower itself is now gone, though not because of this.) The image was certainly not of Rob Pike. After this happened, a voucher was pinned up on a communal corkboard, claiming expenses for several cans of blue spray paint. The voucher was signed by one G. R. Emlin, a fictitious personage with his (later her) own history. Attached to it was a handwritten note from our then Executive Director (Vic Vyssotsky) saying approximately as follows: Unfortunately, this voucher cannot be approved by me; I am not empowered to approve Real Estate improvements. If Mr. Emlin would like to arrange a transfer to the Building and Grounds department, I would be happy to assist. So: who did it? If Greg Rose suspects certain aviation-inclined buddies, I in turn think his suspicions are likely to be well-founded. I managed to retrieve the image used to create the stencil; it's now linked-to near the bottom of http://www.cs.bell-labs.com/10thEdMan/v2pix.html Dennis

22 years, 8 months

1
0
0 0

C reference manual

by Tony Finch

I'm looking for a copy of the C reference manual from some time between the 6th Edition (1975) and the first version that came with 4.3BSD (1986). The stuff in the TUHS archive mostly seems to be missing the documentation sets, or in the case of the earlier BSDs they are ommitted for copyright reasons. There are some tutorials dating from about 1979 but they aren't much use. Any help would be appreciated. Tony. -- f.a.n.finch <dot(a)dotat.at> http://dotat.at/ DOGGER: NORTHEAST 6 TO GALE 8 BACKING NORTHWEST 4 OR 5. RAIN OR SHOWERS. MODERATE OR GOOD.

22 years, 8 months

1
0
0 0

rtm

by A.P.Garcia

I just recently picked up a copy of a book that's been out for some time, _Cyberpunk_ by Katie Hafner and John Markoff. The last chapter is about Robert T. Morris, Jr. and the worm incident (which in itself, I think, is an important event in Unix history). The book contains some interesting details, including some Unix folklore that I haven't seen anywhere else. For instance, RTM Sr. had a terminal at home, as did other members of the CSR group at Bell Labs. So a number of their kids had accounts! RTM Sr. comes off as a very likeable fellow, btw. At the Atlanta Linux Showcase in 1999, Norm Schryer gave a keynote speech, in which he told an amusing anecdote about Morris Sr. (I may be slightly off on some details; such is oral history): Morris, he said, was the kind of guy who always liked to tinker with things, and if an object had buttons, Morris just had to push them. In fact, sometimes Morris was just a little too quick with his fingers. On one side of a machine room was the light switch, and on the other side was the power to the machine. On at least one occasion, you guessed it -- Morris hit the wrong switch. Some people hung a disk pack that got ruined around his neck, and someone put up a big sign as a reminder: "THIS IS THE WEST WALL!" :-)

22 years, 9 months

4
3
0 0

Re: rtm

by Dennis Ritchie

Garcia is correct to praise the Hafner/Markoff account of the worm incident. There were some details about the kids' accounts and exploits that Markoff decided to elide; by the time he wrote that chapter he had become rather sympathetic with the Morris family. In 1995 another big incident occurred: the exploitation of the SYN TCP-connection takeover attack (Mitnick etc.) Markoff got another front-page NYT story out of this (and a book with Shimomura). I sent mail to Markoff at the time of the newspaper coverage reminding him that RTM had discovered the basic attack in 1985 (see CSTR 117 at http://www.cs.bell-labs.com/cm/cs/cstr.html ); while here during a summer. Markoff replied in part, >Interesting how often RTM figures, one way or another, in your front-page >stories, and of course the [Cyberpunk] book.... > > Dennis Ritchie yes, this is true. you know i sat there on sunday for about ten minutes and thought about whether i should include rtm in my story - it would obviously have spiced it up. i finally decided not to on the grounds that 1. i have done enough to mythologize him for one decade 2. he is probably entitled not to be dragged through all this again. i still wonder whether i did the readers a disservice... Incidentally, "RTM Sr." was (while here) "rhm" by login name, and always called Bob; I don't think he actually has a middle name (at least I don't know it.) I think it's like Harry S Truman. RTM is called Robert, and never used Jr. About > [Bob] Morris, he said, was the kind of guy who always liked to tinker with > things, and if an object had buttons, Morris just had to push them. > In fact, sometimes Morris was just a little too quick with his fingers. > On one side of a machine room was the light switch, and on the other > side was the power to the machine. > On at least one occasion, you guessed it -- Morris hit the wrong switch. > Some people hung a disk pack that got ruined around his neck, and someone > put up a big sign as a reminder: "THIS IS THE WEST WALL!" I suspect that we may be dealing with the "Schryer filter" regarding some of the details. Norm S. was right about Bob's being an aggressive investigator and fiddler, but I don't connect the west-wall sign with Morris in particular, but my memory could be failing too. Norman Wilson might have been around for advent of the sign. In the event, it had more to do with circuit breakers labelled in small print "east wall" and "west wall" and someone choosing the wrong one. Dennis

22 years, 9 months

3
2
0 0

RE: [pups] Ultrix-3.1 boot tape inside the PDP-11 distribution directory

by Fred N. van Kempen

Gregg, > Question 1) Has anyone actually followed the instructions and > description of same, found inside the readme file found in the > directory? Yes. They are a cut-and-paste log of my actual screens, although I can't remember exactly what was in the file. > Question 2) Was this on actual hardware? Or inside the Simh simulator? > Or even with one version of E11? I did installs on real hardware (MicroPDP-11/23 and MicroPDP-11/83), and on Ersatz-11 (V3.0) for DOS. > In my case this will be inside the Simh simulator, and I am basically > working straight from the beginning. If all goes well, I'll move it to > the E11 one. Ultrix-11 runs fine on SimH, with the "downs" that because SimH does not do detailed and correct CPU emulation, Ultrix gets confuzed every now and then, which does not happen with E11. I am preparing a new (V3.2) release of Ultrix-11 which has major changes, including: - full system regeneration off single source tree - full RAxx support - addition of VTserver, TDU and compress - compressed manual pages and documentation - Y2K support (not just date(1) ;-) The installation procedure has also changed to a more modern style. I don't have much time right now, so progress is slow. The above is "done", though. If you need help with Ultrix-11, pse contact me off-list. --fred

22 years, 9 months

1
0
0 0

[pups] Ultrix-3.1 boot tape inside the PDP-11 distribution directory

by Gregg C Levine

Hello from Gregg C Levine This is both my first post from this address, and a couple of questions. Question 1) Has anyone actually followed the instructions and description of same, found inside the readme file found in the directory? Question 2) Was this on actual hardware? Or inside the Simh simulator? Or even with one version of E11? In my case this will be inside the Simh simulator, and I am basically working straight from the beginning. If all goes well, I'll move it to the E11 one. ------------------- Gregg C Levine hansolofalcon(a)worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda )

22 years, 9 months

1
0
0 0

Re: [TUHS] rtm

by msokolov＠ivan.Harhan.ORG

Jeffrey Sharp <jss(a)subatomix.com> wrote: > Yes, I believe I am somewhat younger than most the very respectable members > of this group. :-) I'm about the same. My timeline: 1979 born 1988 first computer: Soviet PDP-11 clone, first language: PDP-11 assembly 1995 first introduced to UNIX 1996 first live encounter with a VAX 1998 started maintaining my own version of VAX UNIX 2000 fully converted to it 2002 thinking about designing and building a new VAX CPU on an FPGA MS

22 years, 9 months

1
0
0 0

Actual names of boot images versus names listed in readme file for boot_images

by Gregg C Levine

Hello from Gregg C Levine I found out, on my system, and borrowing the Cygwin tools for file manipulation, the actual file name for .2,9BSD_rl02_1145.gz, it is rl02_2.9BSDroot, so I used that name in place of the one suggested inside the readme file. It works the same way. However, this is just the root collection. Is there any other pack available that contains the other members of the entire 2.9BSD system that provided us with this one? Also this was done with version 2.9-11 of Simh. So, when you get a chance, Warren, you can update the readme, and upload the appropriate file to the directory on your server. Oh yes, this came from a mirror of your site, its the one on ftp.tux.org Gregg C Levine drwho8(a)worldnet.att.net "Oh my!" The Second Doctor's nearly favorite phrase.

22 years, 9 months

1
0
0 0

Pack found in Tim Shoppa distribution but not listed

by Gregg C Levine

Hello from Gregg C Levine This is something that is totally different then what I first reported on regarding this distribution. In the readme for this one, it mentions everything list inside the directory, except the one marked down as "Unlabeled", and it originally came on a RL02 type diskpack. It is not listed in the Readme. Obviously it is what it says it is, an unlabled diskpack that Tim recovered the same day as the others, and those are indeed present, and listed. Except obviously the one that I first reported, that one isn't mentioned, and not there. That subject is done. I am just reporting on "Unlabeled", as far as everyone is concerned, is there anything on it? Or is it an empty pack? Gregg C Levine drwho8(a)worldnet.att.net "Oh my!" The Second Doctor's nearly favorite phrase.

22 years, 9 months

2
1
0 0

Re: [TUHS] Can someone advise me regarding a gui for UNIX

by Aharon Robbins

Another reason the 5620 was botched so badly was that AT&T wanted >= $2000 for the development kit (read: C compiler and libraries) for it. Not a good way to get lots of 3rd party application developers on your bandwagon. I used one for a year or so; it was the first windowing system I'd used and the only one I've really liked. For about 10 years I've been using 9wm, which gives a similar feel (at least to me). Those who want to go all the way should adopt 9term as well. (I generally run xterm + bash these days, although for a long while it was 9term + es/rc.) Somewhere, I have an X version of the 5620 font. I found that it wasn't so pretty. I've been using the pelm-latin1-9 font from the sam distribution for years. Norman forgot to mention that the most long-lived split-design application is Rob Pike's sam editor, still available for X11 and still in use on Plan 9. Arnold

22 years, 9 months

1
0
0 0

Re: Can someone advise me regarding a gui for UNIX

by Brian S Walden

Another hurdle for the 5620/630/730 lines of terminals was when I tried getting software support. Teletype being a mostly a "dumb" terminal manufacturer never considered them more that a way to have multilple 80 char x 24 line terminals on one display. I had difficulty in conveying to them that it was a computer in its own right and you could program it. The marketing was probably just as limited in scope. Another blow for the BLIT portion on the terminal came when you cound get an external cartridge for the 730 that turned it into an X-terminal. I got mine in 1991 and then rarely used layers after that. -B

22 years, 9 months

1
0
0 0

Re: Can someone advise me regarding a gui for UNIX

by Dennis Ritchie

Norman Wilson's account of the Jerq/Blit etc. is quite complete and correct, though there was some recycling of names. 'Jerq' actually was used quite early, when Pike got interested in bitmap graphics. The name was a takeoff on the Three Rivers Perq, which he (and I) saw at Lucasfilm Ltd. while attending an early Usenix. Blit was the slightly more PC version (suggested either as part of BitBlt or "Bell Labs Interactive Terminal). The originals used the Motorola 68000, and part of the development messup was AT&T Computer systems' decision to switch to the WE32000 processor with consequent delay for porting and reworking. The earliest versions were not quite as wonderful in practice as Norman suggests for the later ones. They were built by the Teletype corp. model shop (in quantity of a few hundred) and downloading the OS took several minutes at 1200bps--necessary at startup, since they didn't have a ROM for the whole thing, just enough for doing a download. They were also static electricity antennas! Many is the time that I would shift in my chair, then touch the keyboard, only to have the terminal reset itself. I developed the habit of putting my hand on the heavy steel case before moving around. On the other hand, the basic idea was architecturally right (and the later commercial versions were not so subject to static, and had ROM for the OS). They were even nicer at 9600bps. It's good to know that Norman is still using his. Dennis

22 years, 9 months

1
0
0 0

Re: [TUHS] Can someone advise me regarding a gui for UNIX

by A.P.Garcia

> I've been using this window system more or less daily since August 1984, > though only at home since I left Bell Labs in 1990. (I am using it to > type this message.) ! what other hardware and software do you run, if you don't mind my noseyness?

22 years, 9 months

1
0
0 0

re: c coding standards

by A.P.Garcia

> Not to be overly picky, but aren't there two copies of everything. yes, sorry. that's just how it was posted to usenet.

22 years, 9 months

1
0
0 0

Re: [TUHS] c coding standards

by Carl Lowenstein

> From: "A.P.Garcia" <apgarcia(a)uwm.edu> > To: tuhs(a)minnie.tuhs.org > Subject: [TUHS] c coding standards > Date: Fri, 11 Oct 2002 01:52:08 +0000 > > check out this old post I found on Google Groups. > this kind of stuff makes me giddy. :-) < 2288 lines deleted > Not to be overly picky, but aren't there two copies of everything. carl -- carl lowenstein marine physical lab u.c. san diego clowenst(a)ucsd.edu

22 years, 9 months

1
0
0 0

Re: [TUHS] Can someone advise me regarding a gui for UNIX

by norman＠nose.cs.utoronto.ca

22. Pike, R. "The Blit: A Multiplexed Graphics Terminal". _AT&T Bell Laboratories Technical Journal 63_, 8 (Oct. 1984). Rob described an earlier version of the Blit work in a USENIX talk at USENIX in January 1982 (Santa Monica CA). So far as I know it was just a talk, no paper, though he showed a canned demo on video tape. For those who don't know it, the Blit (in later versions called the Jerq; in official product version, the AT&T 5620 DMD terminal, and later the 630 and 730) is a separate terminal with a bitmapped display, keyboard, and mouse. The window system runs in the terminal; a multiplexed-channel protocol (one channel per window) is used to communicate with the host computer; a (user-mode) multiplexer program on the host passes data for each channel to and from an appropriate local process (group), one per channel. Creating a new window in the terminal tells the multiplexer to create a new process in the host. By default the window is just a terminal (and the process is a shell), but it is possible for a host program to download a program into the terminal (where it can get at the screen and mouse directly) to act on its behalf just for its own window; that's how graphical programs work. This often requires programs to be split into front and back ends, but often that turns out to be a good idea anyway, keeping user-interface work and file-manipulation and computation separate. It also means much less communication bandwidth is needed; in fact the communication line is RS232 (what else would you expect in 1982?). It worked fine, even at 1200 bps, except when a large graphical front- end program had to be loaded, but people tended to load such programs once and keep them running. I've been using this window system more or less daily since August 1984, though only at home since I left Bell Labs in 1990. (I am using it to type this message.) It is Spartan by modern standards--menus are short and to-the-point, windows are not surrounded by fancy borders and icons, there is no `desktop' or `graphical user environment'--it's just good old UNIX in multiple windows, with a terminal window that makes good use of the mouse for local editing, and provision to run fancier programs when necessary. It wouldn't work well for graphics-heavy work unless the communication line could be greatly sped up--a web browser would be hard to make work well unless all the pictures were left out. But it's well thought out, with a nice balance between spareness and function. I still like it better than any other window system I've seen; even Rob's more recent work in Plan 9 seems to me over-elaborate by comparison. I also like much better the overall model that the terminal is a client rather than a server; X11 always seemed inside-out to me. I am still disappointed that the process of turning the Blit from a research tool to a salable product was botched so badly. If memory serves, not only did it take several years longer than it should have done, but when the 5620 hit the streets in early 1984 it cost a mere $6000, which even in those days was outrageous for a terminal. (None of this was Rob's fault so far as I know.) If things had gone better, the UNIX windowing world might have turned out quite different. Norman Wilson Toronto ON

22 years, 9 months

1
0
0 0

c coding standards

by A.P.Garcia

check out this old post I found on Google Groups. this kind of stuff makes me giddy. :-) -=-=-=- Message-ID: <bnews.mit-vax.149> Newsgroups: net.sources X-Path: utzoo!decvax!harpo!eagle!mit-vax!mp From: mit-vax!mp Date: Tue Jun 29 08:07:31 1982 Subject: C coding standards X-Google-Info: Converted from the original B-News header Posted: Sun Jun 27 18:24:20 1982 Received: Tue Jun 29 08:07:31 1982 In my message in net.misc about coding standards, I offered to send out the Stanford Network Graphics project's C style sheet. Since almost everyone who responded to my query requested a copy of that document, I decided to post it to the net. In fact, thanks to JBrookshire@USC-ECLB, I now have 3 different C style standards to give you. Each is separated by a line of "*********"s. Mark Plotnick, MIT ************************************************ INGRES CODING CONVENTIONS FOR C/UNIX PROGRAMMING University of California, Berkeley "The Ingres data base system encompasses about 75,000 lines of code in the programming language `C' and runs on top of the Unix operating system. Over the past six years, Ingres has evolved into a functionally complete and usable prototype. Development required 25 to 30 programmer-years by a total of 19 people, and the systems is now in use at over 125 sites around the world." Allman, Eric.; and Stonebreaker, Michael "Observations on the Evolution of a Software System." COMPUTER 15, 6 (June 1982), 27-32. The following represents the current C coding conventions that have evolved from and during the development of the Ingres system. This document has been provided by Joe Kalash of Berkeley <INGVAX.kalash at Berkeley> in response to a general enquiry distributed via Arpanet BBOARDS. /* ** CODE_CNVNTNS.C -- A Program to Display the INGRES Coding Style ** ** This hunk of code does virtually nothing of use. Its main ** purpose is to demonstrate the "official" ingres coding style. ** ** This demonstrates comments. There should be a block comment ** at the beginning of every file and/or procedure to explain ** the function of the code. Important information to put here ** includes the parameters of the routines, any options that the ** user may specify, etc. ** ** The first line of the comment should be a one-line description ** of what's going on. The remainder should be more detailed. ** Blank lines should seperate major points in the comments. In ** general, ask yourself the question, "If I didn't know what this ** code was, what it was for, how it fit in, etc., and if I didn't ** even have the documentation for it, would these comments be ** enough for me?" ** ** Some general guidelines for the code: ** ** ***** GENERAL SYNTAX ***** ** ** - Commas and semicolons should always be followed by a space. ** Binary operators should be surrounded on both sides by ** spaces. Unary operators should be in direct contact ** with the object that they act on, except for "sizeof", ** which should be seperated by one space. ** ** - Two statements should never go on the same line. This includes ** such things as an if and the associated conditionally ** executed statement. ** In cases such as this, the second half of the if ** should be indented one tab stop more than the if. For ** example, use: ** if (cond) ** statement; ** never: ** if (cond) statement; ** or: ** if (cond) ** statement; ** ** - Braces ({}) should (almost) always be on a line by them- ** selves. Exceptions are closing a do, and terminating ** a struct definition or variable initialization. Braces ** should start at the same indent as the statement with ** which they bind, and code inside the braces should be ** indented one stop further. For example, use: ** while (cond) ** { ** code ** } ** and never: ** while (cond) ** { ** code ** } ** or: ** while (cond) { ** code ** } ** or: ** while (cond) ** { ** code ** } ** or anything else in that line. Braces which match ** should always be at the same tab stop. ** ** - Do statements must always be of the form: ** do ** { ** code; ** } while (cond); ** even if "code" is only one line. This is done so that ** it is clear that the "while" is with a do, rather than ** a standalone "while" which is used for the side effects of ** evaluation of the condition. ** ** - There should always be a space following a keyword (i.e., ** for, if, do, while, switch, and return), but never ** between a function and the paren preceeding its ** arguments. For example, use: ** if (i == 0) ** exit(); ** never: ** if(i == 0) ** exit (); ** ** - Every case in a switch statement (including default) should ** be preceeded by a blank line. The actual word "case" or ** "default" should have the indent of the switch statement plus ** two spaces. It should be followed by a space (not a ** tab) and the case constant. Multiple case labels on ** a single block of code should be on seperate lines, but ** they should not be seperated by blank lines. The ** switch statement should in general be used in place of ** such constructs as: if (i == 1) ** code1; ** else if (i == 34) ** code2; ** else if (i == -1643) ** code3; ** which can be more succinctly stated as: ** switch (i) ** { ** case 1: ** code1; ** break; ** ** case 34: ** code2; ** break; ** ** case -1643: ** code3; ** break; ** } ** In point of fact the equivalent switch will compile ** extremely efficiently. (Note that if you had some ** instance where you could not use a case, e.g., checking ** for i < 5, else check for j > 3, else whatever, then ** the above ("if") code is in the correct style. However, ** if (i < 5) ** code1; ** else ** if (j > 3) ** code2; ** else ** code3; ** is acceptable. ** ** - A blank line should seperate the declarations and the code ** in a procedure. Blank lines should also be used freely ** between major subsections of your code. The major ** subsections should also have a block comment giving ** some idea of what is about to occur. ** ** ***** PREPROCESSOR USAGE ***** ** ** - Fields of #defines and #includes should line up. Use: ** # define ARPA 25 ** # define MAXFIELDS 18 ** and not: ** #define ARPA 25 ** #define MAXFIELDS 18 ** Conditional compilation (#ifdef/#endif) should be used ** around all trace information, timing code, and code ** which may vary from version to version of UNIX. See ** the code below for an example of conditional compila- ** tion use. ** ** ***** VARIABLES AND DECLARATIONS ***** ** ** - Defined constants (defined with the # define feature) must ** be entirely upper case. The exceptions to this are ** compilation flags, which begin with a lower case "x", ** and some sub-types for parser symbols. In any case, ** the majority of the symbol is upper case. ** ** - Global variables should begin with an upper case letter and ** be otherwise all lower case. Local symbols should be ** entirely lower case. Procedure names are all lower ** case. The only exception to this is the trace routine ** "tTf". You should avoid user non-local symbols (globals ** or # define'd symbols) which are one character only; ** it is impossible to distinguish them. Capitalization ** may be used freely inside global names so long as they ** are primarily lower case; for example, "ProcName" is ** an acceptable name (and preferred over either Proc_name ** or Procname). ** ** - Use descriptive variable names, particularly for global var- ** iables. "IEH3462" tells me nothing; nor does "R". On ** the other hand, "Resultid" tells me quite a lot, ** including what it might be, where I might go to see ** how it is initialized, etc. Try not to use variables ** for multiple purposes. Variable names like "i" are ** acceptable for loop indices & temporary storage ** provided that the value does not have long-term ** semantic value. ** ** - When the storage structure or type of a variable is ** important, always state it explicitly. In particular, ** include "auto" if you are going to take the address ** of something using the ampersand operator (so that ** some wayward programmer doesn't change it to register), ** and declare int parameters as int instead of letting ** them default. ** ** ***** GENERAL COMMENTS ***** ** ** - It is quite possible to name a file "printr.c" and then ** put the code for "destroydb" in it. Try to arrange ** the names of your files so that given the name of a ** routine, it is fairly easy to figure out which file ** it is in. ** ** - Sometimes it is really pretty much impossible to avoid doing ** something tricky. In these cases, put in a comment ** telling what you are doing and why you are doing it. ** - Try to write things that are clear and safe, rather than ** things which you think are easier to compile. For ** example, always declare temporary buffers as local, ** rather than as global. This way you can another ** routine accidently when it still had useful info ** in it. ** ** ***** COMMENTS ***** ** ** - The importance of comments cannot be overemphasised. ** INGRES is primarily a research vehicle rather than ** a program product. This means that there will be ** many people pouring over your code, trying to ** understand what you have done & modify it to do ** other things. Try to make life easy for them & ** maybe they will be nice to you someday. ** ** - Try to keep an idea of the flow of your program. Put ** block comments at the beginning of major segments, ** and use one-line comments at less major junctures. ** A person viewing your code at ten paces should be ** able to tell where the major segments lay. ** ** - The preferred format for block comments is to begin with ** a line containing slash-star alone, followed by a ** number of lines all beginning star-star containing ** the comment, and terminating with a line containing ** star-slash alone. Comments without the double-star ** at the beginning of each line should be avoided, ** since it makes the comments seemingly disappear into ** the body of the code. ** ** - The beginning of each routine should have a comment block ** in parametric form as demonstrated below. The fields ** "Parameters", "Returns", and "Side Effects" should ** be considered mandatory. Mark parameters as being ** (IN), (IN/OUT), or (OUT) parameters, depending on ** whether the parameter is used only to transmit infor- ** mation into the routine, in and out of the routine, ** or only to return information; the default is (IN). ** ** Remember, it is easy to write totally incomprehensible code in ** C, but we don't go in for that sort of thing. It isn't too ** much harder to write brilliantly clear code, and the code is ** worth a lot more later. ** ** For efficiency reasons, you should always use register variables ** when possible. A simple and extremely effective tip is to define ** a register variable, and assign an oft-used parameter to it, ** since it is particularly inefficient to reference a parameter. ** Another particularly inefficient operation is referencing arrays ** of structures. When possible, define a register pointer to the ** structure, and then say: ** struct xyz structure[MAX]; ** register struct xyz *p; ** ... ** for (i = 0; i < MAX; i++) ** { ** p = &structure[i]; ** p->x = p->y + p->z; ** (diddle with p->???) ** } ** and not: ** struct xyz structure[MAX]; ** ... ** for (i = 0; i < MAX; i++) ** { ** Structure[i].x = Structure[i].y + Structure[i].z; ** (diddle with Structure[i].???) ** } ** Remember, the nice things about register variables is that they ** make your code smaller and they run faster. It is hard to ** lose with registers. There are three restrictions which you ** should be aware of on register variables, however. First, ** The only types which may be registers are int's, char's, ** and pointers. Second, there may only be three register ** variables per subroutine. Third, you may not take the address ** of a register variable (i.e., you may not say "&i" if i is ** typed as a register variable). ** ** Usage: ** example [flags] argument ** ** Positional Parameters: ** argument -- this gets echoed to the standard ** output. ** ** Flags: ** -n -- don't put a newline at the end. ** -x -- don't do anything. ** -b -- echo it with a bell character. ** ** Return Codes: ** 0 -- successful ** else -- failure ** ** Defined Constants: ** XEQ1 -- maximum number of simultaneous equijoins. ** ** Compilation Flags: ** xTRACE -- enable trace information ** ** Trace Flags: ** 5 -- general debug ** 6 -- reserved for future use ** Compilation Instructions: ** cc -n example.c ** mv a.out example ** chmod 755 example ** ** Notes: ** These comments don't apply to the code at all, ** since this is just an example program. ** Also, it is wise to avoid this many comments ** except at the head of main programs and ** at the head of major modules. For example, ** this sort of commenting is appropriate at ** the top of ingres.c (system startup) and ** view.c (virtual view subsystem), but not ** in small utility routines, e.g., length.c. ** This sort of routine should be limited to ** "Parameters:", "Returns:", "Side Effects:", ** and anything else that seems relevant in ** that context. ** A fairly large comment block should exist at the ** top of modules [files] which contain many ** procedures; this block should clarify why ** the procedures are grouped together, that ** is, their common purpose in life. A small ** block should occur at the top of each ** procedure explaining details of that proce- ** dure. ** Procedures should be on seperate pages (use the ** form feed character, control-L). ** A program will help you generate this comment block. ** In ex, go to the line where you want to insert ** a block and say "so /mnt/ingres/comment". It ** will ask you for a block type, e.g., "main" ** for main program, "modfn" for a file which ** contains only one function, "function" or ** "procedure" for a procedure within a module, ** "module" for a module header (e.g., as a ** seperate comment block for a major module ** [check .../qrymod/view.c for an example] or ** in header files. ** SCCS should be considered an essential tool, if only ** to maintain history fields. ** ** Deficiencies: ** It should handle pseudo tty's. */ /* the following macro is defined by <sccs.h> */ SCCSID(%W%); /* %W% is replaced by a version number by SCCS */ # define XEQ1 5 struct magic { char *name; /* name of symbol */ int type; /* type of symbol, defined in symbol.h */ int value; /* optional value. This is actually * the value if it is type "integer", * a pointer to the value if it is a * string. */ }; struct magic Stuff; main(argc, argv) int argc; char *argv[]; { register struct magic *r; register int i; register int j; int timebuf[2]; auto int status; /* ** Note that in the declarations of argc and argv above, all ** parameters to any function should be declared, even if they ** are of type int (which is the default). */ r = &Stuff; /* initialize random # generator */ time(timebuf); srand(timebuf[1]); /* scan Stuff structure */ for (i = 0; i < XEQ1; i++) { # ifdef xTRACE if (tTf(5, 13)) printf("switch on type %d\n", r->reltype); # endif switch (r->type) { case 0: case 1: case 3: /* initialize */ printf("hi\n"); break; case 2: /* end of query */ printf("bye\n"); break; default: /* ** be sure to print plenty of info on an error; ** "syserr("bad reltype");" would not have been ** sufficient. However, don't make syserr's ** overly verbose; they take much space in the ** object module, and it will probably be ** necessary to look at the code anyway. */ syserr("main: bad type %d", r->type); } } /* resist the temptation to say "} else {" */ if (i == 5) { i++; j = 4; } else i--; /* plot the results */ do { i = rand() & 017; plot(i); } while (j--); /* wait for child processes to complete */ wait(&status); /* end of run, print termination message and exit */ for (i = 0; i < 2; i++) printf("bye "); printf("\n"); } ** PLOT -- Plot a Bar-Graph ** ** Does a simple plot on a terminal -- one line's worth. ** ** Parameters: ** n (IN) -- number of asterisks to plot ** ** Returns: ** none ** ** Side Effects: ** none ** ** Deficiencies: ** Should allow scaling. */ plot(n) int n; { register int i; for (i = n; i-- > 0; ) { printf("*"); } printf("\n"); } ************************************************************************** BBN PROGRAMMING STANDARDS FOR C The following document was provided by Dan Franklin <DAN at BBN=UNIX> in response to a general enquiry distributed to Arpanet BBOARDS: Here's a short set of guidelines that represents a combination of the thoughts of two groups within BBN. I was its last editor. Hope you find it useful. If you come across something more comprehensive (which this certainly isn't), I'd appreciate it if you let me know. PROGRAMMING STANDARDS AND PRACTICES FOR THE UNIX COST CENTER This memo proposes a set of practices that might be followed in the cost center, in order to have a consistently organized and written, readable, understandable, and ultimately maintainable software package. Qualifying each of the items below is an (S) or (P): the former indicates that, once agreed-upon, the rule must be adhered to rigorously and consistently--a Standard; the latter items are more of the flavour of "good programming Practice"--once agreed-upon, programmers should follow the practice to the extent that common sense dictates. 1. DOCUMENTATION OF ROUTINE INTERFACES (S) Every routine should be prefaced by a standard header which describes the routine and its interface precisely, so that the routine could be used by someone without reading the code. The rationale for such a header is that it concentrates the critical document- ation in one place, making it easy for someone (including the original designer/coder) to use the routine correctly, and allows for the possibility of automatically stripping off all headers to form an Internal Documentation document. In some cases a routine may do a small amount of processing and then call another routine. (As an example, a routine may provide a "special case" interface to another more general routine with a more cumbersome calling sequence.) In this case, a routine's header may refer the reader to the header of another routine for further information. The format suggested is illustrated below: comments are surrounded by < > symbols. Any item that is irrelevant, e.g., no parameters, no return value, no error conditions, may be omitted. /*------------------------ E P R I N T -----------------------------------*/ /* <a brief description of the routine...also, put the routine name in * caps in the line above. The description should give, in general * terms, the routine's function, including an overall description of its * parameters, return values, and effect on global databases. It should also * describe any error conditions that may occur and be reflected to the * caller. The return value must be described precisely.> */ int eprint(estrucp, istart, ilength) struct estruct *estructp; /* Pointer to eprint's structure */ int istart; /* Place in structure to start from */ int ilength; /* # things in struct to print */ { } Note that each parameter gets its own declaration line, and has a comment to convey its exact meaning. Each file in a program or subsystem consisting of multiple files should start with some additional information, giving (essentially) the justification for putting all these routines in one file. That is, it should include a description of the common function they all perform, the related functions they all perform, the database they have in common and which is contained only in this file, etc. In the last case, especially, a detailed description of the database should be included; otherwise, since the database is not part of any one routine, it will not get described in any other comment field. The detailed description may require reading comments associated with the actual declarations in order to be complete. This header should include a history list describing all modifications to functions in this file. Each entry in the list should give the person, the date, the names of the functions (or database elements) changed, and the reasons. For the file containing the main routine of a program, the following standards should be observed: 1. The main routine should be the first routine in the file. 2. Before the main routine should appear an overall comment field describing the calling sequence in some detail. Generally, the program will also be described in a manual page as well; this comment field need not duplicate the entire contents of the manual page, but it should include information about the overall structure of the program which would be useful to a maintainer. 3. The main routine should exit by calling exit(0) explicitly. All programs, however, must return an exit status of zero on success, and nonzero on error. 2. FORMATTING (S) All programs must be indented, at least 4 spaces per indentation level. Statements at the same nesting level should be at the same indentation level; statements at deeper nesting levels should be indented more. (For the purposes of this standard, the keyword "else" is regarded as having the same nesting level as the "if" it corresponds to.) For example, the following indentation practices are not permitted: if (condition) statement-group; if (condition) statement-group; else statement-group; if (condition) for (init; test; step) statement-group; if (condition) statement-group; else statement group; (S) Nesting the trinary conditional operator (?:) is not permitted. (P) For internal formatting and indenting style, the following is recommended: . 4-space indentations at each level; . braces delineating blocks used in the style of if (exp) { code } or if (exp) { code } . a separate declaration statement for each pointer, due to the confusion that can arise when reading and modifying a declaration like char *a, b, *c; . comments lined up systematically; . spaces between reserved words and their opening parentheses, e.g., if (condition) rather than if(condition); . no deep nesting (greater than 4 levels deep) . statement blocks less than 1 page long . one statement per line . parentheses around the objects of sizeof and return. (P) Concerning internal comments: . Full English sentences are recommended. . It is often clearer and more readable to make small blocks of comments as "paragraph headers" to a block of code than to comment every line or so, especially if the code is straightforward and untricky (which most of it should be, especially if the programmer is conscientious about variable naming and datatype compatibility). . Anything non-obvious should be well-commented. (P) Concerning white space and other aids to readability and debugging: . blank lines should be used between blocks of code that are functionally distinct . in expressions, operators should be surrounded by blanks (but not operators which compose primaries, specifically ".", "->") . in a function definition, the function name and its datatype should appear on one line. Examples: int pread(...) SOMESTRUCT * function(param1, param2) This latter practice aids readability and the comparison of the definition of a routine with its uses. (P) Other suggestions for improving readability: . Side effects within expressions should be used sparingly. It is recommended that no more than one operator with a side effect (=, op=, ++, --) appear within an expression. Function calls with side effects count as operators for this purpose. . In an "if-else" chain, the form if (condition) statement; else if (condition) statement; else if (condition) statement; should only be used when the conditions are all of the same basic form: e.g., testing the same variable against different values. If the conditions are qualitatively different, the additional "if" statements should start on new lines, indented, as in if (cond) statement; else if (cond2) statement; else statement; . In the condition portion of an if, for, while, etc., side effects whose effect extends beyond the extent of the guarded statement block should be minimized. That is, in a block like if ((c = getc(file)) != EOF) { guarded-stmts } other-stmts it is natural to think of "c" being "bound" to a value only within the guarded-stmts; use of a variable set or modified in a condition, outside the range of the statements guarded by the condition, is quite distracting. . The use of || and && with right hand operands having side effects is discouraged. Also, whenever || and && are mixed in the same expression, parentheses should be used for clarity. 3. MODULARITY 3.1. Routine Length (P) Routines should be kept reasonably short. In general, a routine (or command) processes one or more inputs and generates one or more outputs, where each of the inputs and outputs can be concisely described. Usually a routine should only perform one function. Signs that a routine is too long, and ought to be split up, are: length greater than two pages; heavy use of "internal" variables (variables whose scope is less than the entire routine). 3.2. Shared Data and Include Files (S) Declarations of variables that are to be shared among several routines in a package should be placed at the beginning of the file containing the routines. If they are entirely internal to the package, they should be declared "static" to hide them from other files. (S) Declarations of structures and global variables used for communications between a package and its callers should be placed in an appropriately named .h file. Shared global variables should be declared extern in the .h file so that if the package which sets/uses them is accidentally not loaded, a diagnostic will be issued by the loader. (S) Definition and optional initialization of such globals should reside in one and only one file for each program. If a global is clearly associated with a specific package, it may be defined in the file for that package; otherwise, it should be placed in a file called data.c which is compiled and linked with the other routines when a program is being built. (P) Use of globals should be minimized by judicious use of parameters. Note that while static and extern designators in C both yield "common" storage allocation, static allows the named variable to be known only within the context in which it is declared; thus, an identifier declared static at the top of a file will only be known within the file. In addition, local symbolic constants (#defines) may occur anywhere within a routine, and may be placed below the #include directives if the writer feels that this aids readability. (S) Include files should contain all and only all of the following items necessary for a given program and shared among two or more of its files: . #defines . typedefs . extern declarations (S) Include files may also contain nested #include directives. However, this practice should be kept to a minimum. It is recommended that include files which may be embedded in this way contain a check to see whether they are being included twice, to avoid unnecessary preprocessor and compiler complaints when the user includes them both implicitly and explicitly. The simplest way to do this is to check for a special hidden #define, as in #ifdef _INCLUDEFILENAME #define _INCLUDEFILENAME . . Contents of include file . #endif _INCLUDEFILENAME 3.3 Routine interfaces (P) In general, a routine should be designed with a "natural", easily-remembered calling sequence. Routines with more than five arguments are not recommended. Routines with "op-code" arguments, where one argument determines the interpretation and functions of the others, are also not recommended (though they may prove useful as internal routines to a package, they should NOT be part of a package's documented interface). 4. PORTABILITY (P) Adherence to datatype compatibility should be practiced where reasonable. This can be facilitated by liberal use of C's typedef facility and explicit casting of types, as well as by the use of the union datatype. (P) The following violation of strict adherence is permitted: a package which returns a pointer to a structure whose format need not be known outside that package may return a "generic" pointer, of type (char *). It is recommended that the typedef PTR be used for this purpose; this typedef will be provided in some standard system file. Note that char* is specifically chosen because the language guarantees that any pointer may be converted to a char* and back again without harm. (S) Liberal use of #defines should eliminate "magic numbers", whether machine dependent or implementation dependent or arbitrary/random. (S) To the extent that the conditional compilation facility of C allows, non- portable constructions can use this facility. Failing this, machine or implementation dependent constructs should be visibly commented in the code. When using conditional compilation for portability purposes, be sure to use appropriate parameters, rather than machine type, wherever possible. For example, code which handles the C machine's 20 bit wordsize or 10 bit bytesize should use the parameter BYTESIZE in cpu.h rather than being ifdeffed on "mbb". (P) Up to six register variables can be declared (with some effect) on the C70 machine, but only three on the 11/70 (where additional ones are assigned regular automatic storage). Therefore, the first three register variables declared (in lexicographic order) should be ones for which the most gain can be gotten. Note that register variables, judiciously chosen, can be very good space/time savers, but the compiler is not overly smart about them, and can give you irritating "expression overflow" messages. In general, as with any "optimization", it is wise to design, code and debug first, and then add in register storage to one's declarations. 5. NAMING (P) Names should be chosen for their mnemonic nature. Recall that although there is a limit on the number of initial characters of a name that must be distinct in C (and for a given machine), this does not prevent any name from being longer if such length will aid readability. (S) It is a useful C convention to use upper-case for #defines and typedef names. (S) One exception to the above is for parameterized #defines. These may be in lower-case. ************************************************************************** The following was provided via FTP by Keith A. Lantz at Stanford <CSL.LANTZ at SU-SCORE> via FTP following the enquiry distributed via Arpanet BBOARDS. 1 NETWORK GRAPHICS C STYLE SHEET Andrew Shore, et al. Computer Systems Laboratory Stanford University Stanford, CA 94305 18 June 1982 1. Names Don't use capital letters in file names (except for V !?). Avoid the underscore. Global variables, procedures, structs, unions, typedefs, defined constants, and macros all begin with a capital letter, and are logically capitalized thereafter (e.g. MainHashTable). A global variable is one defined outside a procedure, even though it may not be exported from the file, or an external variable. The motivation for treating macros and constants this way is that they may then be freely changed to procedure calls or (global or external) variables. Local variables begin with a lower-case letter, but are logically capitalized thereafter (e.g. bltWidth, power, maxSumOfSquares). Fields within structures or unions are treated in this manner also. 2. Comments There are generally two types of comments: block-style comments, and on-the- line comments. Multi-line, block-style comments will follow the UNIX style of /* and */ appearing on lines by themselves, and the body of the comment will start with a properly aligned *. The comment should usually be surrounded by blank lines as well. The motivation for this is that it is easy to add/delete first and last lines, and it is easier to detect the common error of omitting the */ and thus including all code up to and including the next */ in a comment (Yapp helps with that too). /* * this is the first line of a multi-line comment, * this is another line * the last line of text */ On-line comments are used to detail declarations, and to explain single lines of code. And, I suppose, for brief (i.e. one line) block-style descriptive comments. 1 This work was supported by the Defense Advanced Research Projects Agency under contract number MDA903-80-C-0102. 2 Procedures are preceded by block-style comments, explaining their (abstract) function in terms of their parameters, results, and side effects. Note that the parameter declarations are indented, not flushed left. /* * Unblock: * unblock the process pd */ Unblock( pd ) register Process pd; /* the process to unblock */ { register Process *currPd, *tmpPd; register unsigned prio; prio = pd->priority; Disable; pd->state = Ready; /* Add pd to the ready queue */ currPd = (Process *) &ReadyqHead; while ((tmpPd = currPd->link) != Null) { if (tmpPd->priority > prio) break; currPd = tmpPd; } pd->link = tempPd; currPd->link = pd; Enable; } 3. Indenting The above example shows many of the indenting rules. Braces ( "{" and "}" ) appear alone on a line, and are indented two spaces from the statement they are to contain the body of, the body is indented two more spaces from the braces (for a total of four spaces). else's and else if's line up with their dominating if statement (to avoid marching off to the right, and to reflect the semantics of the statement). 3 if ((x = y) == 0) { flag = 1; printf (" the value was zero "); } else if (y == 1) { switch (today) { case Thursday: flag = 2; ThursdayAction(); break; case Friday: flag = 3; FridayAction(); break; default: OtherDayAction(); } } else printf(" y had the wrong value "); 4. File Contents I think we agreed on the following order for file contents. 1. initial descriptive comment (see example below) which contains: a. file name, with indication of the relative path to it when relevant b. brief descriptive abstract of contents c. a list of all defined procedures in their defined order d. list of authors e. list of current maintainers f. list of recent and major modifications in reverse chronological order with indication (initials) of who made the change. 2. included files (use relative path names whenever possible) 3. external definitions (imports and exports) 4. function declarations (externals and forward references) 4 5. constant declarations 6. macro definitions 7. type definitions 8. global variable declarations 9. procedure and function definitions Here is an example of the header comment: /* * FILE: libc/vkstuff/malloc.c * * CONTENTS: * C storage allocator stolen and hacked up from UNIX for the SUN * (NOTE: these were stolen and have the wrong naming conventions) * malloc * free * realloc * allock DEBUG ONLY! * SetBrk ! our routine to fake up sbrk() * * AUTHORS: stolen and hacked by Andrew I. Shore (shore) * * MAINTAINER: shore * * HISTORY: * 03/05/82 AIS replaced calls to UNIX sbrk() with calls to own version * SetBrk() for the sun/Vkernel */ 5. Parenthesis () We seem to have decided on the following conventions for parentheses. When parentheses enclose the expression for a statement (if, for, etc.), the parentheses `belong to' the expression, so there is a space between the keyword and the parenthesized expression. For function calls the parentheses `belong to' the call, so there is no space between function name and open paren (there may some inside the parentheses to make the expression list (argument list) look nice). if (Mumble()) { Grumble( (a = b) == 0 ); return (Nil); } else { Fumble( a, b, c ); return (ToSender); } 5 It is unclear what to do with return. Note, then, that it is operators that cause spaces on the outside of parentheses -- (a + b) * c. 6. General 1. One statement/declaration per line. 2. Make judicious use of blank lines. a. At least 3 blank lines between individual procedures. b. Blank lines surround "large" comments. 3. Make sure comments and code agree! 4. Don't just echo the code with comments -- make every comment count! i.e. nix on: /* add foo to bar */ bar += foo; i Table of Contents 1. Names 1 2. Comments 1 3. Indenting 2 4. File Contents 3 5. Parenthesis () 4 6. General 5 ************************************************************************** ------- Date: 27 Jun 1982 11:48:50-PDT From: mo at LBL-UNIX (Mike O'Dell [system]) To: JSol at USC-ECLC cc: Header-People at MIT-MC Subject: Re: Unexplored Topic -- Length of Mail Message In-reply-to: Your message of 25 Jun 1982 1715-PDT (Friday). Yes indeed mail can be BIG!! If you don't have FTP to some random system (again, not ARPAnet, most likely), but DO have mail, you do a LOT with it, like abuse it into make-do FTP. It is crass, but it beats not getting the bits there! This can often be the case with site 2 networks away in the internet (note small "i"). While this shouldn't impact ARPAnet sites too much, if 733 is indeed something the larger world might look to for guidance, I would advocate JSol's position: Mail is another form of machine-machine communications, complete unto itself. As an example, the "net.sources" news topic on USENET routinely posts fixes and entire source listings of quite complex programs; and this is on a network with 300 or 1200 baud hop-by-hop links!! I am not saying this is the ulitimate solution, or that we should advocate such things, but it does indicate the tremendous utility of Mail in reducing the isolation of sites. -Mike Date: 27 Jun 1982 0929-PDT From: JBROOKSHIRE at USC-ECLB Subject: Re: C programming standards To: mp at MIT-MC In response to your message sent Saturday, 26 June 1982, 23:56-EDT Thanks for the note - if you have any pointers it might help. I have received three pretty good sets of stuff that I am enclosing here if you are interested. They are separated by lines of ******** which you can search on if you just want to read the sources of each. Regards, Jerry Brookshire INGRES CODING CONVENTIONS FOR C/UNIX PROGRAMMING University of California, Berkeley "The Ingres data base system encompasses about 75,000 lines of code in the programming language `C' and runs on top of the Unix operating system. Over the past six years, Ingres has evolved into a functionally complete and usable prototype. Development required 25 to 30 programmer-years by a total of 19 people, and the systems is now in use at over 125 sites around the world." Allman, Eric.; and Stonebreaker, Michael "Observations on the Evolution of a Software System." COMPUTER 15, 6 (June 1982), 27-32. The following represents the current C coding conventions that have evolved from and during the development of the Ingres system. This document has been provided by Joe Kalash of Berkeley <INGVAX.kalash at Berkeley> in response to a general enquiry distributed via Arpanet BBOARDS. /* ** CODE_CNVNTNS.C -- A Program to Display the INGRES Coding Style ** ** This hunk of code does virtually nothing of use. Its main ** purpose is to demonstrate the "official" ingres coding style. ** ** This demonstrates comments. There should be a block comment ** at the beginning of every file and/or procedure to explain ** the function of the code. Important information to put here ** includes the parameters of the routines, any options that the ** user may specify, etc. ** ** The first line of the comment should be a one-line description ** of what's going on. The remainder should be more detailed. ** Blank lines should seperate major points in the comments. In ** general, ask yourself the question, "If I didn't know what this ** code was, what it was for, how it fit in, etc., and if I didn't ** even have the documentation for it, would these comments be ** enough for me?" ** ** Some general guidelines for the code: ** ** ***** GENERAL SYNTAX ***** ** ** - Commas and semicolons should always be followed by a space. ** Binary operators should be surrounded on both sides by ** spaces. Unary operators should be in direct contact ** with the object that they act on, except for "sizeof", ** which should be seperated by one space. ** ** - Two statements should never go on the same line. This includes ** such things as an if and the associated conditionally ** executed statement. ** In cases such as this, the second half of the if ** should be indented one tab stop more than the if. For ** example, use: ** if (cond) ** statement; ** never: ** if (cond) statement; ** or: ** if (cond) ** statement; ** ** - Braces ({}) should (almost) always be on a line by them- ** selves. Exceptions are closing a do, and terminating ** a struct definition or variable initialization. Braces ** should start at the same indent as the statement with ** which they bind, and code inside the braces should be ** indented one stop further. For example, use: ** while (cond) ** { ** code ** } ** and never: ** while (cond) ** { ** code ** } ** or: ** while (cond) { ** code ** } ** or: ** while (cond) ** { ** code ** } ** or anything else in that line. Braces which match ** should always be at the same tab stop. ** ** - Do statements must always be of the form: ** do ** { ** code; ** } while (cond); ** even if "code" is only one line. This is done so that ** it is clear that the "while" is with a do, rather than ** a standalone "while" which is used for the side effects of ** evaluation of the condition. ** ** - There should always be a space following a keyword (i.e., ** for, if, do, while, switch, and return), but never ** between a function and the paren preceeding its ** arguments. For example, use: ** if (i == 0) ** exit(); ** never: ** if(i == 0) ** exit (); ** ** - Every case in a switch statement (including default) should ** be preceeded by a blank line. The actual word "case" or ** "default" should have the indent of the switch statement plus ** two spaces. It should be followed by a space (not a ** tab) and the case constant. Multiple case labels on ** a single block of code should be on seperate lines, but ** they should not be seperated by blank lines. The ** switch statement should in general be used in place of ** such constructs as: if (i == 1) ** code1; ** else if (i == 34) ** code2; ** else if (i == -1643) ** code3; ** which can be more succinctly stated as: ** switch (i) ** { ** case 1: ** code1; ** break; ** ** case 34: ** code2; ** break; ** ** case -1643: ** code3; ** break; ** } ** In point of fact the equivalent switch will compile ** extremely efficiently. (Note that if you had some ** instance where you could not use a case, e.g., checking ** for i < 5, else check for j > 3, else whatever, then ** the above ("if") code is in the correct style. However, ** if (i < 5) ** code1; ** else ** if (j > 3) ** code2; ** else ** code3; ** is acceptable. ** ** - A blank line should seperate the declarations and the code ** in a procedure. Blank lines should also be used freely ** between major subsections of your code. The major ** subsections should also have a block comment giving ** some idea of what is about to occur. ** ** ***** PREPROCESSOR USAGE ***** ** ** - Fields of #defines and #includes should line up. Use: ** # define ARPA 25 ** # define MAXFIELDS 18 ** and not: ** #define ARPA 25 ** #define MAXFIELDS 18 ** Conditional compilation (#ifdef/#endif) should be used ** around all trace information, timing code, and code ** which may vary from version to version of UNIX. See ** the code below for an example of conditional compila- ** tion use. ** ** ***** VARIABLES AND DECLARATIONS ***** ** ** - Defined constants (defined with the # define feature) must ** be entirely upper case. The exceptions to this are ** compilation flags, which begin with a lower case "x", ** and some sub-types for parser symbols. In any case, ** the majority of the symbol is upper case. ** ** - Global variables should begin with an upper case letter and ** be otherwise all lower case. Local symbols should be ** entirely lower case. Procedure names are all lower ** case. The only exception to this is the trace routine ** "tTf". You should avoid user non-local symbols (globals ** or # define'd symbols) which are one character only; ** it is impossible to distinguish them. Capitalization ** may be used freely inside global names so long as they ** are primarily lower case; for example, "ProcName" is ** an acceptable name (and preferred over either Proc_name ** or Procname). ** ** - Use descriptive variable names, particularly for global var- ** iables. "IEH3462" tells me nothing; nor does "R". On ** the other hand, "Resultid" tells me quite a lot, ** including what it might be, where I might go to see ** how it is initialized, etc. Try not to use variables ** for multiple purposes. Variable names like "i" are ** acceptable for loop indices & temporary storage ** provided that the value does not have long-term ** semantic value. ** ** - When the storage structure or type of a variable is ** important, always state it explicitly. In particular, ** include "auto" if you are going to take the address ** of something using the ampersand operator (so that ** some wayward programmer doesn't change it to register), ** and declare int parameters as int instead of letting ** them default. ** ** ***** GENERAL COMMENTS ***** ** ** - It is quite possible to name a file "printr.c" and then ** put the code for "destroydb" in it. Try to arrange ** the names of your files so that given the name of a ** routine, it is fairly easy to figure out which file ** it is in. ** ** - Sometimes it is really pretty much impossible to avoid doing ** something tricky. In these cases, put in a comment ** telling what you are doing and why you are doing it. ** - Try to write things that are clear and safe, rather than ** things which you think are easier to compile. For ** example, always declare temporary buffers as local, ** rather than as global. This way you can another ** routine accidently when it still had useful info ** in it. ** ** ***** COMMENTS ***** ** ** - The importance of comments cannot be overemphasised. ** INGRES is primarily a research vehicle rather than ** a program product. This means that there will be ** many people pouring over your code, trying to ** understand what you have done & modify it to do ** other things. Try to make life easy for them & ** maybe they will be nice to you someday. ** ** - Try to keep an idea of the flow of your program. Put ** block comments at the beginning of major segments, ** and use one-line comments at less major junctures. ** A person viewing your code at ten paces should be ** able to tell where the major segments lay. ** ** - The preferred format for block comments is to begin with ** a line containing slash-star alone, followed by a ** number of lines all beginning star-star containing ** the comment, and terminating with a line containing ** star-slash alone. Comments without the double-star ** at the beginning of each line should be avoided, ** since it makes the comments seemingly disappear into ** the body of the code. ** ** - The beginning of each routine should have a comment block ** in parametric form as demonstrated below. The fields ** "Parameters", "Returns", and "Side Effects" should ** be considered mandatory. Mark parameters as being ** (IN), (IN/OUT), or (OUT) parameters, depending on ** whether the parameter is used only to transmit infor- ** mation into the routine, in and out of the routine, ** or only to return information; the default is (IN). ** ** Remember, it is easy to write totally incomprehensible code in ** C, but we don't go in for that sort of thing. It isn't too ** much harder to write brilliantly clear code, and the code is ** worth a lot more later. ** ** For efficiency reasons, you should always use register variables ** when possible. A simple and extremely effective tip is to define ** a register variable, and assign an oft-used parameter to it, ** since it is particularly inefficient to reference a parameter. ** Another particularly inefficient operation is referencing arrays ** of structures. When possible, define a register pointer to the ** structure, and then say: ** struct xyz structure[MAX]; ** register struct xyz *p; ** ... ** for (i = 0; i < MAX; i++) ** { ** p = &structure[i]; ** p->x = p->y + p->z; ** (diddle with p->???) ** } ** and not: ** struct xyz structure[MAX]; ** ... ** for (i = 0; i < MAX; i++) ** { ** Structure[i].x = Structure[i].y + Structure[i].z; ** (diddle with Structure[i].???) ** } ** Remember, the nice things about register variables is that they ** make your code smaller and they run faster. It is hard to ** lose with registers. There are three restrictions which you ** should be aware of on register variables, however. First, ** The only types which may be registers are int's, char's, ** and pointers. Second, there may only be three register ** variables per subroutine. Third, you may not take the address ** of a register variable (i.e., you may not say "&i" if i is ** typed as a register variable). ** ** Usage: ** example [flags] argument ** ** Positional Parameters: ** argument -- this gets echoed to the standard ** output. ** ** Flags: ** -n -- don't put a newline at the end. ** -x -- don't do anything. ** -b -- echo it with a bell character. ** ** Return Codes: ** 0 -- successful ** else -- failure ** ** Defined Constants: ** XEQ1 -- maximum number of simultaneous equijoins. ** ** Compilation Flags: ** xTRACE -- enable trace information ** ** Trace Flags: ** 5 -- general debug ** 6 -- reserved for future use ** Compilation Instructions: ** cc -n example.c ** mv a.out example ** chmod 755 example ** ** Notes: ** These comments don't apply to the code at all, ** since this is just an example program. ** Also, it is wise to avoid this many comments ** except at the head of main programs and ** at the head of major modules. For example, ** this sort of commenting is appropriate at ** the top of ingres.c (system startup) and ** view.c (virtual view subsystem), but not ** in small utility routines, e.g., length.c. ** This sort of routine should be limited to ** "Parameters:", "Returns:", "Side Effects:", ** and anything else that seems relevant in ** that context. ** A fairly large comment block should exist at the ** top of modules [files] which contain many ** procedures; this block should clarify why ** the procedures are grouped together, that ** is, their common purpose in life. A small ** block should occur at the top of each ** procedure explaining details of that proce- ** dure. ** Procedures should be on seperate pages (use the ** form feed character, control-L). ** A program will help you generate this comment block. ** In ex, go to the line where you want to insert ** a block and say "so /mnt/ingres/comment". It ** will ask you for a block type, e.g., "main" ** for main program, "modfn" for a file which ** contains only one function, "function" or ** "procedure" for a procedure within a module, ** "module" for a module header (e.g., as a ** seperate comment block for a major module ** [check .../qrymod/view.c for an example] or ** in header files. ** SCCS should be considered an essential tool, if only ** to maintain history fields. ** ** Deficiencies: ** It should handle pseudo tty's. */ /* the following macro is defined by <sccs.h> */ SCCSID(%W%); /* %W% is replaced by a version number by SCCS */ # define XEQ1 5 struct magic { char *name; /* name of symbol */ int type; /* type of symbol, defined in symbol.h */ int value; /* optional value. This is actually * the value if it is type "integer", * a pointer to the value if it is a * string. */ }; struct magic Stuff; main(argc, argv) int argc; char *argv[]; { register struct magic *r; register int i; register int j; int timebuf[2]; auto int status; /* ** Note that in the declarations of argc and argv above, all ** parameters to any function should be declared, even if they ** are of type int (which is the default). */ r = &Stuff; /* initialize random # generator */ time(timebuf); srand(timebuf[1]); /* scan Stuff structure */ for (i = 0; i < XEQ1; i++) { # ifdef xTRACE if (tTf(5, 13)) printf("switch on type %d\n", r->reltype); # endif switch (r->type) { case 0: case 1: case 3: /* initialize */ printf("hi\n"); break; case 2: /* end of query */ printf("bye\n"); break; default: /* ** be sure to print plenty of info on an error; ** "syserr("bad reltype");" would not have been ** sufficient. However, don't make syserr's ** overly verbose; they take much space in the ** object module, and it will probably be ** necessary to look at the code anyway. */ syserr("main: bad type %d", r->type); } } /* resist the temptation to say "} else {" */ if (i == 5) { i++; j = 4; } else i--; /* plot the results */ do { i = rand() & 017; plot(i); } while (j--); /* wait for child processes to complete */ wait(&status); /* end of run, print termination message and exit */ for (i = 0; i < 2; i++) printf("bye "); printf("\n"); } ** PLOT -- Plot a Bar-Graph ** ** Does a simple plot on a terminal -- one line's worth. ** ** Parameters: ** n (IN) -- number of asterisks to plot ** ** Returns: ** none ** ** Side Effects: ** none ** ** Deficiencies: ** Should allow scaling. */ plot(n) int n; { register int i; for (i = n; i-- > 0; ) { printf("*"); } printf("\n"); } ************************************************************************** BBN PROGRAMMING STANDARDS FOR C The following document was provided by Dan Franklin <DAN at BBN=UNIX> in response to a general enquiry distributed to Arpanet BBOARDS: Here's a short set of guidelines that represents a combination of the thoughts of two groups within BBN. I was its last editor. Hope you find it useful. If you come across something more comprehensive (which this certainly isn't), I'd appreciate it if you let me know. PROGRAMMING STANDARDS AND PRACTICES FOR THE UNIX COST CENTER This memo proposes a set of practices that might be followed in the cost center, in order to have a consistently organized and written, readable, understandable, and ultimately maintainable software package. Qualifying each of the items below is an (S) or (P): the former indicates that, once agreed-upon, the rule must be adhered to rigorously and consistently--a Standard; the latter items are more of the flavour of "good programming Practice"--once agreed-upon, programmers should follow the practice to the extent that common sense dictates. 1. DOCUMENTATION OF ROUTINE INTERFACES (S) Every routine should be prefaced by a standard header which describes the routine and its interface precisely, so that the routine could be used by someone without reading the code. The rationale for such a header is that it concentrates the critical document- ation in one place, making it easy for someone (including the original designer/coder) to use the routine correctly, and allows for the possibility of automatically stripping off all headers to form an Internal Documentation document. In some cases a routine may do a small amount of processing and then call another routine. (As an example, a routine may provide a "special case" interface to another more general routine with a more cumbersome calling sequence.) In this case, a routine's header may refer the reader to the header of another routine for further information. The format suggested is illustrated below: comments are surrounded by < > symbols. Any item that is irrelevant, e.g., no parameters, no return value, no error conditions, may be omitted. /*------------------------ E P R I N T -----------------------------------*/ /* <a brief description of the routine...also, put the routine name in * caps in the line above. The description should give, in general * terms, the routine's function, including an overall description of its * parameters, return values, and effect on global databases. It should also * describe any error conditions that may occur and be reflected to the * caller. The return value must be described precisely.> */ int eprint(estrucp, istart, ilength) struct estruct *estructp; /* Pointer to eprint's structure */ int istart; /* Place in structure to start from */ int ilength; /* # things in struct to print */ { } Note that each parameter gets its own declaration line, and has a comment to convey its exact meaning. Each file in a program or subsystem consisting of multiple files should start with some additional information, giving (essentially) the justification for putting all these routines in one file. That is, it should include a description of the common function they all perform, the related functions they all perform, the database they have in common and which is contained only in this file, etc. In the last case, especially, a detailed description of the database should be included; otherwise, since the database is not part of any one routine, it will not get described in any other comment field. The detailed description may require reading comments associated with the actual declarations in order to be complete. This header should include a history list describing all modifications to functions in this file. Each entry in the list should give the person, the date, the names of the functions (or database elements) changed, and the reasons. For the file containing the main routine of a program, the following standards should be observed: 1. The main routine should be the first routine in the file. 2. Before the main routine should appear an overall comment field describing the calling sequence in some detail. Generally, the program will also be described in a manual page as well; this comment field need not duplicate the entire contents of the manual page, but it should include information about the overall structure of the program which would be useful to a maintainer. 3. The main routine should exit by calling exit(0) explicitly. All programs, however, must return an exit status of zero on success, and nonzero on error. 2. FORMATTING (S) All programs must be indented, at least 4 spaces per indentation level. Statements at the same nesting level should be at the same indentation level; statements at deeper nesting levels should be indented more. (For the purposes of this standard, the keyword "else" is regarded as having the same nesting level as the "if" it corresponds to.) For example, the following indentation practices are not permitted: if (condition) statement-group; if (condition) statement-group; else statement-group; if (condition) for (init; test; step) statement-group; if (condition) statement-group; else statement group; (S) Nesting the trinary conditional operator (?:) is not permitted. (P) For internal formatting and indenting style, the following is recommended: . 4-space indentations at each level; . braces delineating blocks used in the style of if (exp) { code } or if (exp) { code } . a separate declaration statement for each pointer, due to the confusion that can arise when reading and modifying a declaration like char *a, b, *c; . comments lined up systematically; . spaces between reserved words and their opening parentheses, e.g., if (condition) rather than if(condition); . no deep nesting (greater than 4 levels deep) . statement blocks less than 1 page long . one statement per line . parentheses around the objects of sizeof and return. (P) Concerning internal comments: . Full English sentences are recommended. . It is often clearer and more readable to make small blocks of comments as "paragraph headers" to a block of code than to comment every line or so, especially if the code is straightforward and untricky (which most of it should be, especially if the programmer is conscientious about variable naming and datatype compatibility). . Anything non-obvious should be well-commented. (P) Concerning white space and other aids to readability and debugging: . blank lines should be used between blocks of code that are functionally distinct . in expressions, operators should be surrounded by blanks (but not operators which compose primaries, specifically ".", "->") . in a function definition, the function name and its datatype should appear on one line. Examples: int pread(...) SOMESTRUCT * function(param1, param2) This latter practice aids readability and the comparison of the definition of a routine with its uses. (P) Other suggestions for improving readability: . Side effects within expressions should be used sparingly. It is recommended that no more than one operator with a side effect (=, op=, ++, --) appear within an expression. Function calls with side effects count as operators for this purpose. . In an "if-else" chain, the form if (condition) statement; else if (condition) statement; else if (condition) statement; should only be used when the conditions are all of the same basic form: e.g., testing the same variable against different values. If the conditions are qualitatively different, the additional "if" statements should start on new lines, indented, as in if (cond) statement; else if (cond2) statement; else statement; . In the condition portion of an if, for, while, etc., side effects whose effect extends beyond the extent of the guarded statement block should be minimized. That is, in a block like if ((c = getc(file)) != EOF) { guarded-stmts } other-stmts it is natural to think of "c" being "bound" to a value only within the guarded-stmts; use of a variable set or modified in a condition, outside the range of the statements guarded by the condition, is quite distracting. . The use of || and && with right hand operands having side effects is discouraged. Also, whenever || and && are mixed in the same expression, parentheses should be used for clarity. 3. MODULARITY 3.1. Routine Length (P) Routines should be kept reasonably short. In general, a routine (or command) processes one or more inputs and generates one or more outputs, where each of the inputs and outputs can be concisely described. Usually a routine should only perform one function. Signs that a routine is too long, and ought to be split up, are: length greater than two pages; heavy use of "internal" variables (variables whose scope is less than the entire routine). 3.2. Shared Data and Include Files (S) Declarations of variables that are to be shared among several routines in a package should be placed at the beginning of the file containing the routines. If they are entirely internal to the package, they should be declared "static" to hide them from other files. (S) Declarations of structures and global variables used for communications between a package and its callers should be placed in an appropriately named .h file. Shared global variables should be declared extern in the .h file so that if the package which sets/uses them is accidentally not loaded, a diagnostic will be issued by the loader. (S) Definition and optional initialization of such globals should reside in one and only one file for each program. If a global is clearly associated with a specific package, it may be defined in the file for that package; otherwise, it should be placed in a file called data.c which is compiled and linked with the other routines when a program is being built. (P) Use of globals should be minimized by judicious use of parameters. Note that while static and extern designators in C both yield "common" storage allocation, static allows the named variable to be known only within the context in which it is declared; thus, an identifier declared static at the top of a file will only be known within the file. In addition, local symbolic constants (#defines) may occur anywhere within a routine, and may be placed below the #include directives if the writer feels that this aids readability. (S) Include files should contain all and only all of the following items necessary for a given program and shared among two or more of its files: . #defines . typedefs . extern declarations (S) Include files may also contain nested #include directives. However, this practice should be kept to a minimum. It is recommended that include files which may be embedded in this way contain a check to see whether they are being included twice, to avoid unnecessary preprocessor and compiler complaints when the user includes them both implicitly and explicitly. The simplest way to do this is to check for a special hidden #define, as in #ifdef _INCLUDEFILENAME #define _INCLUDEFILENAME . . Contents of include file . #endif _INCLUDEFILENAME 3.3 Routine interfaces (P) In general, a routine should be designed with a "natural", easily-remembered calling sequence. Routines with more than five arguments are not recommended. Routines with "op-code" arguments, where one argument determines the interpretation and functions of the others, are also not recommended (though they may prove useful as internal routines to a package, they should NOT be part of a package's documented interface). 4. PORTABILITY (P) Adherence to datatype compatibility should be practiced where reasonable. This can be facilitated by liberal use of C's typedef facility and explicit casting of types, as well as by the use of the union datatype. (P) The following violation of strict adherence is permitted: a package which returns a pointer to a structure whose format need not be known outside that package may return a "generic" pointer, of type (char *). It is recommended that the typedef PTR be used for this purpose; this typedef will be provided in some standard system file. Note that char* is specifically chosen because the language guarantees that any pointer may be converted to a char* and back again without harm. (S) Liberal use of #defines should eliminate "magic numbers", whether machine dependent or implementation dependent or arbitrary/random. (S) To the extent that the conditional compilation facility of C allows, non- portable constructions can use this facility. Failing this, machine or implementation dependent constructs should be visibly commented in the code. When using conditional compilation for portability purposes, be sure to use appropriate parameters, rather than machine type, wherever possible. For example, code which handles the C machine's 20 bit wordsize or 10 bit bytesize should use the parameter BYTESIZE in cpu.h rather than being ifdeffed on "mbb". (P) Up to six register variables can be declared (with some effect) on the C70 machine, but only three on the 11/70 (where additional ones are assigned regular automatic storage). Therefore, the first three register variables declared (in lexicographic order) should be ones for which the most gain can be gotten. Note that register variables, judiciously chosen, can be very good space/time savers, but the compiler is not overly smart about them, and can give you irritating "expression overflow" messages. In general, as with any "optimization", it is wise to design, code and debug first, and then add in register storage to one's declarations. 5. NAMING (P) Names should be chosen for their mnemonic nature. Recall that although there is a limit on the number of initial characters of a name that must be distinct in C (and for a given machine), this does not prevent any name from being longer if such length will aid readability. (S) It is a useful C convention to use upper-case for #defines and typedef names. (S) One exception to the above is for parameterized #defines. These may be in lower-case. ************************************************************************** The following was provided via FTP by Keith A. Lantz at Stanford <CSL.LANTZ at SU-SCORE> via FTP following the enquiry distributed via Arpanet BBOARDS. 1 NETWORK GRAPHICS C STYLE SHEET Andrew Shore, et al. Computer Systems Laboratory Stanford University Stanford, CA 94305 18 June 1982 1. Names Don't use capital letters in file names (except for V !?). Avoid the underscore. Global variables, procedures, structs, unions, typedefs, defined constants, and macros all begin with a capital letter, and are logically capitalized thereafter (e.g. MainHashTable). A global variable is one defined outside a procedure, even though it may not be exported from the file, or an external variable. The motivation for treating macros and constants this way is that they may then be freely changed to procedure calls or (global or external) variables. Local variables begin with a lower-case letter, but are logically capitalized thereafter (e.g. bltWidth, power, maxSumOfSquares). Fields within structures or unions are treated in this manner also. 2. Comments There are generally two types of comments: block-style comments, and on-the- line comments. Multi-line, block-style comments will follow the UNIX style of /* and */ appearing on lines by themselves, and the body of the comment will start with a properly aligned *. The comment should usually be surrounded by blank lines as well. The motivation for this is that it is easy to add/delete first and last lines, and it is easier to detect the common error of omitting the */ and thus including all code up to and including the next */ in a comment (Yapp helps with that too). /* * this is the first line of a multi-line comment, * this is another line * the last line of text */ On-line comments are used to detail declarations, and to explain single lines of code. And, I suppose, for brief (i.e. one line) block-style descriptive comments. 1 This work was supported by the Defense Advanced Research Projects Agency under contract number MDA903-80-C-0102. 2 Procedures are preceded by block-style comments, explaining their (abstract) function in terms of their parameters, results, and side effects. Note that the parameter declarations are indented, not flushed left. /* * Unblock: * unblock the process pd */ Unblock( pd ) register Process pd; /* the process to unblock */ { register Process *currPd, *tmpPd; register unsigned prio; prio = pd->priority; Disable; pd->state = Ready; /* Add pd to the ready queue */ currPd = (Process *) &ReadyqHead; while ((tmpPd = currPd->link) != Null) { if (tmpPd->priority > prio) break; currPd = tmpPd; } pd->link = tempPd; currPd->link = pd; Enable; } 3. Indenting The above example shows many of the indenting rules. Braces ( "{" and "}" ) appear alone on a line, and are indented two spaces from the statement they are to contain the body of, the body is indented two more spaces from the braces (for a total of four spaces). else's and else if's line up with their dominating if statement (to avoid marching off to the right, and to reflect the semantics of the statement). 3 if ((x = y) == 0) { flag = 1; printf (" the value was zero "); } else if (y == 1) { switch (today) { case Thursday: flag = 2; ThursdayAction(); break; case Friday: flag = 3; FridayAction(); break; default: OtherDayAction(); } } else printf(" y had the wrong value "); 4. File Contents I think we agreed on the following order for file contents. 1. initial descriptive comment (see example below) which contains: a. file name, with indication of the relative path to it when relevant b. brief descriptive abstract of contents c. a list of all defined procedures in their defined order d. list of authors e. list of current maintainers f. list of recent and major modifications in reverse chronological order with indication (initials) of who made the change. 2. included files (use relative path names whenever possible) 3. external definitions (imports and exports) 4. function declarations (externals and forward references) 4 5. constant declarations 6. macro definitions 7. type definitions 8. global variable declarations 9. procedure and function definitions Here is an example of the header comment: /* * FILE: libc/vkstuff/malloc.c * * CONTENTS: * C storage allocator stolen and hacked up from UNIX for the SUN * (NOTE: these were stolen and have the wrong naming conventions) * malloc * free * realloc * allock DEBUG ONLY! * SetBrk ! our routine to fake up sbrk() * * AUTHORS: stolen and hacked by Andrew I. Shore (shore) * * MAINTAINER: shore * * HISTORY: * 03/05/82 AIS replaced calls to UNIX sbrk() with calls to own version * SetBrk() for the sun/Vkernel */ 5. Parenthesis () We seem to have decided on the following conventions for parentheses. When parentheses enclose the expression for a statement (if, for, etc.), the parentheses `belong to' the expression, so there is a space between the keyword and the parenthesized expression. For function calls the parentheses `belong to' the call, so there is no space between function name and open paren (there may some inside the parentheses to make the expression list (argument list) look nice). if (Mumble()) { Grumble( (a = b) == 0 ); return (Nil); } else { Fumble( a, b, c ); return (ToSender); } 5 It is unclear what to do with return. Note, then, that it is operators that cause spaces on the outside of parentheses -- (a + b) * c. 6. General 1. One statement/declaration per line. 2. Make judicious use of blank lines. a. At least 3 blank lines between individual procedures. b. Blank lines surround "large" comments. 3. Make sure comments and code agree! 4. Don't just echo the code with comments -- make every comment count! i.e. nix on: /* add foo to bar */ bar += foo; i Table of Contents 1. Names 1 2. Comments 1 3. Indenting 2 4. File Contents 3 5. Parenthesis () 4 6. General 5 **************************************************************************

22 years, 9 months

1
0
0 0

Re: [TUHS] Can someone advise me regarding a gui for UNIX

by A.P.Garcia

> Can someone advise me regarding when the GUIs became a standard feature on > UNIX? Or operating systems whose ancestry was indeed UNIX? MIT/LCS/TR-368, _The X Window System_, by Scheifler and Gettys, is dated October 1986. Here are a couple paragraphs from the introduction: X is the result of the simultaneous need for a window system from two separate groups at MIT. In the summer of 1984, the Argus system [15] at the Laboratory for Computer Science needed a debugging environment for multi-process distributed applications, and a window system seemed the only viable solution. Project Athena [4] was faced with dozens, and eventually thousands of workstations with bitmap displays, and needed a window system to make the display useful. Both groups were starting with the Digital VS100 display [13] and VAX hardware, but it was clear at the outset that other architectures and displays had to be supported. In particular, IBM workstations with bitmap displays of unknown type were expected eventually within Project Athena. Portability was therefore a goal from the start. Although all of the initial implementation work was for Berkeley Unix, it was clear that the network protocol should not depend on aspects of the operating system. The name X derives from the lineage of the system. At Stanford University, Paul Asente and Brian Reid had begun work on the W window system [3], as an alternative to VGTS [12, 21] for the V system [5]. Both VGTS and W allow network-transparent access to the display, using the synchronous V communication mechanism. Both systems provide "text" windows for ASCII terminal emulation. VGTS provides graphics windows driven by fairly high-level object definitions from a structured display file; W provides graphics windows based on a simple display-list mechanism, with limited functionality. We acquired a Unix-based version of W for the VS100 (with synchronous communication over TCP [23]) done by Asente and Chris Kent at Digital's Western Research Laboratory. From just a few days of experimentation, it was clear that a network- transparent hierarchical window system was desirable, but that restricting the system to any fixed set of application-specific modes was completely inadequate. It was also clear that, although synchronous communication was perhaps acceptable in the V system (due to very fast networking primitives), it was completely inadequate in most other operating environments. X is our "reaction" to W. The X window hierarchy comes directly from W, although numerous systems have been built with hierarchy in at least some form [10, 14, 17, 27, 30, 31, 32, 33, 34, 35]. The asynchronous communication protocol used in X is a significant improvement over the synchronous protocol used in W, but is very similar to that used in Andrew [9, 19]. X differs from all of these systems in the degree to which both graphics functions and "system" functions are pushed back (across the network) as application functions, and in the ability to transparently tailor desktop management. 3. Asente. P. W Reference Manual. Stanford University, 1984. internal document. 4. Balkovich, E., Lerman, S., and Parmelee, R. "Computing in Higher Education: The Athena Experience". _Communications of the ACM 28_, 11 (Nov. 1985). 5. Cheriton, D. "The V Kernel: A Software Base for Distributed Systems". _IEEE Software 1_, 2 (April 1984). 9. Gosling, J. and Rosenthal, D. A Window-Manager for Bitmapped Displays and Unix. In _Methodology of Window-Managers_, F.R.A. Hopgood et al, Eds., Springer-Verlag, 1986. 10. Hawley, M. J., and Leffler, S. J. Windows for Unix at Lucasfilm. Summer Conference Proceedings, Portland, USENIX Association, 1985. 12. Lantz, K.A. and Nowicki, W.I. "Structured Graphics for Distributed Systems". _ACM Transactions on Graphics 3_, 1 (Jan. 1984). 13. Levy, H. "VAXstation: A General-Purpose Raster Graphics Architecture". _ACM Transactions on Graphics 3_, 1 (Jan. 1984). 14. Lipkie, D.E., Evans, S.R., Newlin, J.K., and Weissman, R.L. "Star Graphics: An Object-Oriented Implementation." _Computer Graphics 16_, 3 (July 1982). 15. Liskov, B. and Scheifler, R. "Guardians and Actions: Linquistic Support for Robust, Distributed Programs". _ACM Transactions on Programming Languages and Systems 5_, 3 (July 1983). 17. _Microsoft Windows: Programmer's Guide_. Microsoft Corporation, 1985. 19. Morris, J., et atl. "Andrew: A Distributed Personal Computing Environment". _Communications of the ACM 29_, 3 (March 1986). 21. Nowicki, W. _Partitioning of Function in a Distributed Graphics System_. Ph.D. Th., Stanford University, Stanford, CA, 1985. 23. Postel, J. Transmission Control Protocol. RFC 793, USC/Information Sciences Institute, Sept. 1981. 27. Stallman, R., Moon, D., and Weinreb, D. Lisp Machine Window System Manual. MIT Artificial Intelligence Laboratory, Aug., 1983. 30. _Programmer's Reference Manual for SunWindows_. Sun Microsystems, Inc., 1985. 31. Sweet, R. "Mesa Programming Environment". _ACM SIGPLAN Notices 20_, 7 (July 1985). 32. Sweetman, D. A Modular Window System for Unix. In _Methodology of Window-Managers_, F.R.A. Hopgood et al, Eds., Springer-Verlag, 1986. 33. _Programming the User Interface_. Symbolics, Inc., 1986. 34. Teitelman, W. The Cedar Programming Environment: A Midterm Report and Examination. CSL-83-11, Xerox PARC, June, 1984. 35. Trammel, R.D. A Capability Based Hierarchic Architecture for Unix Window Management. Summer Conference Proceedings, Portland, USENIX Association, 1985. two other references, not mentioned in the above text, that are worth noting: 11. _Information Processing: Graphical Kernel System (GKS) - Functional Description_. DIS 7942, International Standards Organization, 1982. 22. Pike, R. "The Blit: A Multiplexed Graphics Terminal". _AT&T Bell Laboratories Technical Journal 63_, 8 (Oct. 1984).

22 years, 9 months

1
0
0 0

[pups] Can someone advise me regarding a gui for UNIX

by Gregg C Levine

Hello from Gregg C Levine Cross posted to both TUH, and PUPS lists, apologies to all. Can someone advise me regarding when the GUIs became a standard feature on UNIX? Or operating systems whose ancestry was indeed UNIX? I know that with Linux, for example started carrying one, about the same time the kernel became capable of supporting it. Or at least that's my opinion. With regard to the materials we discuss here, well, that's what I am attempting to ascertain. Gregg C Levine drwho8(a)worldnet.att.net "Oh my!" The Second Doctor's nearly favorite phrase.

22 years, 9 months

3
2
0 0

E11 later versions and available boot images

by Gregg C Levine

Hello from Gregg C Levine Has anyone tried out the boot images, in that directory on E11 ver 3.1? It happens that I can get it to work, under Bochs, that is, I can run E11, there. I haven't as yet, tried any of the boot images, myself. Right now I'm downloading the ones that I am interested in. Gregg C Levine drwho8(a)worldnet.att.net "Oh my!" The Second Doctor's nearly favorite phrase.

22 years, 9 months

1
0
0 0

[pups] Interdata 3220 backup tape found... worth recovering for archives?

by Robertdkeys＠aol.com

I chanced upon some old V7 stuff today, from a researcher at the Duke University Medical Center that did not have the heart to just throw them out. There was a complete manual set for V7 from a Perkin-Elmer NMR machine dating from 1984, and a backup tape of the system (9 track Scotch 700 series 6250bpi) dated 12/17/80. The machine was apparently an Interdata 3220 (Perkin-Elmer was supposed to have bought out Interdata). The manuals will make for fun reading, but there may be some worthwhile bits if the tape is OK. Anyway, I am seriously thinking of trying to read the contents of the tape, and pass them on to Warren, for the archives, if he thinks that is something to do. As to reading the tape, with the highest chance for successful recovery, what would the list folks recommend. I was thinking of just doing a retension on the tape to wind it off the reel and prevent sticking, and then maybe use the copytape ditty that has been floating around the net since time began, which should list file sizes, block sizes, file types, etc., while reading the files to disk. I can roll the tape on a VAX or a Sparc system using a Cipher M995S deck. Any suggestions from the list? Thanks Bob Keys robertdkeys(a)aol.com

22 years, 9 months

1
0
0 0

[pups] Req help rebuilding v7 rl2unix with dz driver added

by Richard L. Hamilton

(running under simh V2.9-11) I wanted to add the dz driver for multi-"terminal" support. But I'm a bit stumped figuring out how to rebuild rl2unix, let alone how to add the dz driver. (no rlconf/rl2conf file, although mkconf.c looks like maybe it knows about the rl2 if not about the dz) Is this do-able? Is the dz driver in the v7 image usable? -- mailto:rlhamil@mindwarp.smart.net http://www.smart.net/~rlhamil

22 years, 9 months

1
0
0 0

Re: [TUHS] Re: Making boot disks

by pete＠dunnington.u-net.com

On Oct 1, 10:16, Ian Molton wrote: > On Tue, 1 Oct 2002 06:29:56 GMT > pete(a)dunnington.u-net.com (Pete Turnbull) wrote: > > It is indeed a straight port of BSD 4.x, where x depends in whether is > > it's RISC iX 1 or 1.2 (R440 used 4.2, I think; R260 used 4.3). > > was the only difference between 1 and 1.2 the kernel? I think other things were updated as well, in line with differenet versions of BSD, but I don't have any sort of definitive list. > > Take a look at James Carter's page at > > http://www.jfc.org.uk/documents/riscix_clone.html > > wont I need a working installation first? To clone a disk, yes, you need to start with a good disk :-) > > > is it possible for someone else to make a filesystem image for me > > > that I could dd onto a floppy? I suspect that this system uses an > > > old variant of ufs. > > > > It is a standard 4.3 filesystem (at least for the verison for an > > R260). It even says so when it boots: > > Thats good to know - linux can actually write to that (although attempts > so far have led to kernel panics!) > > Do you know of generic source for mkfs ? Linux source, especially early versions, or a full BSD 4.x distribution, eg from the PUPS archive? > > One of us could copy some stuff for you. I'm not sure you'd be able > > to get what you need onto a single floppy, though. That's not how > > Acorn did it. > > did you see the scripts I attached? > > Apparently the create 3 floppies, which can be used to install a system. I've looked at the scripts (sorry, didn't have time yesterday). They're not Acorn's. They were created by Granada Microcare's Field Service division when they had to upgrade R140 versions of RISC iX -- 1.13 was a bugfix release. They should work, providing the versions of the kernel and other files in my version will fit on a floppy. I'm not sure how best to get your tar file back though; it doesn't look like the minimal system has NFS support. You ought be able to do it if you had a spare hard drive, put the tar file on it, and mount it under /mnt. Modify the tar command in cpsys so it doesn't overwrite /mnt, like James and I did. dsplit is just a utility (written by Acorn?) to split a big file over several floppies, or extract it again (like bsplit, but probably with different markers). > can risciX do loopback mounted filesystems?) No. That's a linux invention. But I can probably create the floppies for you, when I have time to move my R260 to somewhere I can use it -- probably not this weekend, maybe the weekend after. What machine have you got? R140, R260, or something else? Is it the same type as the filesystem you copied came from? -- Pete Peter Turnbull Network Manager University of York

22 years, 9 months

1
0
0 0

Re: [TUHS] Re: Making boot disks

by Christian Groessler

On 10/01/2002 01:37:54 AM CET Ian Molton wrote: > >On Tue, 1 Oct 2002 09:29:02 +0930 >"Greg 'groggy' Lehey" <grog(a)lemis.com> wrote: > >> Well, it would be nice to know what you're really trying to do. >> What's the hardware? If the file system is UFS, it's unlikely to be a >> good fit for Linux. I'd say "try FreeBSD", but without knowing more >> about your software and hardware, it's not clear if that would be any >> better. Google suggests that it runs on ARMs. Is that correct? > >The hardware is an obscure british platform from back when the ARM was >young. - The Archimedes. > >The CPU is the ARM2 or 3 (either work) and the systems have SCSI, >ethernet, and (up to) 16Mb of RAM. I think NetBSD supports these machines. See http://www.netbsd.org/Ports/acorn26/ regards, chris

22 years, 9 months

3
2
0 0

Re: [TUHS] Re: Making boot disks

by pete＠dunnington.u-net.com

On Oct 1, 1:37, Ian Molton wrote: > > On Tue, 1 Oct 2002 09:29:02 +0930 > "Greg 'groggy' Lehey" <grog(a)lemis.com> wrote: > > > Well, it would be nice to know what you're really trying to do. > > What's the hardware? If the file system is UFS, it's unlikely to be a > > good fit for Linux. I'd say "try FreeBSD", but without knowing more > > about your software and hardware, it's not clear if that would be any > > better. Google suggests that it runs on ARMs. Is that correct? > > The hardware is an obscure british platform from back when the ARM was > young. - The Archimedes. > > The CPU is the ARM2 or 3 (either work) and the systems have SCSI, > ethernet, and (up to) 16Mb of RAM. > > I dont actually know what the filesystem is, but my guess is UFS based > on the newfs command in the mkkernel script, and a rumour it is BSD > derived. It is indeed a straight port of BSD 4.x, where x depends in whether is it's RISC iX 1 or 1.2 (R440 used 4.2, I think; R260 used 4.3). > I have everything from a machines filesystem in a tarball. > > I simply have no bootdisk, and cant create one without a suitable newfs > > > > any advice from the list would be appreciated :) Take a look at James Carter's page at http://www.jfc.org.uk/documents/riscix_clone.html James and I worked this out when we rescued half-a-dozen R260's in various states of disrepair and with various not-quite-complete copies of RISC iX. > is it possible for someone else to make a filesystem image for me that I > could dd onto a floppy? I suspect that this system uses an old variant > of ufs. It is a standard 4.3 filesystem (at least for the verison for an R260). It even says so when it boots: RISC iX Release 1.2 ARM3 processor, cache enabled ... ... Root fstype 4.3, name /dev/sd0a Swap fstype spec, name /dev/sd0S ... One of us could copy some stuff for you. I'm not sure you'd be able to get what you need onto a single floppy, though. That's not how Acorn did it. We'd certainly be willing to help, especially if you have any RISC iX stuff we're missing. -- Pete Peter Turnbull Network Manager University of York

22 years, 9 months

2
1
0 0

[pups] Re: minnie.tuhs.org mailing list memberships reminder

by Richard Snow

now that i've signed up for this list I have forgotten what the topic is? I am a disabled veteran, I do some work with Linux as a hobby, and some web sites, also as a hobby. I may be getting a Vaxstation soon. I don't think is one of the ones supported by Linux yet. Richard Snow

22 years, 9 months

4
3
0 0

Re: Making boot disks (fwd)

by Warren Toomey

----- Forwarded message from Ian Molton ----- >From spyro(a)f2s.com Tue Oct 1 09:02:24 2002 Date: Tue, 1 Oct 2002 00:15:35 +0100 From: Ian Molton <spyro(a)f2s.com> To: wkt(a)tuhs.org Subject: Re: Making boot disks On Tue, 1 Oct 2002 07:37:35 +1000 (EST) Warren Toomey <wkt(a)minnie.tuhs.org> wrote: > I'll pass this to the mailing list to see if others can help you. > I'd say that Linux is unlikely to construct the correct filesystem > type. There are severl UFS variants, and you'd need to know the exact > layout details to be sure that Linux (or something else) could create > the boot disks. Thanks. I found some ufs code in the HURD source, and VERY crudely hacked it. It creates filesystems that linux can mount, but it crashed trying to write big files to it (doh!) any advice from the list would be appreciated :) ----- End of forwarded message from Ian Molton -----

22 years, 9 months

3
2
0 0

Re: Making boot disks

by Warren Toomey

In article by Ian Molton: > Hi. > > Dunno if you can help me ont this... > > I have an unusual UNIX derived OS called RISCiX, but I cant install it > because I have no bootdisks. > > I /do/ have scripts to make them, and the kernel + OS files, though. > > I think the filesystem was UFS. > > I can use my Linux box to create a filesystem, but I dont have a copy of > the right utility (newfs?). > > Can you point me to source? I'll pass this to the mailing list to see if others can help you. I'd say that Linux is unlikely to construct the correct filesystem type. There are severl UFS variants, and you'd need to know the exact layout details to be sure that Linux (or something else) could create the boot disks. Warren

22 years, 9 months

1
0
0 0

[pups] Re: v7 crypt(3)

by Dennis Ritchie

Following up Toomey's and Davidson's notes (didn't see Garcia's): It does appear that the early-distributed v7 didn't require = in initializers. A slightly later version of the original 11 C compiler did; the lines Davidson quoted, if (o!=ASSIGN) peeksym = o; were replaced by if (o!=ASSIGN) { error("Declaration syntax"); peeksym = o; } bringing it into conformity with K&R1, which did require the =. Incidentally, if anyone wants to try the v7 crypt(3), the 'encrypt' routine has an implicit, and unwarranted, assumption that the L and R arrays are adjacent in storage and thus that L can be oversubscripted to access R. This was fixed at some (surprisingly late) point too. Dennis

22 years, 9 months

1
0
0 0

[pups] Installing BSD on 11/44 without tapedrive ?

by huglhuglhugl＠gmx.net

Hello, My PDP11/44 is currently running RSX11M but since I lack experience and documentation of RSX, I'd like to install a BSD-Unix. I suppose I can install 2.11BSD or 2.9BSD on a 11/44. Which one should I choose ? I do allready have 2.11 on my 11/93, so I might want to try 2.9BSD if this is not asking for trouble. I do have 1Mb of ram, two RL02 drives (and some disks, so I can always keep RSX), FPU, Ethernet. But I don't have a tapedrive! I thought I could write the RL02 disks on my 11/93 and then put them in my 11/44. Will this work ? Is there something special I need to know ? Regards, --lothar -- Werden Sie mit uns zum "OnlineStar 2002"! Jetzt GMX wählen - und tolle Preise absahnen! http://www.onlinestar.de

22 years, 9 months

1
0
0 0

[pups] Re: v7 crypt(3)

by Warren Toomey

In article by A. P. Garcia: > Warren, > > I've been looking at the Henry_Spencer_v7 tar, and something > is puzzling me. lines 49-54 of /usr/src/libc/gen/crypt.c are > the following: > > static char PC1_D[] { > 63,55,47,39,31,23,15, > 7,62,54,46,38,30,22, > 14, 6,61,53,45,37,29, > 21,13, 5,28,20,12, 4, > }; > > That wasn't legal syntax, was it? There should be an '=' > between [] and {, as in the rest of the file, no? I just tried to compile the code with the V7 compiler and it complained. Maybe it was legal in V6 and they used the .o file from there and didn't recompile it. I think Dennis is on the list, maybe he can answer the intruiging question! > Btw, it's neat to look at this code alongside the DES standard: > http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf > Phil Garcia Yes, it certainly is. Thanks Phil. Warren

22 years, 9 months

2
1
0 0

[pups] Unix and PDP11/20 (was PDP9?)

by Dennis Ritchie

As Billquist, Wilson and others pointed out, the first versions of Unix did run on machines with no memory mapping or protection, and indeed context-switching was accomplished by swapping. By 1973 we had the luxurious 11/45, to considerable relief. I'm not positive about the logo on our first PDP-11. On the earliest handbook I have, the front panel photo just shows "PDP11", though inside the handbook it does talk about the two models (11/10 and 11/20). Both had the same KA11 processor, but the basic 11/10 sported 1024Kw ROM memory plus a generous 128 words of RAM, while the 11-20 had 4096Kw core RAM, and the ASR33 Teletype was included. You could add more RAM to the 11/20. Incidentally, the machine's handbook was a wonder. In 104 pages (each 5.25x8 inches), it described the whole system: not only the instruction set but the theory of the Unibus (including some logic diagrams) together with programming specifications for the TTY, the clock, and the paper tape reader. Dennis

22 years, 10 months

3
2
0 0

Re: [pups] BSD 2.11 on an 11/73 + RD54

by Steven M. Schultz

Hi - A few days ago the "getty plays parity games" topic came up again. I've been thinking about it and looked at the kernel a bit more. 7e1 is rather firmly in place and I'm not sure turning the 'console' (kl/dl) driver into a "LITOUT only" one is a 100% correct way to go (the other drivers such as dz, dh, etc remain 7e1 output by default). Here's a patch for getty/main.c which I think will do what's wanted without having to modify the kernel: ------------snip------------- *** main.c.dist Mon Sep 9 16:52:24 2002 --- main.c Mon Sep 9 16:56:55 2002 *************** *** 384,391 **** c = cc; c |= partab[c&0177] & 0200; ! if (OP) ! c ^= 0200; if (!UB) { outbuf[obufcnt++] = c; if (obufcnt >= OBUFSIZ) --- 384,401 ---- c = cc; c |= partab[c&0177] & 0200; ! /* ! * If "any" parity do nothing otherwise set even parity unless OP is ! * set. Since 'ap' is set in the "default" entry of /etc/gettytab this ! * has the effect of disabling parity on output without having to change ! * the kernel. ! */ ! if (!AP) { ! c |= partab[c & 0177] & 0200; ! if (OP) ! c ^= 0200; ! } ! if (!UB) { outbuf[obufcnt++] = c; if (obufcnt >= OBUFSIZ) --------------snip--------------- What this does is check the "AP" (AnyParity) flag from /etc/gettytab and if NOT set then do the 'even' (or 'odd' if OP is set) parity. Since 'ap' is present in the default line of /etc/gettytab the above block effectively becomes a no-op unless /etc/gettytab is explicitly set for 'ep' or 'op'. If someone could test this and report back I'd appreciate it. Thanks. Steven Schultz sms(a)2bsd.com

22 years, 10 months

1
0
0 0

[pups] Bringing up the fist C compiler

by Tim Bradshaw

Is there a description anywhere of how C was originally bootstrapped? I'm sure it was nothing unconventional, but the question of how you bring up compilers for other languages which are implemented in their own language seems to mystify some people to the extent that they argue that the compiler must be written in C (which is `always there'), and I thought it would be good to have the real story about C to tell them. Thanks --tim

22 years, 10 months

7
9
0 0

RE: [pups] BSD 2.11 on an 11/73 + RD54

by Fred N. van Kempen

Hi, > Currently when I boot, I start off with my terminal set to 19,200 baud > 8-N-1 but once BSD has booted I have to switch to 19,200 7-E-1 The hardware runs on 8-bit clean channels. Most UNIX kernels kinda prefer to use 7e1 or 7o1. > Can anyone tell me why this is happening and how I fix it so > the setting remains on 8-N-1? (stty?) Once you're logged in to the system, type "stty -parenb bits8" or "stty -parenb cs8" or "stty -parenb 8" to go back to 8-bit mode. Then reset your terminal program again :) > Also, if I can't fix this, will vtserver/vtc run on 7-E-1 comms? Nope. VTc requires an 8-bit clean channel (for now). --fred

22 years, 10 months

2
1
0 0

Re: [pups] Unix and PDP11/20 (was PDP9?)

by John Holden

> Dennis Ritchie wrote:- > > Early on, for fun, we tried assembling the DEC-supplied > assembler, which came on at least one (maybe more) long > fan-folded paper tapes. I don't think we ever succeeded; it had to > be fed in twice for the two passes, and enough characters > were dropped that phase errors occurred. The early high speed tape readers used the clock pulse off the stepper motor (with suitable delay) to strobe the data from the photo-transistors. It was somewhat unreliable. Latter models added a ninth detector under the sprocket holes, which being smaller, neatly strobed the data in the middle of the punched data. The 11/20 I first used only had the paper tape software. The pdp-11 instruction set (at that point) was nicely orthogonal, so we often hand coded patches rather than use the assembler/editor, since it was faster.

22 years, 10 months

1
0
0 0

[pups] BSD 2.11 on an 11/73 + RD54

by Tobias Russell

Hi, I've managed to get a BSD 2.11 root filesystem onto my 11/73 via VTserver and I am preparing to use vtc to transfer the /usr components. Currently when I boot, I start off with my terminal set to 19,200 baud 8-N-1 but once BSD has booted I have to switch to 19,200 7-E-1 Can anyone tell me why this is happening and how I fix it so the setting remains on 8-N-1? (stty?) Also, if I can't fix this, will vtserver/vtc run on 7-E-1 comms? Toby

22 years, 10 months

2
1
0 0

Re: TUHS digest, Vol 1 #71 - 2 msgs

by msokolov＠ivan.Harhan.ORG

Johnny Billquist <bqt(a)update.uu.se> wrote: > > It is a problem only if you choose to honor copyright laws. Since that is > > your personal voluntary choice, it is your problem. > > Yes, and it's *that* problem I'm looking for a solution to. But since you've created that problem for yourself by your own voluntary choice to honor copyrights, you shouldn't be asking others for a solution. > Freed as in "legally freed", or just "made available". Legally by whose law? It is legal by the Law of Hammurabi, King of Babylon by the way of Anu, Enlil, and Marduk. [1] > harhan.org don't exist from where my dns is looking... :-/ It sure exists: Registrant: Harhan Computer Operation Facility (HARHAN-DOM) 786 E MISSION AVE APT F ESCONDIDO, CA 92025-2154 US Domain Name: HARHAN.ORG Administrative Contact, Technical Contact: Sokolov, Michael (MS35906) msokolov(a)IVAN.HARHAN.ORG The Harhan Network 786 E MISSION AVE UNIT F ESCONDIDO, CA 92025-2154 US +1-760-480-4575 +1-760-747-1493 Record expires on 17-Feb-2004. Record created on 17-Feb-2000. Database last updated on 4-Sep-2002 16:59:12 EDT. Domain servers in listed order: IVAN.HARHAN.ORG 208.221.139.1 IFCTFVAX.HARHAN.ORG 208.221.139.2 > Another machine I have access to managed to resolve ivan.harhan.org to > 208.221.139.1, Correct. > but there is no response at that address. Maybe my outside link was down then, try again. > However, if it is just the sources, and not some legal notes available, > then I don't need to go there. The new laws I've made for this planet haven't been posted yet, but they soon will be. MS [1] Lofty Anu, lord of the gods who from Heaven to Earth came, and Enlil, lord of Heaven and Earth who determines the destinies of the land, Determined for Marduk, the firstborn of Enki, the Enlil-functions over all mankind; Made him great among the gods who watch and see, Called Babylon by name to be exalted, made it supreme in the world; And established for Marduk, in its midst, an everlasting kingship.

22 years, 10 months

3
2
0 0

Re: [pups] PDP-9?

by norman＠nose.cs.utoronto.ca

Dave Horsfall: AFAIK, Unix never ran on the 11/20 (no MM unit); did you mean a DEC-20? I don't know if it was called an 11/20 at the time (I seem to recall some model-number upheaval in the early days of the -11), but the first PDP-11 UNIX system was certainly one without memory management: By the beginning of 1970, PDP-7 UNIX was a going concern ... In early 1970 we proposed acquisition of a PDP-11, which had just been introduced by Digital ... to create a system specifically designed for editing and formatting text, what might today be called a `word-processing system.' ... During the last half of 1971, we supported three typists from the Patent Department, who spent the day busily typing, editing, and formatting patent applications, and meanwhile tried to carry on our own work. UNIX has a reputation for supplying interesting services on modest hardware, and this period may mark a high point in the benefit/equipment ratio; on a machine with no memory protection and a single 0.5-MB disk, every test of a new program required care and boldness, because it could easily crash the system, and every few hours' work by the typists meant pushing out more information onto DECtape, because of the very small disk. The experiment was trying but successful. Not only did the Patent Department adopt UNIX, and thus become the first of many groups at the Laboratories to ratify our work, but we achieved sufficient credibility to convince our own management to acquire one of the first PDP-11/45 systems made. Dennis M. Ritchie, Evolution of the UNIX Time-Sharing System; AT&T Bell Labs Technical Journal, Vol. 63 No. 8 Part 2, October 1984. Maybe Dennis will chime in with further memories. Certainly there's nothing odd about UNIX running without memory protection, though, especially in that era. The PDP-7 had none. The trick was that every context switch was also a swap. The scheme was revived in the late 1970s for the early, no-memory-map versions of the LSI-11 (called LSX and later Mini-UNIX; paper by Lycklama et al in the 1978 all-UNIX BLTJ, I believe). I suppose next some whippersnapper will express disbelief that UNIX could have run on a system with no Ethernet interface. You mean there was life before 10BaseT, spam, and pornographic web sites? (Not, to be fair, that Dave Horsfall is a whippersnapper.) Norman Wilson Toronto ON (Still on the shelf, but crawling toward the edge)

22 years, 10 months

2
1
0 0

Re: [pups] Unix and PDP11/20 (was PDP9?)

by Carl Lowenstein

> From: Dennis Ritchie <dmr(a)plan9.bell-labs.com> > Subject: [pups] Unix and PDP11/20 (was PDP9?) > Date: Fri, 6 Sep 2002 02:08:02 -0400 > > Holden's link, > > http://www.psych.usyd.edu.au/pdp-11/11_20.html > > reinforces my guess that our first -11 probably did > have just "PDP11" on the bezel. The one in my photo > (which has the 20) is doubtless our second -11. > I've looked at this page before, but it slipped my mind. > > Our first -11 was very early, and its disk took several > months to arrive: it had TTY33 and high-speed paper tape > as its only peripherals besides the clock. > > Early on, for fun, we tried assembling the DEC-supplied > assembler, which came on at least one (maybe more) long > fan-folded paper tapes. I don't think we ever succeeded; it had to > be fed in twice for the two passes, and enough characters > were dropped that phase errors occurred. I was there once myself. The problem was fuzzy holes in the DEC-punched fan-fold paper tape. So I toggled in a small utility program "wait, read, wait, punch, loop" to copy from the TTY reader to the high-speed punch. The sensing pins of the TTY had no trouble with the fuzzy holes, and I got paper tapes that worked in the high-speed reader. carl -- carl lowenstein marine physical lab u.c. san diego clowenst(a)ucsd.edu

22 years, 10 months

1
0
0 0

RE: [TUHS] Ultrix...

by Ian King

Distribution can be restricted by agreement - for instance, I can share source code with you under an agreement that you will not disclose it to others, and I can seek redress if you do disclose. That is common with software. But even absent modifying contract, the "fair use" right you mention is not absolute and unfettered. If I write a book and it is published, you cannot decide to print your own copies and distribute them; I have not waived my rights under copyright by publishing. Indeed, the book does NOT "pass into the public domain" until after expiration of my copyright. This is no different from the case where I invent and create a physical object and distribute it, subject to patent rights that I have acquired; although the physical object is (by logical necessity) out in the public, others may not freely copy it and deny me the benefit of my creativity. "Publishing" is "making public," but not "placing into the public domain" - you have correctly stated that "public domain" is a legal concept, but incorrectly defined it. Even distribution for no material gain (e.g. "freeware") is not "public domain." DEC (and others) wrote some interesting licenses; although I might buy a DEC computer from you, complete with its software, I would not be legally entitled to use the software until I had negotiated my own license with DEC (or now, most commonly, Mentec). I've always thought that was a bit greedy, but it is lawful to create a non-transferrable license. Today, once the license fee for a given copy has been paid, that license is usually transferrable to another; I can give (or sell) you a copy of a book I purchased, too. But that does not change the author's rights to the material, nor those of the party in possession; it is simply not true that "placing the work in the hands of the public" means "they may now be freely redistributed". Software does make things more complex; the corpus of law around it is still being established. However, the fundamental principle of a party's right to control of and recompense for his/her/its work product, be it physical or intellectual, still applies. Anyone who denies that, and acts accordingly, is simply a thief, notwithstanding their erudite rationalizations. -- Ian My opinions do not necessarily reflect those of my employer. -----Original Message----- From: Mirian Crzig Lennox [mailto:mirian@cosmic.com] Sent: Fri 9/6/2002 6:59 AM To: tuhs(a)minnie.tuhs.org Cc: Subject: Re: [TUHS] Ultrix... On Fri, 6 Sep 2002 02:27:39 +0100, Tim Bradshaw <tfb(a)tfeb.org> wrote: >* Mirian Crzig Lennox wrote: > >> In fact, the concept of "intellectual property" is a fairly recent >> perversion, and the consequence has been a steady depletion of the >> public domain. When a piece of software (and Ultrix is an excellent >> example) is tied up in copyright long after it is of any value to >> anyone beyond pure academic interest, nothing is added to anyone's >> wealth, and society as a whole loses. > >I think this is kind of unfair in many cases. Firstly copyright has >lasted for a fairly long time for, well, a fairly long time. It's not >some sinister new development which is keeping ultrix in copyright. Copyright has existed for roughly 300 years[1]. However, the construction of copyright as a form of property is a relatively recent development. The original copyright term in the U.S. was a mere 14 years[2], and copyrights were adjudicated under tort law, not property law. As framed in law and interpreted by U.S courts, the purpose of copyright is foremost the public good (hence the "fair use" doctrine); the act of 'publishing' is, as the etymology of the word suggests, a contribution by the author to the public domain, in return for which he or she is given exclusive right to profit from that work for a limited prior time. However, since 1960 the term of copyright has been extended 11 times, so that no copyrighted work published before 1923 has entered the public domain (nor will it until 2018, save for future extensions of the term). The depletion of the public domain is real. >Secondly, it's all very well to say that old and valueless bits of >software should be freed, but if you are the organisation which has >the copyright on these things it's really less trivial than you might >think to just give them away. For a start, there's (almost by >definition) no money in it, so any kind of work needed is costing >money. Secondly there may be just plain trade-secret stuff in there, >what do you do about that? There may be all sorts of other awful >things that you don't want to let the world see. This is all a totally unrelated issue however. Copyright refers necessarily only to published materials, and published materials cannot (by definition) be trade secrets. Furthermore, "public domain" refers merely to legal status, not to any obligation to make physical materials available. The presumption is that if a work is published, then copies already exist in the hands of the public, and they may now be freely redistributed. --Mirian [1] The Statute of Anne (1710, in England) is considered to be the precursor to U.S. copyright law. [2] It could however be renewed for a single further period of 14 years, provided the initial author was still alive. _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/tuhs

22 years, 10 months

1
0
0 0

RE: [TUHS] Ultrix...

by Ian King

"It is a problem only if you choose to honor copyright laws." I can only hope that others (dis)regard your property rights, as you (dis)regard the property rights of others. BTW, where do you live? I could use a new monitor or two.... -- Ian King, speaking only for himself (the usual disclaimers apply) -----Original Message----- From: Michael Sokolov [mailto:msokolov@ivan.Harhan.ORG] Sent: Wed 8/28/2002 10:48 AM To: tuhs(a)minnie.tuhs.org Cc: Subject: Re: [TUHS] Ultrix... Johnny Billquist <bqt(a)update.uu.se> wrote: > I'm trying to figure out a way of getting the MSCP driver from Ultrix > available for porting to NetBSD. I don't support NetBSD, but Ultrix' MSCP/SCA code is available to everyone. > The problem is that it's (c) by Digital, now HP. It is a problem only if you choose to honor copyright laws. Since that is your personal voluntary choice, it is your problem. > Could I be lucky enough that Ultrix actually have been released? > And I'm talking Ultrix-32 here, not Ultrix-11. The International Free Computing Task Force has freed the Ultrix-32 V2.00 and V4.20 sources. They can be found on our FTP site in ivan.Harhan.ORG:/pub/UNIX/thirdparty/Ultrix-32 -- Michael Sokolov 786 E MISSION AVE APT F Programletarian Freedom Fighter ESCONDIDO CA 92025-2154 USA International Free Computing Task Force Phone: +1-760-480-4575 msokolov(a)ivan.Harhan.ORG (ARPA) Let the Source be with you Programletarians of the world, unite! _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/tuhs

22 years, 10 months

3
3
0 0

[pups] bringing up the fist C compiler

by Dennis Ritchie

The chist paper on my home page is pretty complete (if telegraphic) about bootstrapping B on the PDP-7 and later C (via B) on the -11. It does not, indeed, explain TMG. Doug McIlroy did write TMG (on the -7) first in assembly language, then bootstrapped that into itself. Doug had used TMG to write EPL, the early Pl/I compiler for Multics. I don't know whether he needed to create a new implementation of TMG for that or whether it was already running on the IBM 7094. The paper also mentions (as does some of the other history stuff) that Unix itself was written first in assembler on the GE-645 (running GECOS, not Multics at that point), using a macro package that turned symbolic -7 instructions into an object deck that could be rendered onto paper tape. There is not much about TMG on the web that I can find (and some of it is inaccurate). Incidentally, TMG didn't immediately survive the move to the -11. B was already in its own language, and nothing else was using TMG besides itself. Doug did revive it later just for fun, and it is in the 6th edition distribution--you can get it nearby! Both on the -7 and the -11, TMG was implemented as an interpreter for an abstract machine. Dennis

22 years, 10 months

3
6
0 0

[pups] Unix and PDP11/20 (was PDP9?)

by Dennis Ritchie

Holden's link, http://www.psych.usyd.edu.au/pdp-11/11_20.html reinforces my guess that our first -11 probably did have just "PDP11" on the bezel. The one in my photo (which has the 20) is doubtless our second -11. I've looked at this page before, but it slipped my mind. Our first -11 was very early, and its disk took several months to arrive: it had TTY33 and high-speed paper tape as its only peripherals besides the clock. Early on, for fun, we tried assembling the DEC-supplied assembler, which came on at least one (maybe more) long fan-folded paper tapes. I don't think we ever succeeded; it had to be fed in twice for the two passes, and enough characters were dropped that phase errors occurred. Incidentally, B programs could be run on this first pre-disk -11, using cross-compilation from GECOS. There was a stand-alone predecessor of dc! BTW, apologies for the units slip in the earlier posting. Indeed 128 words of RAM on the 11/10, 4096 words standard on the 11/20 (we splurged with 12K). Also BTW, the young woman on p. 104 of the first manual has a just-so-1969 hairdo! She has her index finger on one of the console switches, is holding a Unibus jumper in the other hand, and the caption is "The PDP-11 provides Direct Device Addressing...." The Unibus address pin assignments that replaced herwere probably more useful, but not so redolent of history. Dennis

22 years, 10 months

1
0
0 0

RE: [TUHS] Ultrix...

by Ian King

I agree with your premise that copyright can be detrimental to broader interests, and the case of "obsolete but historically interesting" software is a prime case in point. However, copyright holders can choose to make things readily available without placing them in the public domain; the 'Ancient UNIX' license is a great example. If they choose not to do so, the law does allow them recourse. I doubt they would consume the resources to execute on that against individuals who are running old software for non-commercial purposes; I suspect that those who commit such indiscretions wholesale may not be treated with such latitude. And, IMHO, those who baldly advertise their general disdain of copyright law are pretty much asking for it. -- Ian My opinions are my own, and do not necessarily represent my employer's opinions. -----Original Message----- From: Mirian Crzig Lennox [mailto:mirian@cosmic.com] Sent: Thu 9/5/2002 4:56 PM To: tuhs(a)minnie.tuhs.org Cc: Subject: Re: [TUHS] Ultrix... On Wed, 4 Sep 2002 20:15:52 -0700, Ian King <iking(a)microsoft.com> wrote: >"It is a problem only if you choose to honor copyright laws." I can > only hope that others (dis)regard your property rights, as you > (dis)regard the property rights of others. BTW, where do you live? I > could use a new monitor or two.... It is possible to respect property rights and yet disagree (to the point of disobedience) with how the concept has been lately twisted by monied interests in the United States. The purpose of copyright is not to be a form of property; if it were, copyrights would not expire. The purpose of copyright is to enrich the public domain by encouraging authors to publish their works, by ensuring them exclusive right to profit from their work for a limited time after which time *the work passes into the public domain*. This is plainly stated in the U.S. Constitution as the basis for copyright law: "To promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries." [Article I, section 8]. In fact, the concept of "intellectual property" is a fairly recent perversion, and the consequence has been a steady depletion of the public domain. When a piece of software (and Ultrix is an excellent example) is tied up in copyright long after it is of any value to anyone beyond pure academic interest, nothing is added to anyone's wealth, and society as a whole loses. --Mirian _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/tuhs

22 years, 10 months

1
0
0 0

Re: [pups] Bringing up the fist C compiler

by Al Kossow

<nl> > I guess my MACRO-11 implementation of C isn't good enough. > (Well, it ain't mine, it's the normal DECUS C, but I'm hacked some at it.) <nl><nl> and to bring this full circle, do you know where DECUS C came from? <nl><nl>

22 years, 10 months

2
1
0 0

Re: [pups] Bringing up the fist C compiler

by Carl Lowenstein

> From: Al Kossow <aek(a)spies.com> > To: pups(a)tuhs.org > Subject: Re: [pups] Bringing up the fist C compiler > Content-ID: <9012_13188_1031248039_2(a)spies.com> > Date: Thu, 5 Sep 2002 10:47:19 -0700 > > <nl> > > I guess my MACRO-11 implementation of C isn't good enough. > > (Well, it ain't mine, it's the normal DECUS C, but I'm hacked some at i= > t.) > <nl><nl> > > and to bring this full circle, do you know where DECUS C came from? > <nl><nl> It is my understanding that it was a "clean room" reimplementation of the 6th Edition Unix "cc" and "as". carl -- carl lowenstein marine physical lab u.c. san diego clowenst(a)ucsd.edu

22 years, 10 months

1
0
0 0

Re: [TUHS] Vax 3300 and Ultrix

by msokolov＠ivan.Harhan.ORG

Peter Wrangell <pwrangell(a)bsdmercs.org> wrote: > I am looking for a copy of Ultrix 4.5 preferably on TK70 tapes but any > medium will do. I have a MicroVax 3300 that I would like to breath life > into again. I can't help you with 4.5, but I have the full V4.00 TK50 distribution and it fully supports MV3300 with DSSI. The tape images are on my FTP site in: ivan.Harhan.ORG:/pub/UNIX/thirdparty/Ultrix-32/ult400vaxdist-tk50 On the same site I also have full sources for V2.00 and V4.20. (I have no sources for the version for which I have the dist, and no dists for the versions for which I have the sources... I guess I need to bite the bullet and compile V4.20 myself. Some day maybe.) MS

22 years, 10 months

1
0
0 0

RE: [pups] Bringing up the fist C compiler

by Ian King

About a thousand years ago, I recall hand-building programs for 8-bit microprocessors (in what we'd call embedded systems today). In many cases, I was the "assembler", writing directly in machine code which was then either keyed in through front-panel switches or burned into a PROM.... -- Ian -----Original Message----- From: Johnny Billquist [mailto:bqt@update.uu.se] Sent: Thu 9/5/2002 5:05 AM To: Tim Bradshaw Cc: pups(a)minnie.tuhs.org Subject: Re: [pups] Bringing up the fist C compiler On Thu, 5 Sep 2002, Tim Bradshaw wrote: > * Johnny Billquist wrote: > > > How? It was written, of course. In assembler. By that time, you already > > had the assembler, an editor, and other commonly used system programs, so > > it's just a case of the normal development cycle. > > Is this known or is it deduction? [...] Ah. Ok, now I understand what you're asking for. You want to know what the first C was written in, and what that compiler/assembler was written in/on, and so on... No, I'm just deducting. Since the reference posted said that TMG was the first higher level language implemented, it follows that it must have been written in a low level language, namely assembler. Admittedly, the PDP-7 TMG *could* have been written in some high level language on some other machine using some tool that made a PDP-7 executable, so your guess is as good as mine. But even though I cannot account for all steps, I can guarantee that at the end of the chain, you *will* find assembler. I guess my MACRO-11 implementation of C isn't good enough. :-) (Well, it ain't mine, it's the normal DECUS C, but I'm hacked some at it.) Johnny Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)update.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol _______________________________________________ PUPS mailing list PUPS(a)minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/pups

22 years, 10 months

1
0
0 0

Vax 3300 and Ultrix

by Peter Wrangell

Greetings, I am looking for a copy of Ultrix 4.5 preferably on TK70 tapes but any medium will do. I have a MicroVax 3300 that I would like to breath life into again. Unfortunately the version in the Archives is too old to be of use and it seems that there is no DSSI support in NetBSD. I would be willing to trade old computer parts in return(I have Old SGI, Dec PDP and and Sun Stuff). Any help would be appreciated. Thanks. -Peter pwrangell(a)bsdmercs.org

22 years, 10 months

1
0
0 0

Re: Re: [pups] Unix and PDP11/20 (was PDP9?)

by John Holden

On Wed, 4 Sep 2002, Dennis Ritchie wrote:- > I'm not positive about the logo on our first PDP-11. The picture of Dennis and Ken in front ASR-33's hints at a pdp11/20 logo on the console. The 11/20 I have (built 29/1/71, SN 821) has just plain 'pdp11'. The lead time on getting the machine was about 6 months. I suspect that the /20 was added as other models were in the pipeline (/05,/45). For a picture, see http://www.psych.usyd.edu.au/pdp-11/11_20.html > Incidentally, the machine's handbook was a wonder. Indead it was The front cover is interesting, in that it shows a table top version of the 11/20. It was quite possible to run one just with paper tape and an ASR33 with the reader/punch option. There was a similar option for the pdp8/e. The only obvious change between the first and second edition handbooks was that the latter changed the last page from a picture of a young lady in front of a machine to a table of Unibus pin assignments.

22 years, 10 months

1
0
0 0

Re: [pups] Unix and PDP11/20 (was PDP9?)

by Carl Lowenstein

> From: Dennis Ritchie <dmr(a)plan9.bell-labs.com> > Subject: [pups] Unix and PDP11/20 (was PDP9?) > Date: Wed, 4 Sep 2002 00:21:40 -0400 > > I'm not positive about the logo on our first PDP-11. The text accompanying the picture "Ken and Den" somewhere on your web site says that the logo on your first PDP-11 was just "PDP-11" without the /20. > On the earliest handbook I have, the front panel photo > just shows "PDP11", though inside the handbook > it does talk about the two models (11/10 and 11/20). > Both had the same KA11 processor, but the basic > 11/10 sported 1024Kw ROM memory plus a generous > 128 words of RAM, while the 11-20 had > 4096Kw core RAM, and the ASR33 Teletype was included. > You could add more RAM to the 11/20. I fear that you have suffered a "units slip" saying 1024Kw and 4096Kw when you meant 1Kw and 4Kw respectively. > Incidentally, the machine's handbook was a wonder. > In 104 pages (each 5.25x8 inches), it described the whole > system: not only the instruction set but the theory > of the Unibus (including some logic diagrams) together with > programming specifications for the TTY, the clock, > and the paper tape reader. > > Dennis Agreed, "PDP11 Handbook Second Edition" was a really good book Occasionally I wonder if I ever had my hands on a "First Edition" and threw it away when the second edition came out. Not knowing that both the computer and the handbook would become classics. carl -- carl lowenstein marine physical lab u.c. san diego clowenst(a)ucsd.edu

22 years, 10 months

1
0
0 0

[pups] PDP11/73, RD53, RX50... What are my options?

by Tobias Russell

Hi, I have a micro PDP11/73 equipped with an RD53, RX50 and a Cipher mag tape drive (untested). The machine currently boots into TSX (although I don't have usernames/passwords so no shell access). I'd like to get BSD2.11 onto the machine. What is going to be the best route? I assume that my chances of breaking through TSX security (so I can use kermit) are small, so is vtserver going to be the easiest method? Toby Tobias Russell Managing Director Russell Sharpe Limited The Tannery, Tannery Lane, Bramley, Surrey. GU5 0AJ England Tel: +44 (1483) 894158 Fax: +44 (1483) 898932 Email: toby(a)russellsharpe.com

22 years, 10 months

3
2
0 0

Re: [pups] PDP11/73, RD53, RX50... What are my options?

by norman＠nose.cs.utoronto.ca

Carl Lowenstein: I suppose the easiest break-in tool would be a floppy disk with a bootable RT11 on it. Or, if your goal is just to drain the machine's brain entirely and start over, which is likely the case if you want to put 2.11 on it: dig up the standalone disk diagnostic (is XXDP easily available somewhere these days?) and reformat the disk. Norman Wilson Toronto ON

22 years, 10 months

1
0
0 0

Re: [pups] PDP11/73, RD53, RX50... What are my options?

by Carl Lowenstein

> From: "Tobias Russell" <toby(a)russellsharpe.com> > To: "PDP Unix Preservation Society" <pups(a)tuhs.org> > Date: Mon, 2 Sep 2002 08:38:26 +0100 > > Hi, > > I have a micro PDP11/73 equipped with an RD53, RX50 and a Cipher mag tape > drive (untested). The machine currently boots into TSX (although I don't > have usernames/passwords so no shell access). > > I'd like to get BSD2.11 onto the machine. What is going to be the best > route? I assume that my chances of breaking through TSX security (so I can > use kermit) are small, so is vtserver going to be the easiest method? I haven't done it in many years, but after you get the machine to boot into RT11 you can disable the TSX security stuff. Probably a file named "STARTF.COM" is the initial RT11 startup and it contains the command to chain to TSX. I suppose the easiest break-in tool would be a floppy disk with a bootable RT11 on it. carl -- carl lowenstein marine physical lab u.c. san diego clowenst(a)ucsd.edu

22 years, 10 months

1
0
0 0

RE: [pups] PDP-9?

by Fred N. van Kempen

Unix was _developed_ on the 11/20. The first versions (up to the fourth or fifth edition or so) didn't require an MMU, and, therfore, had no protection whatsoever. Dennis... tell us the "All out?" story.. please.. :) --fred > -----Original Message----- > From: Dave Horsfall [mailto:dave@horsfall.org] > Sent: Monday, September 02, 2002 3:02 AM > To: PDP Unix Preservation Society > Subject: Re: [pups] PDP-9? > > > On Sun, 18 Aug 2002, Lars Buitinck wrote: > > > we all know that UNIX first ran on the PDP-7 and then on > the PDP-11/20, > > Just got back from overseas, but this doesn't seem to have > been addressed: > AFAIK, Unix never ran on the 11/20 (no MM unit); did you mean > a DEC-20? > > -- > Dave Horsfall DTM VK2KFU dave(a)esi.com.au Ph: +61 2 > 9906-3377 Fx: 9906-3468 > (Unix Guru) Pacific ESI, Unit 22, 8 Campbell St, Artarmon, > NSW 2065, Australia > > _______________________________________________ > PUPS mailing list > PUPS(a)minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/pups >

22 years, 10 months

2
1
0 0

[pups] Unix and PDP11/20 (was PDP-9?)

by John Holden

Early editions of Unix did run on a PDP11/20, written in assembly language. There was a memory mapping option KS-11 that sat between the processor and Unibus that mapped chunks of memory. It was a DEC special, and only about a dozen were built. See http://cm.bell-labs.com/cm/cs/who/dmr/odd.html A hardware story'

22 years, 10 months

2
1
0 0

Re: [pups] PDP-9?

by Johnny Billquist

On Mon, 2 Sep 2002, Dave Horsfall wrote: > On Sun, 18 Aug 2002, Lars Buitinck wrote: > > > we all know that UNIX first ran on the PDP-7 and then on the PDP-11/20, > > Just got back from overseas, but this doesn't seem to have been addressed: > AFAIK, Unix never ran on the 11/20 (no MM unit); did you mean a DEC-20? Um? Who said Unix used an MMU in the beginning? No, Unix never ran on a PDP-10. It was PDP-7 and then the PDP-11, and I believe it was a PDP-11/20 at the beginning. Johnny Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)update.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

22 years, 10 months

1
0
0 0

Mine's older than yours

by norman＠nose.cs.utoronto.ca

Larry McVoy: In response to old hardware... My first machine was an Okidata CPM machine which had a color (!) monitor and a built in printer. If someone had one of these, I'd like it just for old time's sake... Well, my first computer was a Cardiac. I'm glad to say that I managed to grab one from Classic Computing a few years ago, but I don't think they have any left. If anyone knows of a source, I'd be interested to hear about it; every now and then I mention Cardiac to someone who hasn't heard of it, and they'd like to know where to get one. I still think Cardiac should be a required tool in freshman programming courses. Norman Wilson Toronto ON

22 years, 10 months

2
1
0 0

Re: TUHS digest, Vol 1 #73 - 1 msg

by Larry McVoy

In response to old hardware... My first machine was an Okidata CPM machine which had a color (!) monitor and a built in printer. If someone had one of these, I'd like it just for old time's sake... -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

22 years, 10 months

1
0
0 0

computer inventory for hardcore geeks (fwd)

by Warren Toomey

All, I just received this e-mail. I have no idea who Wendy is, but perhaps the things she has stashed away may be of some interest to you. Warren ----- Forwarded message from Wendy Murphy ----- >From jendywo(a)yahoo.com Sat Aug 31 08:22:00 2002 Message-ID: <20020830222155.14119.qmail(a)web14907.mail.yahoo.com> Date: Fri, 30 Aug 2002 15:21:55 -0700 (PDT) From: Wendy Murphy <jendywo(a)yahoo.com> Subject: computer inventory for hardcore geeks To: clintw(a)colorado.cirrus.com, xds_sigma7(a)hotmail.com, eric(a)brouhaha.com, iking(a)microsoft.com, mcquiggi(a)sfu.ca, emu(a)ecubics.com, dworkin(a)village.org, russell283(a)attbi.com Cc: rob(a)witte-family.net, jjdellea(a)chisp.net, wkt(a)tuhs.org X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.01 Content-Length: 3539 In my quest to get the house clean so I can get out, I decided to inventory the computer stuff. It's like inventory by the technologically blind! I got just so far before I got frustrated and gave up. Pat and Rob took the sillyscope (with the intention of selling it, I believe) and the RT, I think it was called (to keep for my ex-). Dworkin took the PDP-11/73. I asked him for $84 because that's what I need to keep Xcel from shutting off my electricity, but he chose to give me a check for $500, which I have not cashed and won't until he's had the stuff long enough to ascertain that it works and tell me so, or for two weeks, whichever comes first. That leaves: (Note: sizes are eyeballed by someone with a lousy eye) IN THE GARAGE: various cables, keyboards, mouses, plugs, cabinets, broken TVs, VCRs, and a Laser disk player, and miscellaneous hardware a box about 1'x1.5'x2' with a 3.5" and a 5.25" drive, and seven flat buttons with colored lights and symbols, like turtles, rabbits, and lightning bolts. an Alpha Micro 1000E Raster Tech monitor D-SCAN, an 8"x8"x1" board with 17 female cable plugs in three rows labeled "In" "Out" and "CH", six columns labeled "R G B H V C" a 3'x3'x2' dec RXO2 and RLO2 exposure timer & power supply unit Sharp electric typewriter, and another electric typewriter up too high for me to read anything off it. a couple of Apple II+s (Dad wants to keep one as he has some information on a 5.25" floppy formatted for that computer) SCM152 dry copier microfiche reader ? Kennedy model 9300 tape drive AlphaWrite documentation, and several 3-ring binders of documentation I just didn't feel like thumbing through for particulars right now (but can later, if you like) and the infamous 78 2'x2' floor tiles. (Dworkin said he's seen them advertised for $9 apiece, new. They're not quite in new condition, but that gives a ballpark for what they ought to be worth) I didn't check IN THE LOFT, because it's too high for me to reach or see. IN THE FURNACE ROOM: I saw an Amdex 300A video monitor NEC multisync 2A monitor Raster Tech monitor ADDS (?) monitor and at least one other monitor with no words I could identify An okidata printer an ALPS ALQ200 printer an IBM selectric II typewriter a Minolta fax 261 and a "stack" -- y'know, a computer, with two 3.5" and one 5.25" floppy drives and buttons that said "turbo" and "reset", but no brand name I could make out. IN THE CAVE: there remains a Scientific Atlanta receiver IBM monitor IBM 3.5" floppy drive HP LaserJet printer Smith-Corona electric typewriter Data south DS 150 printer Microscience International Corporation thing that says it has 7 heads and 855 cylinders, but won't tell me what it uses them for digital h3350; I don't know what it is, but it's the size of a deck of cards a couple of EMLock security door thingies (magnetic) various boards (green things with solder and little batteries and stuff on them) a couple of Alpha Micro video cassettes That's what I had the energy to see. Can you enlighten me as to what these things are and what ought to be done with them? I can't even get at the other stuff in the furnace room/garage until some of it gets moved. ~ Wendy the technologically incorrigible ----- End of forwarded message from Wendy Murphy -----

22 years, 10 months

1
0
0 0

Re: TUHS digest, Vol 1 #71 - 2 msgs

by Johnny Billquist

Sokolov wrote: > Johnny Billquist <bqt(a)update.uu.se> wrote: > > > I'm trying to figure out a way of getting the MSCP driver from Ultrix > > available for porting to NetBSD. > > I don't support NetBSD, but Ultrix' MSCP/SCA code is available to everyone. I know you don't support it. :-) > > The problem is that it's (c) by Digital, now HP. > > It is a problem only if you choose to honor copyright laws. Since that is your > personal voluntary choice, it is your problem. Yes, and it's *that* problem I'm looking for a solution to. > > Could I be lucky enough that Ultrix actually have been released? > > And I'm talking Ultrix-32 here, not Ultrix-11. > > The International Free Computing Task Force has freed the Ultrix-32 V2.00 and > V4.20 sources. They can be found on our FTP site in Freed as in "legally freed", or just "made available". > ivan.Harhan.ORG:/pub/UNIX/thirdparty/Ultrix-32 harhan.org don't exist from where my dns is looking... :-/ Another machine I have access to managed to resolve ivan.harhan.org to 208.221.139.1, but there is no response at that address. However, if it is just the sources, and not some legal notes available, then I don't need to go there. Johnny Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)update.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

22 years, 10 months

1
0
0 0

Re: [TUHS] Ultrix...

by msokolov＠ivan.Harhan.ORG

Johnny Billquist <bqt(a)update.uu.se> wrote: > I'm trying to figure out a way of getting the MSCP driver from Ultrix > available for porting to NetBSD. I don't support NetBSD, but Ultrix' MSCP/SCA code is available to everyone. > The problem is that it's (c) by Digital, now HP. It is a problem only if you choose to honor copyright laws. Since that is your personal voluntary choice, it is your problem. > Could I be lucky enough that Ultrix actually have been released? > And I'm talking Ultrix-32 here, not Ultrix-11. The International Free Computing Task Force has freed the Ultrix-32 V2.00 and V4.20 sources. They can be found on our FTP site in ivan.Harhan.ORG:/pub/UNIX/thirdparty/Ultrix-32 -- Michael Sokolov 786 E MISSION AVE APT F Programletarian Freedom Fighter ESCONDIDO CA 92025-2154 USA International Free Computing Task Force Phone: +1-760-480-4575 msokolov(a)ivan.Harhan.ORG (ARPA) Let the Source be with you Programletarians of the world, unite!

22 years, 10 months

1
0
0 0

Ultrix...

by Johnny Billquist

Hi. I have a small question for you. I'm trying to figure out a way of getting the MSCP driver from Ultrix available for porting to NetBSD. The problem is that it's (c) by Digital, now HP. Does anyone know of any persons who were involved in the old days when code was exchanged between BSD and Ultrix? Those people might be a good starting point for getting code today as well I suspect. Does anyone else around here have any good clues on this? Could I be lucky enough that Ultrix actually have been released? And I'm talking Ultrix-32 here, not Ultrix-11. Johnny Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)update.uu.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

22 years, 10 months

1
0
0 0

[pups] Re: heavy to ship

by Warren Toomey

In article by Joe Dellea: > What does one do in such a situation? Hi Joe, I've passed the e-mail on to some mailing lists, and hopefully you will get some eager mail about it soon! Good luck, Warren

22 years, 10 months

2
1
0 0

[pups] heavy to ship (fwd)

by Warren Toomey

----- Forwarded message from Joe Dellea ----- Date: Tue, 27 Aug 2002 02:35:12 -0600 From: Joe Dellea <jjdellea(a)chisp.net> To: wkt(a)tuhs.org Subject: heavy to ship Proffessor Toomey: I have an interesting problem for you.... A friend of mine here in Denver, (Colorado,US) is in posession of a PDP 11/73 and litterally a ton of peripheral hardware- it was left in her house by her ex-husband who more than likely dumpster-dived it while working for the phone company. The Ex is a talented Computer guy, but a bit of an idiot in his personal life.... Friend wants to find a new home for this machine. Friend is erratic. Also fairly pissed off. Could probably use some money, but mainly wants the thing to go away, rather than calculate actual dollar value or whatever.... Would be happy if it went to a good home. What does one do in such a situation? In my case, I found your web-page near the top of a Google search..... Regards, Joe Dellea jjdellea(a)chisp.net ----- End of forwarded message from Joe Dellea -----

22 years, 10 months

1
0
0 0

RE: [pups] It all works!!

by Fred N. van Kempen

Ian King wrote: > > I suggest you now find a multi-port beer card, insert that into a free > > slot, add /dev/beer to the kernel, and abuse it lots... :) > > > > (rumor is, that 2.9bsd has much more space available for /dev/beer > > buffers, though, so if 2.11 doesn't allow enough of it, just take the > > plunge and downgrade to 2.9... ;-) > > Should he implement uubp? Well, that's kinda store-and-forward. A bit dated, innit? Why not go the modern way and go straight for the splattering-type mbdp? For those who dunno: Multicast Beer Distribution Protocol. One catch... given the kind of stuff we want distributed, we'd better not have any (memory and/or session) leaks... --f

22 years, 10 months

1
0
0 0

[pups] It all works!!

by Kevin Murrell

Needed to tell someone, so I thought I would tell all of you! My PDP11/73 now has BSD2.11 installed and working. I added a DEQNA card, rebuilt the kernel and now ping, telnet, ftp et al is working. The joy of telneting into my '11 from a Windoze machine is beyond words! Many thanks to Warren, Fred and Joe for all the help and advice. Regards Kevin

22 years, 10 months

2
1
0 0

RE: [pups] It all works!!

by Fred N. van Kempen

I suggest you now find a multi-port beer card, insert that into a free slot, add /dev/beer to the kernel, and abuse it lots... :) (rumor is, that 2.9bsd has much more space available for /dev/beer buffers, though, so if 2.11 doesn't allow enough of it, just take the plunge and downgrade to 2.9... ;-) --f > -----Original Message----- > From: Kevin Murrell [mailto:kevin@ps8.co.uk] > Sent: Thursday, August 22, 2002 3:04 PM > To: Pups Mailing List > Subject: [pups] It all works!! > > > Needed to tell someone, so I thought I would tell all of you! > > My PDP11/73 now has BSD2.11 installed and working. I added a > DEQNA card, > rebuilt the kernel and now ping, telnet, ftp et al is working. > > The joy of telneting into my '11 from a Windoze machine is > beyond words! > > Many thanks to Warren, Fred and Joe for all the help and advice. > > Regards > > > Kevin > > _______________________________________________ > PUPS mailing list > PUPS(a)minnie.tuhs.org > http://minnie.tuhs.org/mailman/listinfo/pups >

22 years, 10 months

1
0
0 0

RE: Porting Unix v6 to i386

by russ

It seems as though there was considerable interest in Porting Unix v6 to i386 some months ago. This is a project that appeals to me also. I was wondering if anyone has made any headway in the project and would like to share their experience.

22 years, 10 months

3
2
0 0

[pups] some RD54 drives free to takers in .nl

by Wilko Bulte

Hi, I have some RD54 drives (and maybe a RD53 or so) that I want to part with. Free for a PDP user in the Netherlands who is willing to pick them up in Arnhem (I won't ship them) Wilko -- | / o / /_ _ wilko(a)FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands

22 years, 10 months

1
0
0 0

[pups] re: PDP-9

by Dennis Ritchie

Bilquist said (quoting Buitinck): > > we all know that UNIX first ran on the PDP-7 and then on the PDP-11/20, > > but does anyone know anything about PDP-9 UNIX? it\'s mentioned in \"The > > UNIX Time-Sharing System\" in the V7 manual: > > > > \"The earliest [version of UNIX] (circa 1969-70) ran on the Digital > > Equipment Corporation PDP-7 and -9 computers.\" > Hmmm, I cannot exactly answer that, but the PDP-7 and PDP-9 were both > 18-bit machines, and somewhat compatible, I believe. > The whole line is (I believe): > PDP-4 -> PDP-7 -> PDP-9 -> PDP-15 > So I guess that if you had it running on a PDP-7, you could probably > almost take the code unmodified and run it on the PDP-9. > The PDP-15 have a different bus (Unibus?) I believe, and thus, > peripherials are different from the predecessors. > This obviosuly affects the OS. :-) The 7, 9, 15 were very compatible. I think the -15 had some scheme for using an index register, which the earlier ones didn't have, but it was otherwise pretty much identical in IS architecture. There was very little rewriting to try Unix out on the -9 and -15; perhaps just some tweaks in the disk device commands. I don't think the system actually ran on either for more than a few hours. Ken was just playing around. The -15 may have had an electrically different bus, but I'm reasonably sure it was not a Unibus. All of them used IOT instructions, not memory-mapped IO registers. Both of the machines we tried were being used by other groups and we couldn't squat on them as with the PDP-7. I recall that the -15's main job was controlling a step-and-repeat camera that exposed LSI masks. Dennis

22 years, 10 months

6
6
0 0

Re: [pups] re: PDP-9

by Carl Lowenstein

> To: pups(a)minnie.tuhs.org > From: Dennis Ritchie <dmr(a)plan9.bell-labs.com> > Subject: [pups] re: PDP-9 > Date: Tue, 20 Aug 2002 23:55:55 -0400 > > Bilquist said (quoting Buitinck): > > > > we all know that UNIX first ran on the PDP-7 and then on the PDP-11/20, > > > but does anyone know anything about PDP-9 UNIX? it\'s mentioned in \"The > > > UNIX Time-Sharing System\" in the V7 manual: > > > > > > \"The earliest [version of UNIX] (circa 1969-70) ran on the Digital > > > Equipment Corporation PDP-7 and -9 computers.\" > > > Hmmm, I cannot exactly answer that, but the PDP-7 and PDP-9 were both > > 18-bit machines, and somewhat compatible, I believe. > > The whole line is (I believe): > > > PDP-4 -> PDP-7 -> PDP-9 -> PDP-15 > > > So I guess that if you had it running on a PDP-7, you could probably > > almost take the code unmodified and run it on the PDP-9. > > The PDP-15 have a different bus (Unibus?) I believe, and thus, > > peripherials are different from the predecessors. > > This obviosuly affects the OS. :-) > > The 7, 9, 15 were very compatible. I think the -15 > had some scheme for using an index register, which > the earlier ones didn't have, but it was otherwise > pretty much identical in IS architecture. > > There was very little rewriting to try Unix out > on the -9 and -15; perhaps just some tweaks in > the disk device commands. I don't think the > system actually ran on either for more than a few > hours. Ken was just playing around. > > The -15 may have had an electrically different > bus, but I'm reasonably sure it was not a Unibus. > All of them used IOT instructions, not memory-mapped > IO registers. > > Dennis What I remember, as the last gasp of PDP-15 production was a dual-processor setup, linked with a PDP-11. The intent was to take advantage of the lower-cost Unibus peripherals. I remember the sales literature, but do not recall ever seeing one. carl -- carl lowenstein marine physical lab u.c. san diego clowenst(a)ucsd.edu

22 years, 10 months

1
0
0 0

[pups] Test message

by Tom Alsberg

This is a test message, please ignore it. -- Tom -- Tom Alsberg - certified insane, complete illiterate. e-mail: <alsbergt(a)softhome.net> Homepage: http://www.cs.huji.ac.il/~alsbergt/ * An idea is not responsible for the people who believe in it.

22 years, 10 months

1
0
0 0

[pups] Re: PDP-9

by Roger Ivie

Dennis Ritchie said: > The 7, 9, 15 were very compatible. I think the -15 > had some scheme for using an index register, which > the earlier ones didn't have, but it was otherwise > pretty much identical in IS architecture. According to Gordon Bell's "Computer Engineering", the primary differences from the -4 to the -7 were switching from 6-bit to ASCII I/O devices and the addition of a trap mechanism. The -9 primarily changed the memory system, going to 2-1/2D core; it was also microcoded. The -15 went to TTL ICs and added index registers and memory relocation. He says "The PDP-9 instruction compatibility was acheived with three minor exceptions about which no complaints were received", although I don't see an explanation of the exceptions. http://research.microsoft.com/users/GBell/Computer_Engineering/ -- Roger Ivie ivie(a)cc.usu.edu

22 years, 10 months

1
0
0 0

[pups] Dilog DQ686, anyone?

by Fred N. van Kempen

Hey gang, Does anyone have an online manual or other info for the DQ686 ESDI disk controller from Dilog? I'm trying to fix a VAX 4, which as that beastie... Thanks, Fred

22 years, 10 months

2
1
0 0

Re: [pups] Dilog DQ686, anyone?

by Carl Lowenstein

> From: "Fred N. van Kempen" <Fred.van.Kempen(a)microwalt.nl> > To: <pups(a)minnie.tuhs.org> > Subject: [pups] Dilog DQ686, anyone? > > Hey gang, > > Does anyone have an online manual or other info for the DQ686 > ESDI disk controller from Dilog? I'm trying to fix a VAX 4, > which as that beastie... There is a manual for the DQ696, which is essentially the same thing except it controls 2 drives not 4. It was last seen by me at < http://www.miim.com/documents/dilog/dq696.zip >. It is zip-compressed MSWord. carl -- carl lowenstein marine physical lab u.c. san diego clowenst(a)ucsd.edu

22 years, 10 months

1
0
0 0

[pups] PDP-9?

by Lars Buitinck

we all know that UNIX first ran on the PDP-7 and then on the PDP-11/20, but does anyone know anything about PDP-9 UNIX? it\'s mentioned in \"The UNIX Time-Sharing System\" in the V7 manual: \"The earliest [version of UNIX] (circa 1969-70) ran on the Digital Equipment Corporation PDP-7 and -9 computers.\" -- If I travelled to the end of the rainbow As Dame Fortune did intend Murphy would be there to tell me The pot is at the other end Lars

22 years, 10 months

2
1
0 0

[pups] Vtserver, BSD2.11 and brain_fatigue

by Kevin Murrell

Hi all Firstly, I have done this before, but due to age/stress/tiredness/whatever, I can't remember what I did! I am using Warren's/Fred's vtserver program to install BSD2.11 on an 11/53. I have installed the root.dump file (and all the steps beforehand) and now my '53 boots into 2.11. So far so good! I now need to restore the usr file systems - all the stuff in file6/7/8.tar How do I do this still using Vtserver. Someone remind me please! Regards Kevin Murrell

22 years, 11 months

3
2
0 0

RE: [pups] Unix on a PDP-11/24

by Ian King

You could also run Unix v6, if you're of a historical bent; 2.9BSD should run with no problems; and possibly v7, if you have the 22-bit address bus and enough RAM. Keep in mind that if there isn't a distribution for your machine, you can build one on an emulator, then create a disk image. However, with v6 I ran the 11/40 image on an 11/34 and was able to rebuild for my hardware. Warren wrote a neat tool to get bits onto a machine over a serial line; it takes a while (at 9600 baud!), but it works. Look on the PUPS site under VTserver; don't worry that there probably isn't an installation package for a given version or machine, there's a way to run a small client on a PC that can talk to a bootstrap on the target machine. -- Ian DISCLAIMER: Pay no attention to that man behind the curtain - or to my email address. These rantings are my personal statements, and not a product of my employer. -----Original Message----- From: Bill Gunshannon [mailto:bill@cs.scranton.edu] Sent: Tuesday, August 13, 2002 11:17 AM To: Unix_Preservation_List Subject: Re: [pups] Unix on a PDP-11/24 On 13 Aug 2002, Christopher McNabb wrote: > I've acquired a PDP-11/24 with 2 RL02s and a RA80. What are my > options for running Unix? > Ultrix-11 if you can get a 9-track tape drive. :-) bill -- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves bill(a)cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include <std.disclaimer.h> _______________________________________________ PUPS mailing list PUPS(a)minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/pups

22 years, 11 months

1
0
0 0

RE: [pups] Unix on a PDP-11/24

by Fred N. van Kempen

> I've acquired a PDP-11/24 with 2 RL02s and a RA80. What are > my options for running Unix? Either a small system like V7, or Ultrix-11. And no, you don't need a tape drive... as long as you have a PC around, and the PDP-11 has a serial port, you can use my VTserver package to install Ultrix over the console port. Cheers, Fred

22 years, 11 months

1
0
0 0

[pups] Unix on a PDP-11/24

by Christopher McNabb

I've acquired a PDP-11/24 with 2 RL02s and a RA80. What are my options for running Unix? -- --------------------------------------------------------------------- Christopher L McNabb Tel: 540 231 7554 Operating Systems Analyst Email: cmcnabb(a)vt.edu Virginia Tech ICBM: 37.205622N 80.414595W GMRS: WPSR255 ARS: N2UX Grid Sq: EM97SD

22 years, 11 months

2
1
0 0

Re: [TUHS] Re: pcc ports

by Christian Groessler

On 08/10/2002 04:54:16 PM MST Al Kossow wrote: > >> I see there no version for the Z8000 but for the 16032. Was there >> really a Z8000 version? > >http://www.lcs.mit.edu/about/architects.html > >"Fortunately for Ward, by 1980 the community of computer researchers >had grown from a few labs to a few dozen---and for the most part, the >research community was moving in one particular direction: UNIX, the >castrated Multics operating system that had been spawned from Bell >Labs. UNIX was loved because it was small and portable, which meant >that it would be easy for Ward to get the operating system running on >the NuMachine. The group got the UNIX source code from Bell Labs and >ported the operating system to three different microprocessors: the >Zilog Z8000, the Intel 8086, and the Motorola 68000. Although it >would not be clear for several years, by building a single-user >computer with a bitmapped display, a network interface, and a >powerful microprocessor, Ward's group had just created one of the >world's first UNIX workstations. >" Hmm, but where is it? :-) regards, chris

22 years, 11 months

1
0
0 0

Re: pcc ports

by Al Kossow

> I see there no version for the Z8000 but for the 16032. Was there > really a Z8000 version? http://www.lcs.mit.edu/about/architects.html "Fortunately for Ward, by 1980 the community of computer researchers had grown from a few labs to a few dozen---and for the most part, the research community was moving in one particular direction: UNIX, the castrated Multics operating system that had been spawned from Bell Labs. UNIX was loved because it was small and portable, which meant that it would be easy for Ward to get the operating system running on the NuMachine. The group got the UNIX source code from Bell Labs and ported the operating system to three different microprocessors: the Zilog Z8000, the Intel 8086, and the Motorola 68000. Although it would not be clear for several years, by building a single-user computer with a bitmapped display, a network interface, and a powerful microprocessor, Ward's group had just created one of the world's first UNIX workstations. "

22 years, 11 months

1
0
0 0

Re: pcc ports

by cpg＠aladdin.de

On 08/10/2002 10:09:54 AM ZE10 Warren Toomey wrote: > >In article by M E Leypold @ labnet: >> Al Kossow writes: >> > There were ports of PCC to the 8086, Z8000, and 68000 done by >> > MIT's Laboratory for Computer Science. This might be a more >> > historically correct place to start. >> I alway wondered, wether the source of these ports is available >> somewhere. I bet it isn't. >> Regards -- Markus > >Al has sent in the PCC ports mentioned to the Unix Archive. They are >now available on the primary site at both: > > http://www.tuhs.org/Archive/Applications/Portable_CC/ > ftp://minnie.tuhs.org/UnixArchive/Applications/Portable_CC/ I see there no version for the Z8000 but for the 16032. Was there really a Z8000 version? regards, chris

22 years, 11 months

1
0
0 0

v7 upgrade

by Al Kossow

There were ports of PCC to the 8086, Z8000, and 68000 done by MIT's Laboratory for Computer Science. This might be a more historically correct place to start.

22 years, 11 months

4
4
0 0

RE: [pups] 2.11BSD on non separate I&D systems?

by Fred N. van Kempen

Hi, > Has anyone done anything to try and get 2.11BSD working > on non-separate I&D PDP-11s? > > One of the various READMEs I ran across said it might be possible > with some creative memory layouts using overlays. > > I briefly searched the PUPS mail archives but turned up > nothing. No way. It already relies heavily on overlays to get things done. Even without the networking code (which requires I&D, *and* Supervisor mode), there is pretty much no way to get it to fit (even a small system) within a 64K space. If you really need a UNIX that (slowly ;-) fits in the nonID space, ytu Ultrix-11. That fits, although its very slow on such machines. Cheers, Fred

22 years, 11 months

1
0
0 0

[pups] 2.11BSD on non separate I&D systems?

by Michael

Hi folks, Forgive me in case this question has been asked before.. Has anyone done anything to try and get 2.11BSD working on non-separate I&D PDP-11s? One of the various READMEs I ran across said it might be possible with some creative memory layouts using overlays. I briefly searched the PUPS mail archives but turned up nothing. Thanks, -- Michael lion(a)apocalypse.org

22 years, 11 months

1
0
0 0

[pups] Message for Steve Schultz

by Robin Birch

Hi Steve, Long time no chat. Can't get through to your email on moe so can you amend my email address for patch distributions to robinb(a)ruffnready.co.uk. Attempting to stem the tide of spam :-( Cheers Robin

22 years, 11 months

1
0
0 0

SVID?

by Larry McVoy

In the "it would be nice" department, I'd love more copies of the 1986 3 volume SVID. If people have copies of these sitting around, I'll pay for them. I could use a dozen sets. Thanks in advance (he says hopefully :) -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

22 years, 11 months

1
0
0 0

[Bourne shell] SVR1

by Sven Mascheck

Hello, I'm searching for documentation about the SVR1 shell: i would be glad if somebody could dig up e.g. a man page or the 1st edition of the SVID (System V Interface Definition). I'm interested in the history of the Bourne shell, and this is the last important variant i'm missing (my current knowledge documented in .sig). I know the short "changes" paragraph in the 2nd SVID, however a few points are still unclear to me. Sven -- <http://www.uni-ulm.de/~s_smasch/various/bourne/>

22 years, 11 months

2
1
0 0

Re: [TUHS] Copies of 1978 and 1984 BSTJ on Unix; what should I do with them?

by Aharon Robbins

> (Does anyone know how many copies of BSTJ vol. 57, no. 6 there are out there?) Bell Labs reprinted this volume, it was popular for a while. I bought my copy circa 1981 simply by writing to the address listed and sending a check for whatever amount it said. Arnold

22 years, 11 months

1
0
0 0

Re: [TUHS] Copies of 1978 and 1984 BSTJ on Unix; what should I do with them?

by Bryan Cantrill

> Dear UNIX Hertigate Society, > > I was wondering if you could tell me if these two journals are worth > anything and to whom. > > WHile I haven't done Unix work since 1992. When I picked these journals > up in 1986 out of computer engineering school I had a sense they were > something special. I believe the Bell System Technical Journal > July/August 1978 Vol. 57, No. 6., Part 2 is one of the first places that > Ritchie and THomson publicly described the design of Unix. > > They are both in reasonably good condition. Do you know if they are > worth anything? Do you know who might be interested in them? They are certainly worth something. (And, being finite, will probably be worth more in the future.) If they mean something to you personally, you should probably hold on to them. If you want to sell them, I would recommend eBay (which seems to be the best venue for selling used computer manuals at the moment). Be sure to include a write-up of what makes these two volumes so special. Note that BSTJ vol. 57, no. 6 will likely fetch a much higher price than vol. 63, no. 8. (I've bought the latter for as little as ten bucks.) (Does anyone know how many copies of BSTJ vol. 57, no. 6 there are out there?) - Bryan ---------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. bmc(a)eng.sun.com (650) 786-3652

22 years, 12 months

1
0
0 0

Copies of 1978 and 1984 BSTJ on Unix; what should I do with them?

by Sylvan.Stephan＠epamail.epa.gov

Dear UNIX Hertigate Society, I was wondering if you could tell me if these two journals are worth anything and to whom. WHile I haven't done Unix work since 1992. When I picked these journals up in 1986 out of computer engineering school I had a sense they were something special. I believe the Bell System Technical Journal July/August 1978 Vol. 57, No. 6., Part 2 is one of the first places that Ritchie and THomson publicly described the design of Unix. They are both in reasonably good condition. Do you know if they are worth anything? Do you know who might be interested in them? THanks! Stephan Sylvan

22 years, 12 months

2
1
0 0

Distributions directory and UCB, and missing ftp site

by Gregg C Levine

Hello from Gregg C Levine Folks, I've got a question here. What happened to the ftp site mentioned in this Readme file? I'll post it here, in its entirety, with the reference in question highlighted. Quoted Readme there: "The directories 2.9BSD and 2.11BSD contain these UNIX distributions, and " "were supplied by Steven Schultz. They contain a full distribution, including " "installation tape images. " " " "The remaining gzipped tar files are other 2BSD distributions supplied by" "Keith Bostic, except for spencer_2bsd.tar.gz which came from Henry Spencer." "They do not contain installation tape images. The 2.9BSD-Patch directory" "contains patches to 2.9BSD dated August 85, and again supplied by Keith Bostic." " " "Note that Steven Schultz is still maintaining 2.11BSD, fixing bugs and making" "improvements. The patches required to bring this archive version of 2.11BSD" "up to the current patch level can be obtained via anonymous ftp to" "ftp.iipo.gtegsc.com in the directory /pub/2.11BSD" ^^^^^^^^^^^^^^^^ I have tried connecting to it, and my client tells me it does not exist. But I've seen Steve's message, on my earlier question, so I know he's here. Steve, are you continuing the work described in the file? And can you get back to me, via a private message. Warren both replies are valid. Gregg C Levine drwho8(a)worldnet.att.net "How many floors does this TARDIS of yours have, anyway?" P.S. Thanks to everyone for getting back to me so quickly on that issue regarding our old friend, and the historical items here.

23 years

2
1
0 0

Re: [TUHS] Distributions directory and UCB, and missing ftp site

by Steven M. Schultz

Hi - > From: "Gregg C Levine" <drwho8(a)worldnet.att.net> > 2.11BSD" > "up to the current patch level can be obtained via anonymous ftp to" > "ftp.iipo.gtegsc.com in the directory /pub/2.11BSD" > ^^^^^^^^^^^^^^^^ > I have tried connecting to it, and my client tells me it does not exist. But Indeed. That's the trouble/curse of the Internet - it's not possible to go around and fix/change all the references to names that change as companies get bought/sold That was a long long (quad_t? ;)) time ago. GTE sold their Government Systems Corporation ('gsc') to General Dynamics several years ago. After a while GTE of course insisted we stop using 'gtegsc' - then a little later GTE became Verizon. Try "ftp.to.gd-es.com" For now. The idjits in charge are playing at reorganizing and I think sometime next year the domain name will change yet again - but the hope is that the current name will be retained for a while as a compatibility measure. > Steve, are you continuing the work described in the file? And can you get It's been a slow couple years - only a couple updates done last year and only one or so this year. Current patchlevel's at 442 (done Jan 2002). Yes, the archive of updates is maintained. I think there are a couple mirrors but I have no accurate count of who is mirroring the directory Steven Schultz sms(a)2bsd.com

23 years

1
0
0 0

Re: [TUHS] Re: Porting Unix v6 to i386

by Warren Toomey

In article by Sven Dehmlow: > Hi Warren, > I can't find the port [of V6 to the 286] in the archives. > Am I'm too stupid to search or haven't you added it yet? > Sven My apologies, I had forgotten to import it. It's now available at http://www.tuhs.org/Archive/Other/V6on286 with the mirror sites to follow soon. Cheers, Warren

23 years

3
3
0 0

Re: [TUHS] Other operating systems on the PDP-11

by Steven M. Schultz

Hi - > From: Warren Toomey <wkt(a)minnie.tuhs.org> > In article by Greg 'groggy' Lehey: > > The big issue is address space. It's difficult enough shoehorning > > 2.11BSD onto the PDP-11. It's well-nigh impossible to retrofit 32 bit > > operating systems. But Steven M. Schulz will doubtless give you a > More specifically, the issue is data space. Using overlays, you can > have a process with more than 64Kbytes of instruction space on a PDP-11, > but the maximum data space that a process can have is 64Kbytes. > > The kernel is in a similar situation, but with some PDP-11 models > there is kernel mode and supervisor mode, giving you two separate > 64Kbytes instruction + 64Kbytes data address spaces (and overlays > to increase the I space). > > I can't see Linux fitting into 128K of data space, and GCC is definitely > out of the question. Besides, 2.11BSD already looks pretty close to 4BSD :-) Well said Warren. The D (data) space is the most severe constraint on adding any new feature to 2.11BSD. Besides, as Warren mentioned, most of 4.3BSD as well as a few bits&pieces of 4.4 are already present. A couple years ago I toyed with the idea of porting over the 4.4BSD tty subsystem (it'd be real nice to have termios and 8bit clean serial line handling). The 'struct tty' almost tripled in size! Even doing major surgery and leaving out a couple less useful capabilities the growth in 'struct tty' exceeded what is left available in 2.11's kernel D space. Oh, I should point out the limit for the kernel's D space is even lower than the 64KB mentioned. Of that 64KB the I/O page has to, of course, be mapped in at all times or the kernel wouldn't have access to the memory management registers, device registers, and so on. Then the kernel has to have access to 'struct u' (the per process context area - part of the address space is also where the kernel stack is kept). So, 64 - 8 - 8 = 48. The kernel has a total of 48KB of data space to use. There are a few "tricks" that are played. Some data structures are allocated external to the kernel's D space. That data is mapped in as needed. Slows things down of course since it does take a number of instructions to save the current memory manangement status, change it to access the external data, fetch the data, restore the mmu registers. Things such as the 4.3BSD disc quota system were implemented this way. There is at the present time an absolute maximum on the size of the I (instruction/text) space of 56K + (15*8)KB or 176KB (base segment of 56KB and 15 overlays of 8KB each. At present, depending on how many drivers and so on are configured, about 9 or 10 overlays are used to build a 2.11 kernel. The actual limit of kernel size that can be booted is a bit lower due to how the boot process functions - in order to simplify the memory manangement during booting the boot code relocates to 192KB. The sum of the kernel text plus initialized data (but not the .bss segment) can not exceed 192KB or the boot code will be overwritten. Another complicating factor comes from UMR (Unibus Mapping Registers) handling - if the boot code ever runs above 256KB then UMR handling would have to be done by the boot code on UNIBUS machines (Qbus machines of course don't have this problem since they don't have UMRs to contend with). GCC (all of the GNU stuff actually) was written with, I believe, "malloc aforethought" ;) It's outright hostile to 16 bit machines. There might be a few bytes free to add a feature or two to 2.11BSD but much more than that would mean a lot of work to come up with some free D space for the data structures that would be needed. Cheers, Steven Schultz sms(a)2bsd.com

23 years

1
0
0 0

Other operating systems on the PDP-11

by Gregg C Levine

Hello from Gregg C Levine I've got a question for those of you, who work more in that field then I.Has anyone successfully gotten, say, NetBSD, or anything along the lines of the 4.4 series to run on a PDP-11? Granted I don't think it would work there, because of the way its hardware was constructed. Or for that matter, say Linux? Since the Simh collection builds easily on Linux, I was thinking that it would be relatively simple to do so. Gregg C Levine drwho8(a)worldnet.att.net "How many floors does this TARDIS of yours have, anyway?"

23 years

3
2
0 0

SCO then Caldera

by Gregg C Levine

Hello from Gregg C Levine The web site links, that contain the SCO location, now point to a site on Caldera's site. I tried e-mailing someone via their contacts page, but so far to no avail. Has anyone on the list had any favorable response, regarding the ability to access their archives of the older versions of UNIX? As always, I am interested in the versions of UNIX that are targeted towards the PDP-11. Seriously though, has anyone actually gotten any feedback from Caldera? Warren if you want to comment, please do so, and I'll even accept a private one. Gregg C Levine drwho8(a)worldnet.att.net "How many floors does this TARDIS of yours have, anyway?"

23 years

2
1
0 0

Re: [TUHS] The Tim Shoppa distribution of V6

by Wolfgang Helbig

Gregg C Levine: >gotten the distribution to boot, using a version of Simh? A text file of >commands to be fed to the Simh program would be a great help. Here is a transcript: PDP-11 simulator V2.9-10 sim> set rl0 rl02 sim> show rl0 RL0, 5242KW, not attached, write enabled, RL02 sim> att rl0 unix_v6.rl02 sim> show rl0 RL0, 5242KW, attached to unix_v6.rl02, write enabled, RL02 sim> boot rl0 !unix unix v6 11/23 mem = 99 KW max = 63 # Good Luck, Wolfgang Gregg C Levine: >gotten the distribution to boot, using a version of Simh? A text file of >commands to be fed to the Simh program would be a great help. Here is a transcript: PDP-11 simulator V2.9-10 sim> set rl0 rl02 sim> show rl0 RL0, 5242KW, not attached, write enabled, RL02 sim> att rl0 unix_v6.rl02 sim> show rl0 RL0, 5242KW, attached to unix_v6.rl02, write enabled, RL02 sim> boot rl0 !unix unix v6 11/23 mem = 99 KW max = 63 # Good Luck, Wolfgang

23 years

1
0
0 0

Re: [TUHS] The Tim Shoppa distribution of V6

by Gregg C Levine

Hello from Gregg C Levine Thank you for your kind advice, Warren. However, I have tried most of the other members of that directory, and yes, it does work. I am curious about this one, because it appears to be decidely different then say an actual distribution of V6. I am also looking at the ones that came from the Research area. Gregg C Levine drwho8(a)worldnet.att.net "How many floors does this TARDIS of yours have, anyway?" ----- Original Message ----- From: "Warren Toomey" <wkt(a)minnie.tuhs.org> To: "Gregg C Levine" <drwho8(a)worldnet.att.net> Sent: Sunday, June 30, 2002 8:09 AM Subject: Re: [TUHS] The Tim Shoppa distribution of V6 > In article by Gregg C Levine: > > On the FTP site, is a a V6 distribution contributed by Tim Shoppa. It is > > created for the PDP-11/23, and there is a good readme.txt file that explains > > the different images, and how they got there. However, has anyone actually > > gotten the distribution to boot, using a version of Simh? A text file of > > commands to be fed to the Simh program would be a great help. > > I have mine, built using the MingW compiler, and this is version 2.9-10. > > Also, if anyone has gotten it to boot on real hardware, that would a be a > > great plus. > > Gregg, I'd first try the other V6 boot images found in: > > http://www.tuhs.org/Archive/PDP-11/Boot_Images > > e.g v6_rl02_unknown.gz > > to make sure that they will boot with the Supnik emulator. > You might also find that the Supnik emulator can't emulate > an 11/23. So I would also try the Ersatz emulator and set > it's CPU to be a 23. > > In other words, try a known bootable image first, then > try Ersatz-11 as an 11/23 on that same bootable image, > and then try Tim Shoppa's image. > > Warren >

23 years

1
0
0 0

The Tim Shoppa distribution of V6

by Gregg C Levine

Hello again from Gregg C Levine On the FTP site, is a a V6 distribution contributed by Tim Shoppa. It is created for the PDP-11/23, and there is a good readme.txt file that explains the different images, and how they got there. However, has anyone actually gotten the distribution to boot, using a version of Simh? A text file of commands to be fed to the Simh program would be a great help. I have mine, built using the MingW compiler, and this is version 2.9-10. Also, if anyone has gotten it to boot on real hardware, that would a be a great plus. Gregg C Levine drwho8(a)worldnet.att.net "How many floors does this TARDIS of yours have, anyway?"

23 years

1
0
0 0

FW: Missing pack from the UnixV6 distros based at the TUH site

by Gregg C Levine

Hello from Gregg C Levine normally with Jedi Knight Computers Forwarded from a posting on news:alt.sys.pdp-11 that I made. Rather then repost the entire message in perpetuity I decided to forward the whole business to this list. As I am still deciding the best way to make use of the whole file tree, without an actual machine living here, I decided to download everything to this one, and then wait. Gregg C Levine drwho8(a)att.net "How many floors does this TARDIS of yours have, anyway?" "Gregg C Levine" <drwho8(a)att.net> wrote in message news:<20020625121449.XOEM20423.mtiwmhc21.worldnet.att.net@who>... > Hello from Gregg C Levine > Has anyone actually found this to happen? The TUH ftp site, has on it, a > number of actual distributions for UNIX for the PDP-11. One of them was > assembled by Tim Shoppa from a discarded machine. They were > subsequently uploaded to that site. However on of the packs is missing. > It is this one, "xxdp_with_1123.rl02: XXDP+ on RL02 pack, bootable." > That is from the README file associated with the entire directory. > Everything else is there, that one is not. What did happen to it, I wonder. > Gregg C Levine drwho8(a)att.net > >

23 years

2
3
0 0

Re: [pups] Real ZOO web site, welcome! ID<sxsvCplqqlh1wxkv1ruj>

by Warren Toomey

In article by Dave Horsfall: > On Mon, 24 Jun 2002, Randy Merkel wrote: > > Golly, I think we have a spammer ;) > Either he/she/it took the trouble to subscribe (few do), or the list > is wide open; if the latter, expect more crap. Open no more, and I have to approve subscriptions too :-) Warren

23 years

1
0
0 0

RE: [pups] Real ZOO web site, welcome! ID<sxsvCplqqlh1wxkv1ruj>

by Randy Merkel

Golly, I think we have a spammer ;)

23 years

1
0
0 0

[pups] Real ZOO web site, welcome! ID<sxsvCplqqlh1fv1dgid1r}1dx>

by Farmgirl10326

23 years

1
0
0 0

[pups] Real ZOO web site, welcome! ID<sxsvCplqqlh1wxkv1ruj>

by Farmgirl28914

23 years

1
0
0 0

[pups] Real ZOO web site, welcome! ID<sxsvCwxkv1ruj>

by Farmgirl28237

23 years

1
0
0 0

Simh and networking, and any of the available 2.11BSD collections

by Gregg C Levine

Hello from Gregg C Levine I've just joined this list, so bear with me. I am developing applications that will be using the protcols covered in DECnet to access a running PDP-11 system. Actually it is running, but its a SimH program posing as a PDP-11/23. I have downloaded the boot images, especially the 2.11BSD system that is available, and booted it under the SimH simulator. Any suggestions as to how I take this one step further? This is running on both Windows, and Linux. But the DECnet programs were built on Slackware Linux. Gregg C Levine drwho8(a)worldnet.att.net "How many floors does this TARDIS of yours have, anyway?"

23 years

1
0
0 0

[pups] bsd2.11 kernel compile

by joseph lang

I am building a PDP 11 from junked parts and have it mostly working. I'm now installing BSD 2.11 and have run into a problem i could use some help with. When compiling a new kernel (to include network) I get an error ld: too big for type 431 *** exit 2 I assume this error is due to one of the overlays being too large. (this is pointed out in the install docs) How do I figure out which overlay (or base) is the problem? The random module shuffle in the documents only has 10 million combinations and at 30 minutes to compile, well I'm not going to live that long. Is there a more scientific way to arrange the overlays? Am I missing something obvious? joe lang langj(a)bellsouth.net

23 years

3
3
0 0

Re: [pups] bsd2.11 kernel compile

by Steven M. Schultz

Hi! > From: "Chuck Dickman" <chd_1(a)nktelco.net> I see you beat me to the answer ;) > During the compile 'size' outputs a list of the sizes of the > overlays. Look at the output. For mine.... > > > How do I figure out which overlay (or base) is the problem? > > The base must be less than 7 8k pages or 57344(decimal) bytes. > Each overlay must be less than 8k bytes or 8192(decimal). > The network code is not overlayed, so you have 8 pages or the > full 64k. And you use "size" on the .o files to see how much each object file contributes to an overlay. With the exception of a few .o files which *must* be in the base segment (and these are identified in the Makefile) anything can go anywhere it will fit. The overlay switching is extremely efficient so don't worry about the 'affinity' of modules too much. Oh, it should be mentioned that it is not legal to have an empty (0 length) overlay except at the end - i.e. you can't have overlay 3 be 0 bytes if overlay 4 or higher has nonzero size. > To make it work, just get the sizes below the limits. The > optimal arrangement would be placing the code in such that > the overlay changes were minimized. So... move your system > disk drivers into base and change the configuration to > remove any hardware you don't actually have. With the exception of perhaps the tty driver for the specific serial devices present on the system it's not worth trying to pack things "optimally". The overhead of overlays is inhererent in the function prologue and epilogue - the only extra overhead of actually switching overlays is stuffing ~two words or so into the MMU registers. DO NOT remove anything from the actual OV lines in the makefile - just make sure you define/configure devices as not being present in the config file (by saying you have 0 of them). Then the .o files do not take up any space and can be segregated into unused overlays at the end (OV9 or 10 or so). Good Luck! Steven Schultz sms(a)2bsd.com

23 years

1
0
0 0

Re: [TUHS] Re: Porting Unix v6 to i386

by Mike Haertel

>I'll upload it soon. Meanwhile, instead of a DOS C compiler, people >should be able Bruce Evans' bcc or C86 as the compiler, which would >eventually allow the system to compile itself. The source code to the Watcom compilers has also finally been released.

23 years, 1 month

2
2
0 0

RE: [TUHS] Re: Porting Unix v6 to i386

by Ian King

I think this would be a great addition to the archive! I'm glad I didn't throw out that old 286 motherboard yet. :-) -- Ian -----Original Message----- From: Warren Toomey [mailto:wkt@minnie.tuhs.org] Sent: Tuesday, June 04, 2002 4:35 PM To: Szigeti Szabolcs Cc: tuhs(a)minnie.tuhs.org Subject: Re: [TUHS] Re: Porting Unix v6 to i386 In article by Szigeti Szabolcs: > I don't know if i can now legally give out parts of the original code, > if anyone wants to experiment with it (some parts are pretty ugly, > because i intedned to rewrite it, but never did, and the parts of the > comments are in Hungarian), drop me an email (though i'm now doing my > MBA thesis, so might not answer immediatey). If there is interest, I > can summarize my experiences. Hi, yes it's now legal to distribute your code, as Caldera's license allows for distribution of changes, see http://www.tuhs.org/Archive/Caldera-license.pdf I'm the guy who runs the Unix Archive, so I'd be very happy to take a copy of your work and add it to the archive. Cheers, Warren _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/tuhs

23 years, 1 month

3
2
0 0

Re: Porting Unix v6 to i386

by John Chung

Where can I obtain the program nowadays? It is going to be fun playing it using my x86 machine. :) __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com

23 years, 1 month

1
0
0 0

Re: Porting Unix v6 to i386

by Szigeti Szabolcs

Hi folks! I've just joined your mailing list, and while looking at the archives, i saw this discussion on porting V6 to Intel. Well, back in '92, in a university scinence students' competition, I ported v6 to intel286 in protected mode. (I got second place, the winner was a 3D animation prog, which is more spectacular, than a # prompt :-) I used Borland C to compile, with some extra mungling the assembly code ( i can't remember why). The hard part was to understand the protected mode, and to write the low level stuff. Other things, like filesystem, etc. compiled with hardly any modification. (Had to change =+ to =+, introduce long insted of int[2], etc.). It has floppy, ide, kbd, parallel, serial and vga drivers. It got to full multiuser operation, but there are bugs and stupid codings certainly. The C compiler, nroff, and some other parts were not ported. (Yes, I used Borland C to compile the programs, and a tool to convert it to a.out :-) I don't know if i can now legally give out parts of the original code, if anyone wants to experiment with it (some parts are pretty ugly, because i intedned to rewrite it, but never did, and the parts of the comments are in Hungarian), drop me an email (though i'm now doing my MBA thesis, so might not answer immediatey). If there is interest, I can summarize my experiences. I've not looked it since several years, so i might not remember every detail, but there are some interesting point, and it was great fun to do. Regards, Szabolcs Szigeti

23 years, 1 month

2
1
0 0

Ken Beer/NewYork/DBNA/DeuBa is out of the office.

by Ken Beer

I will be out of the office starting 05/25/2002 and will not return until 06/06/2002. I will respond to your message when I return. I will be on vacation. My manager, Venkat Jituri has my contact information. For Equity Research issues, contact Chris Fumai. -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

23 years, 1 month

1
0
0 0

Memorial Day in uts

by Bryan Cantrill

I recently discovered your excellent site (was pre-Lions src just recently made available?), which prompted me to send the following mail out to my colleagues in Solaris Kernel Development. (Apologies in advance if you find this annoying, superfluous or disrespectful -- I thought some might find it interesting, if stupid.) If there are other kernel implementors of AT&T-derived UNIX lurking here, it would be enlightening to know what a similar comparison yields on your baby. (It should go without saying that the implementation of each mentioned function has virtually no resemblance to its V3 forebear.) And of course, my burning question: has none of us changed "/* stat codes */" in proc.h?) ------8<--------------------- Subject: Memorial Day in uts To: kernel(a)eng.sun.com All, This Memorial Day, take a moment to remember the source code that has served in our kernel since its inception. To this end, wander by http://minnie.tuhs.org/UnixTree/, and pause for a moment to commemorate these brave functions from the 101st Tapeborne -- all of which have served continuously since August, 1973: bflush() falloc() newproc() sched() bread() getblk() nodev() signal() brelse() getf() nulldev() stty() bwrite() gtty() panic() suser() clock() issig() printf() swtch() closef() mmread() psig() timeout() core() mmwrite() psignal() ufalloc() Their compatriot structure fields include: av_back b_flags p_flag u_cdir av_forw b_forw p_ppid b_back c_arg (*) p_stat b_blkno c_func (*) p_wchan (*) c_func and c_arg are notable for having survived a bonwick scorched-earth rewrite of callouts circa 1997 -- unclear if this makes them eligible for the Purple Heart, or if they should be considered acquited war criminals. As for constants, B_DONE, B_ERROR, FREAD, FWRITE, and SSLEEP have all had the same numerical value since they enlisted in 1973. And a moment of silence is certainly due to this line in proc.h -- a line which has not changed so much as a character since 1973: /* stat codes */ And to the code ripped out in the line of duty, we say only: "We Have Not Forgotten." (Of course, we usually follow that up with "Never Again.") - Bryan ---------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. bmc(a)eng.sun.com (650) 786-3652

23 years, 1 month

1
0
0 0

Re: [TUHS] Re: simh vax and 4.3-quasijarus

by msokolov＠ivan.Harhan.ORG

I wrote: > the uVAX unhalt is simply an RFI: on real hardware it knows that > this RFI is an unhalt and lights the RUN LED because the SSC chip compares > instruction fetch addresses against the halt range and detects the unhalt Of course I meant REI. I was mixing VAX and PowerPC in my head again... That's what happens when you try to work on too many architectures at the same time. MS

23 years, 1 month

1
0
0 0

Re: [TUHS] Re: simh vax and 4.3-quasijarus

by msokolov＠ivan.Harhan.ORG

Rico Pajarola <rp(a)servium.ch> wrote: > At this point, I am at the simh prompt (">"). I think simh catches > the halt instruction and goes to the simh prompt when it encounters > one. I have a VAX 4000/300 at home (unfortunately it doesn't run > any of the older unixes), and when it halts, I get the >>> prompt > (differs from simh). The 4000/300 works like any other uVAX (VAX processor implemented in a single IC) in this respect: a halt is a special exception that works like regular VAX macrocode exceptions except that it saves the PC and the PSL in special IPRs rather than on the stack (so that it doesn't depend on a stack), vectors to the hardwired ROM address 20040000 rather than through SCB (so that it doesn't depend on SCB), and MAPEN is cleared (so that it goes to the physical address 20040000 in the ROM rather than whatever that address may be virtually). The CPU board firmware than displays the halt message and the >>> prompt as prescribed by the VAX Architecture (DEC STD 032-0). KA650/655 works exactly the same way. While I haven't played with simh and don't intend to in the near future (due to my general lack of interest in emulators), thus I don't claim to be right here, but from your session logs it appears that simh is not doing the above uVAX halt exception but instead it handles halts like an 11/780, by "physically" stopping all instruction execution. That is fine and dandy, the 11/780 way is certainly cooler, but the problem is it ain't a KA655 any more, and one should not expect the KA655 boot ROM to work right then (and IMAO it has no right to report the KA655 SID code either). > I am pretty sure that I have configured simh correctly, I verified > this by installing netbsd on the same setup, and it boots ok. When I took a cursory look at SIMH/VAX, which consisted only of glancing at its brief documentation, I read that the KA655 ROM image it comes with is not the real one but hacked to work with the poor emulator. This suggests to me that you are able to boot some OSes because Bob has gutted the (quite complicated) KA655 console and boot logic to the bare minimum he had emulated. I wouldn't be surprised if he hacked out the KA655 diagnostic executive almost entirely, so that on "power-up" one goes through an absolutely minimal init sequence without a single halt/unhalt cycle occuring (of which on a real KA655 several occur on every power-up during diagnostics), gets to the >>> prompt, and then when booting, runs VMB, unhalts once (the SIMH probably doesn't even know that it unhalts, as the uVAX unhalt is simply an RFI: on real hardware it knows that this RFI is an unhalt and lights the RUN LED because the SSC chip compares instruction fetch addresses against the halt range and detects the unhalt, but I doubt that SIMH emulates this), and then it all goes well (cross your fingers three times!) never goes through a proper KA655 halt/unhalt again. But if something goes wrong in the boot and VMB's error handler gets invoked, SIMH's very poor man's emulation is not prepared for it. > My only problem seems to be getting the bootblocks right. I have > heard that someone managed to install quasijarus0a on simh, so it > must be me somehow screwing the bootblocks. But the rub is that because of SIMH talking the KA655 talk but not walking the KA655 walk, you can't see what exactly is the problem with your bootblocks: VMB's error messages aren't displayed. MS

23 years, 1 month

1
0
0 0

Re: [TUHS] simh vax and 4.3-quasijarus

by Rico Pajarola

is there anybody who has successfully installed 4.3-quasijarus on simh, who could tell me how to install the bootblocks (I am not completely sure that I got the disklabel right). The exact incantation of installboot and the output of disklabel would be very helpful. Rico Pajarola

23 years, 1 month

1
0
0 0

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