- TUHS - www.tuhs.org

Re: [TUHS] Happy New Year and an amusing story from the past

by norman＠oclsc.org

Dave Horsfall: > At yet another, we had a Sun 3/50 window connected to a Convex, and acted > all innocent when various dweebs did the old "echo 99k2vp..." etc trick. John Cowan: High-precision approximation to sqrt(2). What's the trick? ====== Not really a trick, just a hoary old zero-order CPU benchmark: echo 99k2vp | time dc You can see why letting people type that on a Convex thinking it was a Sun 3/50 might have entertainment value. Modern systems are far too fast for that to be worth while, though. I still use a variant of it: a shell script called dc-N, containing dc <<! 99k[2vszla1-dsa0<b]sb${1-500}salbx ! meant to be invoked as time dc-N 10000 or the like. (The internal default of 500 has long since gone stale too, of course.) Norman Wilson Toronto ON

10 years, 6 months

2
1
0 0

Re: [TUHS] I swear! I rtfm'ed

by Johnny Billquist

On 2014-12-31 21:14, Clem Cole<clemc(a)ccc.com> wrote: > > Jake - you have lots of help from others and using curses(3) is definitely > the right way to program. > > But to answer your specific question about printf(string), according to > Chapter 3 (Programmer's Info) of my old VT-100 user's guide, I think what > is you are doing wrong is that "\033c" is not the ANSI clear to end of > screen command. Right... > When I saw your message on my iPhone last night, the cache said - wait that > can't be correct. But I could not remember why. So I had to wait until > I got back home today to look in my basement. > > As I suspected, it's not an ANSI sequence. So are you running in VT-100 > (ANSI) mode or VT52 mode? I ask because it is close to the VT52 cursor > right command which is actually: "\033C" but I do not remember is case > mattered. Case do matter. > In VT52 mode you need to send the terminal: "\033H\033J" to clear the > screen. > > In ANSI mode, it becomes: "\033[1;1\033[0J" Shorter form: "\033[H\033[J" > A few things to remember: > 1.) Clear takes the current cursor position and clears from there to end of > X (where X depends on mode, and type of clear). So you need to move the > cursor to home position (aka 1,1). Not really. It's way more advanced than that. If we start with the generic clear screen, it is CSI Pn J Where CSI can be expressed as ESC [ (or "\033[" in the same parlance as above.) Pn, then is an argument to the function, while J is the actual function (clear screen in this case). Now, Pn can cause many things: 0 Clear from cursor to end of screen 1 Clear from cursor to end of screen 2 Clear from beginning of screen to cursor 3 Clear whole screen If no argument is given, the default is 0. > 2.) VT-100's did not implement the full ANSI spec like Ann Arbor, Heathkit, > Wyse etc. So there are a number of things that those terminals did > better. A really good reason to you curses(3) because all the knowledge is > keep in the termcap and as a programmer you don't need to worry about it. Probably true. However, I'm not sure Ann Arbor or Heathkit did much better. As far as I can remember, they were always more "weird", but I might just be confused. However, curses(3) is definitely a good way of not having to care about different terminal oddities. > 3.) I saw sites were VT52 mode was sometimes preferred because it was good > enough for most editing, and needed fewer chars to do manipulation. On > slow serial lines, this sometimes was helpful. That said, give me an AAA > any day. Like others, I still miss that terminal.:-) Yeah, the VT52 was simpler, and had shorter control strings. But of course, with the additional limitations that came with that. Personally, I'd give an AAA or a Heathkit away if one was dropped on me. A VT100 I would keep. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

10 years, 6 months

5
8
0 0

I swear! I rtfm'ed

by Jacob Ritorto

, but I can't see how you're supposed to clear the screen on a vt100 in 2.9BSD. I guess printf'ing ("\033c") would do the trick, but I assumed there was a more proper way; something that leverages the vt100 termcap entry and does the right thing. Anyone? thx jake

10 years, 6 months

14
27
0 0

HP300/4.4BSD stuff

by Cory Smelosky

Evening all, Am I correct in my guess that 4.4BSD was built cross on an HP300? I have never found a binary dist of anything other than HP300 4.4...and my attempts to build 4.4 on ULTRIX/SunOS have so far not succeeded...it had to have been built SOMEHOW. I picked up an HP300 to help me get somewhere...but it seems to only have a 68010. :( I either need to find a definitive 68020-minimum one on ebay...someone with one available...or some tips of actually cross-building 4.4 for MIPS or SPARCv7 (I have physical hardware for either) I am very determined to run pure 4.4 on something bigger than a PIC32. ;) -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

10 years, 6 months

5
13
0 0

Re: [TUHS] I swear! I rtfm'ed

by jnc＠mercury.lcs.mit.edu

> From: Mary Ann Horton <mah(a)mhorton.net> > I loved my Ambassador! Ditto! > Still have one. Argh! Now you've made me want one for my vintage -11's! Alas, I don't see one on eBay.... :-( Noel

10 years, 6 months

1
0
0 0

Re: [TUHS] I swear! I rtfm'ed

by Johnny Billquist

The information give is correct. You could possibly argue that you shouldn't be using those functions, but should be using the curses(3) library instead, which in turn uses this stuff... But it's all up to how complex you want to be. :-) Johnny On 2014-12-31 07:16, Jacob Ritorto<jacob.ritorto(a)gmail.com> wrote: > Mary, this is exactly what I needed -- good to go now; thank you! > > As a side note: Man, what an intimidating can of braindamage I've opened!:) > > thanks all! > jake > > P.S. if anyone's bored enough, you can check out what we're up to at > https://github.com/srphtygr/dhb. I'm trying to get my 11yo kid to spend a > little time programming rather than just playing video games when he's near > a computer. He'a actually getting through this stuff and is honestly > interested when he understands it and sees it work -- and he even spotted a > bug before me this afternoon! Feel free to raise issues, pull requests, > etc. if you like -- I'm putting him through the git committing and pair > programming paces, so outside interaction would be kinda fun:) > > P.P.S. We're actually using 2.11bsd after all.. > > > On Tue, Dec 30, 2014 at 9:33 PM, Mary Ann Horton<mah(a)mhorton.net> wrote: > >> >This is the right info. Be sure to scroll up to see how to use tgetent, >> >tgetstr, and tputs. You aren't likely to need any padding. >> > >> >Essentially: >> > tgetent using getenv("TERM") gets you the whole entry from >> >/etc/termcap >> > tgetstr of "cl" gets you the "clear" >> >sequence >> > tputs outputs the "clear" >> >sequence >> > >> > >> >On 12/30/2014 06:22 PM, Dan Stromberg wrote: >> > >>> >>Check outhttps://www.gnu.org/software/termutils/manual/termcap-1.3/ >>> >>html_mono/termcap.html#SEC30 >>> >>- especially the "cl" entry. >>> >> >>> >>ISTR the database being at /etc/termcap normally. -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

10 years, 6 months

2
1
0 0

Bell Works

by Andy Kosela

This was brought to my attention on another mailing list. "Marking a new chapter for one of the country’s most architecturally and historically significant buildings, Somerset Development has announced a new name for the iconic former Bell Labs complex in Holmdel, N.J. The two-million-square-foot building – now named Bell Works – is currently undergoing a more than $100-million adaptive reuse redevelopment that will transform the facility into a dynamic mixed-use center.” http://patch.com/new-jersey/holmdel-hazlet/somerset-development-unveils-bel… http://bell.works/

10 years, 6 months

1
0
0 0

Re: [TUHS] What's with the DZ-11?

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > a 9-track tape followed me home, but even if I knew where it was now it > ain't gonna be readable after over 30 years... Umm, don't be too sure! I have several sets of backup tapes from one of the V6 machines at MIT, and those are also roughly 30 years old, and they are not in the best shape (they sat in my basement for most of that time). I sent one off to someone who specializes in reading old tapes, and he's gotten almost all the bits off of it (a few records had unrecoverable read errors, but the vast majority were OK - like roughly 15 read errors in around 1500 records). So do look for that tape (unless the material is all already online). I hope to annouce a vast trove of stuff soon from my tapes (once I figure out how to interpret the bits - they are written by a sui generis application called 'saveRVD', and the _only_ documentation of how it did it is... on that tape! :-) That includes a lot of code written at MIT, as well as stuff from elsewhere. Coming sbould be BCPL, Algol, LISP and some other languages; MACRO-11 and the DEC linker (which I guess are also available from UNSW tapes),but _also_ programs to convert back and forth from .REL to a.out format, and to .LDA format; and a whole ton of other applications (I have no idea what all is there - if anyone is interested, I can make a pass through my manuals and try and make a list). Noel

10 years, 7 months

3
2
0 0

What's with the DZ-11?

by Dave Horsfall

I've seen a couple of less than flattering references here; what was the problem with them? At UNSW, we couldn't afford the DH-11, so ended up with the crappy DJ-11 instead (the driver for the DH-11 had the guts ripped out of it in an all-nighter by Ian Johnston as I recall), and when the DZ-11 came along we thought it was the bees' knees. Sure, the original driver was as slow as hell, but the aforesaid IanJ reworked it and made it faster by at least 10x; amongst other things, I think he did away with the character queues and used the buffer pool instead, getting 9600 on all eight channels simultaneously, possibly even full-duplex. -- Dave Horsfall DTM (VK2KFU) "Bliss is a MacBook with a FreeBSD server." http://www.horsfall.org/spam.html (and check the home page whilst you're there)

10 years, 7 months

5
8
0 0

Re: [TUHS] BerkNet

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole A few comments on aspects I know something of: > BTW: the Arpanet was not much better at the time The people at BBN might disagree with you... :-) But seriously, throughout its life, the ARPANET had 'load-dependent routing', i.e. paths were adjusted not just in response to links going up or down, but depending on load (so that traffic would avoid loaded links). The first attempt at this (basically a Destination-Vector algorithm, i.e. like RIP but with non-static per-hop costs) didn't work too well, for reasons I won't get into unless anyone cares. The replacement, the first Link-State routing algorithm, worked much, much, better; but it still had minor issues damping fixed most of those too). > DH11's which were a full "system unit" Actually, two; they were double (9-slot, I guess?) backplanes. > The MIT guys did ARP for ChaosNet which quickly migrated down the street > to BBN for the 4.1 IP stack. Actually, ARP was jointly designed by David Plummer and I for use on both TCP/IP and CHAOS (which is why it has that whole multi-protocol thing going); we added the multi-hardware thing because, well, we'd gone half-way to making it totally general by adding multi-protocol support, so why stop there? As soon as it was done it was used on a variety of IP-speaking MIT machines that were connected to a 10MBit Ethernet; I don't recall them all, but one kind was the MIT C Gateway multi-protocol routers. > Hey it worked just fine at the time. For some definition of 'work'! (Memories of wrapping protocol A inside protocol B, because some intervening router/link didn't support protocol A, only B...) Noel

10 years, 7 months

4
4
0 0

2.10

by Jacob Ritorto

Hi all, Wanting to set up an 11/34 or 11/23 with a unix that's at least contemporary enough to run telnet and ftp. From what I can gather on line, I guess 2.10 is the best shot, but it's apparently a little less popular and I can't fin enough docs about it to determine if it'll run with the hardware I have. Am I on the right track here, or should I be considering backporting the programs to 2.9? Pointers to 2.10 Setup manual would be most welcome as well as suggestions on where to find other resources to meet this goal.. thx jake

10 years, 7 months

8
15
0 0

Re: [TUHS] BerkNet

by jnc＠mercury.lcs.mit.edu

> From: jnc(a)mercury.lcs.mit.edu (Noel Chiappa) > The replacement, the first Link-State routing algorithm, worked much, > much, better; but it still had minor issues > > damping fixed most of those too). Oop, the editor 'ate' a line there (or, rather the editor's operator spaced out :-): it should say "it still had minor issues, such as oscillation between two equal-cost paths, with the traffic 'chasing itself' from path to path; proper damping fixed most of those too". > I always give Dave Clark credit (what I call "Clark's Observation") for > the most powerful part of the replacement for the ARPAnet - aka the > idea of a network of network. Not sure exactly what you're referring to here (the concept of an internet as a collection of networks seems to have occurred to a number of people, see the Internet Working Group notes from the early 70s). > Dave once quipped: "Why does a change at CMU have to affect MIT?" Subnets (which first appeared at MIT, due to our, ah, fractured infrastructure) again were an idea which occurred to a number of people all at the same time; in part because MIT's CHAOSNET already had a collection of subnets (the term may in fact come from CHAOSNET, I'd have to check) inside MIT. > I've forgotten what we did at CMU at the time, but I remember the MIT > folk were not happy about it. I used to know the answer to that, but I've forgotten what it was! I have this bit set that CMU did something sui generis, not plain ARP sub-netting, but I just can't remember the details! (Quick Google search...) Ah, I see, it's described in RFC-917 - it's ARP sub-netting, but instead of the first-hop router answering the ARP based on its subnet routing tables, it did something where ARP requests were flooded across the entire network. No wonder we disapproved! :-) > Thought, didn't you guys have the 3Mbit stuff like we did at CMU and > UCB first? MIT, CMU and Stanford all got the 3Mbit Ethernet at about the same time, as part of the same university donation scheme. (I don't recall UCB being part of that - maybe they got it later?) The donation included a couple of UNIBUS 3Mbit Ethernet cards (a hex card, IIRC) the first 3MB connections at MIT were i) kludged into one of the MIT-AI front-end 11's (I forget the details, but I know it just translated CHAOS protocol packets into EFTP so they could print things on the Dover laser printer), and ii) a total kludge I whipped up which could forward IP packets back and forth between the 3M Ethernet, and the other MIT IP-speaking LANs. (It was written in MACRO-11, and with N interfaces, it used hairy macro expansions to create separate code for each of all 'N^2' possible forwarding paths!) Dave Clark did the Alto TCP/IP implementation (which was used to create a TFTP->EFTP translating spooler for IP access to the Dover). I can give you the exact data, if you care, because Dave Clark and I had a competition to see who could be done first, and the judge (Karen Sollins) declared it a draw, and I still have the certificate! :-) Noel

10 years, 7 months

2
1
0 0

Re: [TUHS] What's with the DZ-11?

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole <clemc(a)ccc.com> > two issues. first DEC subsetted the modem control lines so running > modems - particularly when you wanted hardware flow control like the > trailblazers - did not work. ?? We ran dialup modems on our DZ11s (1200 bps Vadics, IIRC) with no problems, so you must be speaking only some sort of high-speed application where you needed the hardware flow control, or something, when you say "running modems ... did not work". Although, well, since the board didn't produce an interrupt when a modem status line (e.g. 'carrier detect') changed state, we did have to do a kludge where we polled the device to catch such modem control line changes. Maybe that's what you were thinking of? > To Dave the DZ was great because it was two boards to do what he > thought was the same thing as a DH To prevent giving an incorrect impression to those who 'were not there', each single DZ hex board supported 8 lines (fully independent of any other cards); the full DH replacement did need two boards, though. Noel

10 years, 7 months

3
4
0 0

Re: [TUHS] What's with the DZ-11?

by jnc＠mercury.lcs.mit.edu

> From: Ronald Natalie >> each single DZ hex board supported 8 lines (fully independent of any >> other cards); the full DH replacement did need two boards, though. > Eh? The DH/DM from Able was a single hex board and it supported 16 > lines. To be read in the context of Clem's post which I was replying to: to replace the line capacity of a DH (16 lines), one needed two DZ cards. Noel

10 years, 7 months

1
0
0 0

Re: [TUHS] What's with the DZ-11?

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > what was the problem with them? Well, not a _problem_, really, but.... 'one interrupt per output character' (and no way around that, really). So, quite a bit of overhead when you're running a bunch of DZ lines, at high speeds (e.g. 9600 baud). I dunno, maybe there was some hackery one could pull (e.g. only enabling interrupts on _one_ line which was doing output, and on a TX interrupt, checking all the other lines to see if any were i) ready to take another character, and ii) had a character waiting to go), but still, it's still going to be more CPU overhead than DMA (which is what the DH used). Noel

10 years, 7 months

1
0
0 0

Re: [TUHS] 2.10

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole <clemc(a)ccc.com> > an old Able "Enable" board which will allow you to put 4Megs of memory > in an 40 class processor (you get a cache plus a new memory MAP with 22 > bits of address like the 45 class processors). But it doesn't add I/D to a machine without it, though, right? (I tried looking for Enable documentation online, couldn't find any. Does anyone know of any?) I recall at MIT we had a board we added to our 11/45 which added a cache, and the ability to have more than 256KB of memory, but I am unable to remember much more about it (e.g. who made it, or what it was called) - it must have been one of these. I recall we had to set up the various memory maps inside the CPU to permanently point to various ranges of UNIBUS address space (so that, e.g. User I space was assigned 400000-577777), and then the memory map inside the board mapped those out to the full 4MB space; the code changes were (IIRC) restricted to m45.s; for the rest of the code, we just redefined UISA0 to point to the one on the added board, etc. And the board had a UNIBUS map to allow UNIBUS devices access to all of real memory, just like on an 11/70. > From: Jacob Ritorto <jacob.ritorto(a)gmail.com> > So does that single board contain the memory and everything, or is this > a backplane mod/special memory kind of setup? I honestly don't recall much about how the board we had at MIT worked, but i) the memory was not on the board itself, and ii) there had to be some kind of special arrangements for the memory, since the stock UNIBUS only has 18 bits of address space. IIRC, the thing we had could use standard Extended UNIBUS memory cards. I don't recall how the mapping board got access to the memory - whether the whole works came with a small custom backplane which one stuck between the CPU and the rest of the system, and into which the new board and the EUB memory got plugged, or what. I had _thought_ it somehow used the FastBUS provision in the 11/45 backplane for high-speed memory (since with the board in, the machine had a basic instruction time of 300nsec if you hit the cache, just like an 11/70), and plugged in there somewhere, but maybe not, since apparently this board you have is for a /34? Or maybe there were two different models, one for the /45 and one for the /34? > With the enable34 board, do I have some hope of getting 2.11bsd on this > one? Since I doubt it adds I/D to machines that don't already have it, I would guess no. Unless somehow one can use overlays, etc, to fit 2.11 into 56KB of address space (note, not 'memory'). > I do have an 11/73 I'm working on that could run that build much more > easily and appropriately.. That's where I'd go. I do have that MIT V6 Unix with TCP/IP, where the TCP is almost entirely in user space (only incoming packet demux, etc is in the kernel), and I have found backup tapes for it, which are off at an old tape specialist being read, and the interim reports on readability are good, but until that happens, I'm not sure we'll be seeing TCP/IP on non-split-I/D machines. Noel

10 years, 7 months

1
0
0 0

Re: [TUHS] 2.10

by Jacob Ritorto

Jim / Nick, That's kinda my problem: can't find enough documentation on 2.10 to ascertain if I can / should run it. I know 2.9 is OK for the 11/34, but 2.9 doesn't have telnet or ftp and I want this machine to be easily reachable on the net. From what I've read, 2.11 is right out except for the little glimmer of hope in the docs that it "would probably only require a moderate amount of squeezing to fit on machines with less memory, but it would also be very unhappy about the prospect," which I think roughly translates to, "don't try it on a puny thing like an 11/34." I wonder if porting telnet and ftp to 2.9 on the 11/34 would be my best hope? But with a much more antique tcp stack, it sounds daunting. On Thu, Nov 20, 2014 at 9:05 PM, Jim Carpenter <jim(a)deitygraveyard.com> wrote: > > > 2.10 and 2.11 require split I/D, right? I'm positive 2.9 was the > latest I could run on my 11/34. > > Jim >

10 years, 7 months

2
2
0 0

Coherent files mislabelled

by Cory Smelosky

Afternoon, Just tried to install http://www.tuhs.org/Archive/Other/Coherent/compiler/ disk3 and disk4 got swapped, looks like gnu4 is actually disk3 and gnu3 is actually disk4. -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

10 years, 7 months

1
0
0 0

extend 2.11BSD window(1) to work with relatively enormous terminals

by Jacob Ritorto

Hi all, I've been using window(1) on my simh-emulated 11/73, but it can't handle terminals much larger than 80x24, failing with "Out of memory." I'd like to use window(1) to drive a big xterm, like 132x66, for instance, because I'd like to reduce the number of telnet connections to the host. How does one go about analyzing and remediating the memory contention in this environment? If anyone's interested, we could set up a pair programming session to work on it together, which I think would be most instructive, for me, at least. Bear in mind that this is just for pdp11 voyeurism / fun. thx jake

10 years, 7 months

1
0
0 0

Early Yacc revisited

by Mark Longridge

I've been thinking more about early yacc. It's not mentioned explicitly but I'm wondering if early Yacc's output (say in Unix version 3) was in B language since it was written in B language? It seems logical but I can't back up this assertion as there's no executable or source code that I can find. I assume there had to be some sort of B language compiler at some point but the hybrid v1/v2 unix I've looked at doesn't have it. And I'm still wondering what yacc was used for in the Unix v5 era. There's no *.y at all, e.g. no expr and no bc. I still have some hopes of modifying bc to run on Unix v5, or at least getting some simple yacc program to work under the v5 version. Mark

10 years, 7 months

2
1
0 0

AT&T video about Unix from 1982

by Jason Stevens

I just saw this video mentioned on reddit... https://www.youtube.com/watch?v=XvDZLjaCJuw UNIX: Making Computers Easier To Use -- AT&T Archives film from 1982, Bell Laboratories It features many of Bell UNIX folks, and even includes a brief example of speak in action at about the 15:20 mark. It's really cool to see the proliferation of UNIX by 1982 inside Bell.

10 years, 8 months

7
6
0 0

[tuhs] Xerox Alto and CP/M news

by Nelson H. F. Beebe

The Xerox Alto and CP/M are not Unix-derived, but the first in particular influenced the design of Unix workstations and the X11 Window System in the 1980s, so this story may be of interest to list readers: Exposed: Xerox Alto and CP/M OS source code released The Computer History Museum has made the code behind yet more historic software available for download http://www.itworld.com/article/2838925/exposed-xerox-alto-and-cp-m-os-sourc… ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

10 years, 8 months

1
0
0 0

Re: [TUHS] 11/40E and 11/60 (was: speaking of early C compilers)

by Johnny Billquist

On 2014-10-28 13:42, Clem Cole <clemc(a)ccc.com> wrote: > yes: > http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci Cool. I knew CMU did a lot of things with 11/40 machines. I didn't know they had modified them to be able to write their own microcode, but thinking about it, it should have been obvious. As they did multiprocessor systems based on the 11/40, they would have had to modify the microcode anyway. > I had a 60 running v7 years later. we also toyed with adding CSV/CRET > but never did it because we got an 11/70 >> >On Oct 27, 2014, at 9:09 PM, Dave Horsfall<dave(a)horsfall.org> wrote: >> > >>> >>On Mon, 27 Oct 2014, Clem Cole wrote: >>> >> >>> >>[...] because the CMU 11/40E had special CSV/CRET microcode which we >>> >>could not use on the 11/34. >> > >> >The 40E had microcode whilst the vanilla 40 didn't? I thought only the 60 >> >was micro-programmable; I never did get around to implementing CSV/CRET on >> >our 60 (Digital had a bunch of them when a contract with a publishing >> >house fell through). DEC actually made two PDP-11s that were micro programmable. The 11/60 and the 11/03 (if I remember right). DEC never had microprogramming for the 11/40, but obviously CMU did that. Ronald Natalie<ron(a)ronnatalie.com> wrote: >> >On Oct 27, 2014, at 10:06 PM, Clem Cole<clemc(a)ccc.com> wrote: >> > >> >yes:http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=comp… <http://repository.cmu.edu/cgi/viewcontent.cgi?article=3241&context=compsci> >> > >> >I had a 60 running v7 years later. we also toyed with adding CSV/CRET but never did it because we got an 11/70 > Problem with the 60 was it lacked Split I/D (as did the 40's). We kind of relied on that for the kernels towards the end of the PDP-11 days, > We struggled with the lack of I/D on the 11/34 and 11/23 at BRL but finally gave up when TCP came along. We just didn't have enough segments to handle all the overlaying needed to do. I recycled all the non split-I/D machines into BRL GATEWAYS. > > Of course, there was the famous (or imfamous) MARK instruction. This thing was sort of a kludge, you actually pushed the instruction on the stack and then did the RTS into the stack to execute the MARK to pop the stack and jump back to the caller. I know of no compiler (either DEC-written or UNIX) that used the silly thing. It obviously wouldn't work in split I/D mode anyhow. Years later while sitting in some DEC product announcement presentation, they announced the new T-11 chip (the single chip PDP-11) and the speaker said that it supported the entire instruction set with the exception of MARK. Me and one other PDP-11 trivia guy are going "What? No mark instruction?" in the back of the room. Yurg... The MARK instruction was just silly. I never knew of anyone who actually used it. Rumors have it that DEC just came up with it to be able to extend some patent for a few more years related to the whole PDP-11 architecture. Clem Cole<clemc(a)ccc.com> wrote: >> >Problem with the 60 was it lacked Split I/D (as did the 40's). > > ?A problem was that it was 40 class processor and as you says that means it > was shared I/D (i.e. pure 16 bits) - so it lacked the 45 class 17th bit. > The 60 has went into history as the machine that went from product to > "traditional products" faster than any other DEC product (IIRC 9 months). > I'm always surprised to hear of folks that had them because so few were > actually made. I picked up four 11/60 machines from a place in the late 80s. I still have a complete set of CPU cards, but threw the last machine away about 10 years ago. > I've forgotten the details nows, but they also had some issues when running > UNIX. Steve Glaser and I chased those for a long time. The 60 had the HCM > instruction sequences (halt a confuse microcode) which were some what > random although UNIX seemed to hit them. DEC envisioned it as a commercial > machine and added decimal arithmetic to it for RSTS Cobol.? I'm not sure > RSX was even supported on it. RSX-11M supports it. So do RSTS/E and RT-11. RSX-11M-PLUS obviously don't, since it have a minimal requirement of 22-bit addressing. The microcode specific instructions are interesting. But in general shouldn't crash things, but of course kernel is a different story. :-) Johnny

10 years, 8 months

3
7
0 0

speaking of early C compilers

by Jason Stevens

has anyone ever tried to compile any of the old C compilers with a 'modern' C compiler? I tried a few from the 80's (Microsoft/Borland) and there is a bunch of weird stuff where integers suddenly become structs, structures reference fields that aren't in that struct, c01.c register int t1; .... t1->type = UNSIGN; And my favorite which is closing a bunch of file handles for the heck of it, and redirecting stdin/out/err from within the program instead of just opening the file and using fread/fwrite.. c00.c if (freopen(argv[2], "w", stdout)==NULL || (sbufp=fopen(argv[3],"w"))==NULL) How did any of this compile? How did this stuff run without clobbering each-other? I don't know why but I started to look at this stuff with some half hearted attempt at getting Apout running on Windows. Naturally there is no fork, so when a child process dies, the whole thing crashes out. I guess I could simulate a fork with threads and containing all the cpu variables to a structure for each thread, but that sounds like a lot of work for a limited audience. But there really is some weird stuff in v7's c compiler.

10 years, 8 months

8
14
0 0

Re: [TUHS] speaking of early C compilers

by Jason Stevens

Wow BSD on a supercomputer! That sounds pretty cool! http://web.ornl.gov/info/reports/1986/3445600639931.pdf >From here it mentions it could scale to 16 process execution modules (CPU's?) while here http://ftp.arl.mil/mike/comphist/hist.html it mentions 4 PEMs which each could run 8 processes. It still looks like an amazing machine. -----Original Message----- From: Ronald Natalie To: Noel Chiappa Cc: tuhs(a)minnie.tuhs.org Sent: 10/27/14 11:09 PM Subject: Re: [TUHS] speaking of early C compilers We thought the kernels got cleaned up a lot by the time we got to the BSD releases. We were wrong. When porting our variant of the 4 BSD to the Denelcor HEP supercomputer we found a rather amusing failure. The HEP was a 64 bit word machine but it had partial words of 16 and 32 bits. The way it handled these was to encode the word size in the lower bits of the address (since the bottom three weren't used in word addressing anyhow). If the bottom three were zero, then it was the full word. If it was 2 or 6, it was the left or right half word, and 1,3, 5, and 7 yielded the four quarter words. (Byte operations used different instructions so they directly addressed the memory). Now Mike Muuss who did the C compiler port made sure that all the casts did the right thing. If you cast "int *" to "short *" it would tweak the low order bits to make things work. However the BSD kernel in several places did what I call conversion by union: essentially this: union carbide { char* c; short* s; int* i; } u; u.s = ...some valid short* ... int* ip = u.i; Note the compiler has no way of telling that you are storing and retrieving through different union members and hence the low order bits ended up reflecting the wrong word size and this led to some flamboyant failures. I then spent a week running around the kernel making these void* and fixing up all the access points to properly cast the accesses to it. The other amusing thing was what to call the data types. Since this was a word machine, there was a real predisposition to call the 64 bit sized thing "int" but that meant we needed another typename for the 32 bit thing (since we decided to leave short for the 16 bit integer). I lobbied hard for "medium" but we ended up using int32. Of course, this is long before the C standards ended up reserving the _ prefix for the implementation. The afore mentioned fact that all the structure members shared the same namespace in the original implementation is why the practice of using letter prefixes on them (like b_flags and b_next etc... rather than just flags or next) that persisted long after the C compiler got this issue resolved. Frankly, I really wish they'd have fixed arrays in C to be properly functioning types at the same time they fixed structs to be proper types as well. Around the time of the typesetter or V7 releases we could assign and return structs but arrays still had the silly "devolve into pointers" behavior that persists unto this day and still causes problems among the newbies. _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs

10 years, 8 months

2
1
0 0

Re: [TUHS] speaking of early C compilers

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > What, as opposed to spelling creat() with an "e"? Actually, that one never bothered me at all! I tended to be more annoyed by _extra_ characters; e.g. the fact that 'change directory' was (in standard V6) "chdir" (as opposed to just plain "cd") I found far more irritating! Why make that one _five_ characters, when most common commands are two?! (cc, ld, mv, rm, cp, etc, etc, etc...) Noel

10 years, 8 months

3
2
0 0

Re: [TUHS] speaking of early C compilers

by Nelson H. F. Beebe

Norman Wilson writes today: >> ... >> -- Dennis, in one of his retrospective papers (possibly that >> in the 1984 all-UNIX BLTJ issue, but I don't have it handy at >> the moment) remarked about ch becoming chdir but couldn't >> remember why that happened. >> ... The reference below contains on page 5 this comment by Dennis: >> (Incidentally, chdir was spelled ch; why this was expanded when we >> went to the PDP-11 I don't remember) @String{pub-PH = "Pren{\-}tice-Hall"} @String{pub-PH:adr = "Upper Saddle River, NJ 07458, USA"} @Book{ATT:AUS86-2, author = "AT{\&T}", key = "ATT", title = "{AT}{\&T UNIX} System Readings and Applications", volume = "II", publisher = pub-PH, address = pub-PH:adr, pages = "xii + 324", year = "1986", ISBN = "0-13-939845-7", ISBN-13 = "978-0-13-939845-2", LCCN = "QA76.76.O63 U553 1986", bibdate = "Sat Oct 28 08:25:58 2000", bibsource = "http://www.math.utah.edu/pub/tex/bib/master.bib", acknowledgement = ack-nhfb, xxnote = "NB: special form AT{\&T} required to get correct alpha-style labels.", } That chapter of that book comes from this paper: @String{j-ATT-BELL-LAB-TECH-J = "AT\&T Bell Laboratories Technical Journal"} @Article{Ritchie:1984:EUT, author = "Dennis M. Ritchie", title = "Evolution of the {UNIX} time-sharing system", journal = j-ATT-BELL-LAB-TECH-J, volume = "63", number = "8 part 2", pages = "1577--1593", month = oct, year = "1984", CODEN = "ABLJER", DOI = "http://dx.doi.org/10.1002/j.1538-7305.1984.tb00054.x" ISSN = "0748-612X", ISSN-L = "0748-612X", bibdate = "Fri Nov 12 09:17:39 2010", bibsource = "Compendex database; http://www.math.utah.edu/pub/tex/bib/bstj1980.bib", abstract = "This paper presents a brief history of the early development of the UNIX operating system. It concentrates on the evolution of the file system, the process-control mechanism, and the idea of pipelined commands. Some attention is paid to social conditions during the development of the system.", acknowledgement = ack-nhfb, fjournal = "AT\&T Bell Laboratories Technical Journal", topic = "computer systems programming", } Incidentally, on modern systems with tcsh and csh, I use both chdir and cd; the long form does the bare directory change, whereas the short form is an alias that also updates the shell prompt string and the terminal window title. I also have a personal alias "xd" (eXchange Directory) that is short for the tcsh & bash sequence "pushd !*; cd .", allowing easy jumping back and forth between pairs of directories, with updating of prompts and window titles. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

10 years, 8 months

1
0
0 0

Re: [TUHS] speaking of early C compilers

by jnc＠mercury.lcs.mit.edu

> From: Jason Stevens > has anyone ever tried to compile any of the old C compilers with a > 'modern' C compiler? > ... > How did any of this compile? How did this stuff run without clobbering > each-other? As Ron Natalie said, the early kernels are absolutely littered with all sorts of stuff that, by today's standards, are totally unacceptable. Using a variable declared as an int as a pointer, using a variable declared as a 'foo' pointer as a 'bar' pointer, yadda-yadda. I ran (tripped, actually :-) across several of these while trying to get my pipe-splicing code to work. (I used Version 6 since i) I am _totally_ familiar with it, and ii) it's what I had running.) For example, I tried to be all nice and modern and declared my pointer variables to be the correct type. The problem is that Unix generated unique ID's to sleep on with code like "sleep(p+1, PPIPE)", and the value generated by "p+1" depends on what type "p" is declared as - and if you look in pipe.c, you'll see it's often declared as an int pointer. So when _I_ wrote "sleep((p + 1), PPIPE)", with "p" declared as a "stuct file pointer", I got the wrong number. I can only speculate as to why they wrote code like this. I think part of it is, as Brantley Coile points out, historical artifacts due to the evolution of C from (originally) BCPL. That may have gotten them used to writing code in a certain way - I don't know. I also expect the modern mindset (of being really strict about types, and formal about coverting data from one to another) was still evolving back then - partly because they often didn't _have_ the tools (e.g. casts) to do it right. Another possibility is that they were using line editors, and maintaining more extensive source is a pain with an editor like that. Why write "struct file *p" wnen you can just write "*p"? And of course everyone was so space-concious back then, with those tiny disks (an RK05 pack is, after all, only 2.5MB - only slightly larger than a 3.5" floppy!) every byte counted. I have to say, though, that it's really kind of jarring to read this stuff. I have so much respect for their overall structure (the way the kernel is broken down into sub-systems, and the sub-systems into routines), how they managed to get a very powerful (by anyone's standards, even today's) OS into such a small amount of code... And the _logic_ of any given routine is usually quite nice, too: clear and efficient. And I love their commenting style - no cluttering up the code with comments unless there's something that really needs elucidation, just a short header to say, at a high level, what the routine does (and sometimes how and why). So when I see these funky declarations (e.g. "int *p" for something that's _only_ going to be used to point to a "struct file"), I just cringe - even though I sort of understand (see above) why it's like that. It's probably the thing I would most change, if I could. Noel

10 years, 8 months

4
3
0 0

Re: [TUHS] speaking of early C compilers

by Norman Wilson

Noel Chiappa: > I tended to be more annoyed by _extra_ characters; e.g. the fact that > 'change directory' was (in standard V6) "chdir" (as opposed to just > plain "cd") I found far more irritating! Why make that one _five_ > characters, when most common commands are two?! (cc, ld, mv, rm, cp, > etc, etc, etc...) In the earliest systems, e.g. that on the PDP-7, the change-directory command was just `ch'. Two vague memories about the change: -- Dennis, in one of his retrospective papers (possibly that in the 1984 all-UNIX BLTJ issue, but I don't have it handy at the moment) remarked about ch becoming chdir but couldn't remember why that happened. -- Someone else, possibly Tom Duff, once suggested to me that in the earliest systems, the working directory was the only thing that could be changed: no chown, no chmod. Hence just ch for chdir. I don't know offhand whether that's true, but it makes a good story. Personally I'd rather have to type chdir and leav off th trailing e on many other words than creat if it let me off dealing with pieces of key system infrastructure that insist on printing colour-change ANSI escape sequences (with, so far as I can tell, no way to disable them) and give important files names beginning with - so that grep pattern * produces an error. But that happens in Linux, not UNIX. Norman Wilson Toronto ON

10 years, 8 months

1
0
0 0

Re: [TUHS] speaking of early C compilers

by Jason Stevens

Thanks for clearing that the whole members out of nowhere thing. I had thought (ha ha) that since I don't have a working fork, I could just rebuild CC as a native executable, and then just call apout for each stage, but I never realized how interdependent they all are, at least C0 to C1. It's crazy to think of how much this stuff cost once upon a time. And now we live in the era of javascript pdp-11's http://pdp11.aiju.de/ -----Original Message----- From: Brantley Coile To: Jason Stevens Cc: tuhs(a)minnie.tuhs.org Sent: 10/27/14 9:03 PM Subject: Re: [TUHS] speaking of early C compilers Early C allowed you to use the '->' operator with any scaler. See early C reference manuals. This is the reason there is one operator to access a member of a structure using a pointer and another, '.', to access a member in a static structure. The B language had no types, everything was a word, and dmr evolved C from B. At first it made sense to use the '->' operator to mean add a constant to whatever is on the left and use as an l-value. You will also find that member names share a single name space. The simple symbol table had an bit in each entry to delineate members from normal variables. You could only use the same member name in two different structs if the members had the same offsets. In other words, it was legal to add a member name to the symbol table that was already there if the value of the symbol was the same as the existing entry. Dennis' compilers kept some backward compatibility even after the language evolved away from them. This really shows the value of evolving software instead of thinking one has all the answers going into development. If one follows the development of C one sees the insights learned as they went. The study of these early Unix systems have a great deal to teach that will be valuable in the post Moore's law age. Much of the worlds software will need to a re-evolution. By the way, did you notice the compiler overwrites itself? We used to have to work in tiny spaces. Four megabytes was four million dollars. Sent from my iPad > On Oct 27, 2014, at 6:42 AM, Jason Stevens <jsteve(a)superglobalmegacorp.com> wrote: > > has anyone ever tried to compile any of the old C compilers with a 'modern' > C compiler? > > I tried a few from the 80's (Microsoft/Borland) and there is a bunch of > weird stuff where integers suddenly become structs, structures reference > fields that aren't in that struct, > > c01.c > register int t1; > .... > t1->type = UNSIGN; > > > And my favorite which is closing a bunch of file handles for the heck of it, > and redirecting stdin/out/err from within the program instead of just > opening the file and using fread/fwrite.. > > c00.c > if (freopen(argv[2], "w", stdout)==NULL || > (sbufp=fopen(argv[3],"w"))==NULL) > > > How did any of this compile? How did this stuff run without clobbering > each-other? > > I don't know why but I started to look at this stuff with some half hearted > attempt at getting Apout running on Windows. Naturally there is no fork, so > when a child process dies, the whole thing crashes out. I guess I could > simulate a fork with threads and containing all the cpu variables to a > structure for each thread, but that sounds like a lot of work for a limited > audience. > > But there really is some weird stuff in v7's c compiler. > _______________________________________________ > TUHS mailing list > TUHS(a)minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs

10 years, 8 months

1
0
0 0

Re: [TUHS] speaking of early C compilers

by jnc＠mercury.lcs.mit.edu

> From: random832(a)fastmail.us > Did casting not exist back then? No, not in the early V6 compiler. It was only added as of the Typesetter compiler. (I think if you look in those 'Recent C Changes' things I sent in recently {Oct 17}, you'll find mention of it.) Noel

10 years, 8 months

1
0
0 0

Re: [TUHS] Getting Unix v5 to talk

by Jason Stevens

Have you looked at http://real-votrax.no-ip.org/ they have a votrax hooked up, and yes it'll use your phonemes that speak generates. It just likes things to be upper case though. So.. hello !p ,h,e0,l,o0,o1,-1 works more like H E0 L O0 O1 PA1 I wonder if anyone's generated wav's for each of the phonemes, then you could hook up a line printer or something that'll read it as a pipe and just play the wav's as needed.. It is rough 1970's speech synthesis, but I had one of those Intellivoice things as a kid, so I kinda like it. -----Original Message----- From: Mark Longridge To: tuhs Sent: 10/13/14 8:57 AM Subject: [TUHS] Getting Unix v5 to talk Thanks to the efforts of Jonathan Gevaryahu I have managed to get the Unix v5 speak utility to compile and execute. All this was done using the simh emulator emulating a PDP-11/70. Jonathan managed extract enough of speak.c to reconstruct it to the point it could be compiled with v5 cc. I believe it was necessary to look at speak.o to accomplish this. Jonathan also states that there are more interesting things that could possibly be recovered from v6doc.tar.gz One can look at speak.c source here: http://www.maxhost.org/other/speak.c Now had we have speak compiled we can go a bit further: cat speak.v - | speak -v null generates speak.m from ascii file speak.v speak speak.m computer !p (prints out phonetics for working word) which outputs: ,k,a0,m,p,E2,U1,t,er,-1 ctrl-d exits Looking at speak.c we can see that it opens /dev/vs. Fortunately we have the file /usr/sys/dmr/vs.c to look at so this could be compiled into the kernel although I haven't done this as yet. speak.c looks like Unix v5 era code. My understanding is that Unix v5 appeared in June 1974 and the comments say 'Copyright 1974' so it seems plausible. I'm intrigued by the possibility of getting Unix v5 to talk. Mark _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs

10 years, 8 months

1
0
0 0

Re: [TUHS] Codata progress update

by jnc＠mercury.lcs.mit.edu

> From: "Engel, Michael" <M.Engel(a)leedsbeckett.ac.uk> > The machine has a Multibus FD controller with its own 8085 CPU and a > uPD765, connected to a Toshiba 5.25" DD floppy drive (720 kB, 80 > tracks, 9 sectors of 512 bytes), the model identifier is DDF5-30C-34I > ... I couldn't find any information on that drive online, so I hesitate > to simply connect a more modern drive due to possible pinout differences. > ... > I also found out a bit more on the SMD disk controller. It seems to be > an OEM variant of the Micro Computer Technology MCT-4300 controller. > The only place I could find this mentioned was in a catalog of Multibus > boards on archive.org. > ... > So, if you happen to have any information on the Codata floppy > controller, the Toshiba floppy or the MCT-4300 SMD disk controller, I > would be happy to hear from you... I don't, but can I suggest the Classic Computers mailing list: http://www.classiccmp.org/mailman/listinfo/cctalk They seem to have an extremely deep well of knowledge, and perhaps someone there can help? (I'd rate the odds very high on the floppy drive.) Noel

10 years, 8 months

1
0
0 0

Codata progress update

by Engel, Michael

Hi, it's time for an update on our progress with the Codata machine. The serial interface problem was not caused by a defective transceiver chip (which I found out after buying a couple…), but by an extreme amount of noise on the (quite long and old) serial cable we used to connect the machine to the PC acting as a terminal. Using a USB to serial adapter and a short 9-to-25-pin adapter cable solved this problem. Well, try the obvious things first (using a scope helped). The second CPU board also works, so we could build a complete second machine with our spare boards if we have another multibus backplane... We could get the machine up and booting from the first 8" hard disk last Friday. Luckily, an old version of Kermit was installed and we were able to transmit a large part of the root file system from single user more - especially the Unix kernels, driver sources, the build directories for the kernel, include files and the build directory for the standalone boot floppies. All with a speed of 500 bytes/s (9600 bps serial line minus kermit overhead). cksum was used to confirm that the files were transferred correctly (this was the only checksumming tool that was available on the Codata, I didn't want to mount the fs read-write and compile software before completing the backup). I had to shut the machine down on Friday evening (security policy that kicks you out of the building here), since I didn't want to leave it running unattended over the weekend. Unfortunately, the disk seems to have developed a bad sector in the autoconfiguration region (the system seems to be quite modern in this respect). The kernel can be booted successfully, but it refuses to mount the root fs, complaining about a timeout. There seems to be a complete root file system on the second disk (the firmware is able to read files from the disk, but it doesn't offer a feature to list directories…), but the kernel on the second disk also is hardwired to mount its root fs from the first disk. Trying to connect disk 2 as disk 1 resulted in a non-booting system... The good news is that both root file systems seem to be reasonably intact so far, I can read text files from the boot monitor. So our next step to backup the rest of the system is to build an emergency boot floppy. At the moment, however, the Codata refuses to talk to its floppy drive. The machine has a Multibus FD controller with its own 8085 CPU and a uPD765, connected to a Toshiba 5.25" DD floppy drive (720 kB, 80 tracks, 9 sectors of 512 bytes), the model identifier is DDF5-30C-34I (printed on the motor assembly). I couldn't find any information on that drive online, so I hesitate to simply connect a more modern drive due to possible pinout differences. I also found out a bit more on the SMD disk controller. It seems to be an OEM variant of the Micro Computer Technology MCT-4300 controller. The only place I could find this mentioned was in a catalog of Multibus boards on archive.org. It has its own driver (cd.c), there is a separate one for the Interphase 2180 and an additional one for the Codata MFM controller. So, if you happen to have any information on the Codata floppy controller, the Toshiba floppy or the MCT-4300 SMD disk controller, I would be happy to hear from you... -- Michael

10 years, 8 months

1
0
0 0

Re: [TUHS] early cc variable and function names

by jnc＠mercury.lcs.mit.edu

> From: Greg 'groggy' Lehey <grog(a)lemis.com> > This is really an identifier issues Probably actually a function of the relocatable object format / linker on the machines in question, which in most (all?) cases predated C itself. > it's documented in K&R 1st edition, page 179: Oooh, good piece of detective work! Noel

10 years, 8 months

3
2
0 0

early cc variable and function names

by Mark Longridge

Hi folks, I've been looking at Unix v5 cc limitations. It seems like early cc could only use variable and function names up to 8 characters. This limitation occurs in v5, v6 and v7. But when using the nm utility to print out the name list I see function test1234() listed as: 000044T _test123 That seems to suggest that only the first 7 characters are significant, but when looking at other sources they stated that one can use up to 8 characters. I hacked up a short program to test this: main() { test1234(); test1235(); } test1234() { printf ("\nWorking"); } test1235() { printf ("\nAlso working"); } This generated: Multiply defined: test5.o;_test123 So it would seem that function names can only be 7 characters in length. I am not sure if limitations of early cc were documented anywhere. When I backported unirubik to v5 it compiled the longer functions without any problem. Did anyone document these sorts of limitations of early cc? Does anyone remember when cc started to use function names longer than 7 characters? Mark

10 years, 8 months

8
8
0 0

Re: [TUHS] early cc variable and function names

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge <cubexyz(a)gmail.com> > It seems like early cc could only use variable and function names up to > 8 characters. > This limitation occurs in v5, v6 and v7. > ... > That seems to suggest that only the first 7 characters are significant, > but when looking at other sources they stated that one can use up to 8 > characters. The a.out symbol tables use 8-character fields to hold symbol names. However, C automagically and unavoidably prepends an _ to all externals (I forget about automatics, registers, etc - too tired to check right now), making the limit for C names 7 characters. > I am not sure if limitations of early cc were documented anywhere. I remember reading the above. Other limits... well, you need to remember that C was still changing in that period, so limits were a moving target. > When I backported unirubik to v5 it compiled the longer functions > without any problem. ISTR that C truncated external names longer than 7 characters. Probably the ones in that program were all unique within 7, so you won. > Did anyone document these sorts of limitations of early cc? I seem to recall at least one document from that period (I think pertaining to the so-called 'Typesetter C') about 'changes to C'. Also, I have started a note with a list of 'issues with C when you're backporting V7 and later code to V6', I'll see if I can dig them out tomorrow. Noel

10 years, 8 months

5
7
0 0

3BSD/32V: 2 RP06 (SIMH)

by Cory Smelosky

Afternoon, # /etc/mkfs /dev/rrp1g 145673 isize = 65488 m/n = 3 500 write error: 2 # file rp0g rp0g: block special (0/6) # file rp1g rp1g: block special (0/14) # file rp0a rp0a: block special (0/0) # file rp1a rp1a: block special (0/8) # file rrp0a rrp0a: character special (4/0) # file rrp1a rrp1a: character special (4/8) # file rrp0g rrp0g: character special (4/6) # file rrp1g rrp1g: character special (4/14) DESCRIPTION Files with minor device numbers 0 through 7 refer to various portions of drive 0; minor devices 8 through 15 refer to drive 1, etc. The origin and size of the pseudo-disks on each drive are as follows: What am I forgetting? I have an image attached, I have modified hp.c to have NHP as 2. Is it conflict between rp.c and hp.c? (I patched hp.c to have NHP 2 after patching NURP in rp.c to be 2). -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

10 years, 8 months

1
0
0 0

Re: [TUHS] early cc variable and function names

by jnc＠mercury.lcs.mit.edu

> From: jnc(a)mercury.lcs.mit.edu (Noel Chiappa) >> Did anyone document these sorts of limitations of early cc? > I seem to recall at least one document from that period (I think > pertaining to the so-called 'Typesetter C') about 'changes to C'. > ... > I'll see if I can dig them out tomorrow. OK, there are three documents which sort of fall into this class. First, there is something titled "New C Compiler Features", no date, available here: http://minnie.tuhs.org/cgi-bin/utree.pl?file=Interdata732/usr/doc/cdoc/news… no date, but it appears to describe an early version of the so-called 'Typesetter C', mentioned in other documents, so this would be circa 1976 or so. There is a second document, untitled, no date, which I have not been able to locate online at all. I scanned my hard-copy, available here: http://ana-3.lcs.mit.edu/~jnc/history/unix/CImprovements1.jpg .. http://ana-3.lcs.mit.edu/~jnc/history/unix/CImprovements5.jpg >From the content, it seems to be from shortly after the previous one, so say, circa 1977. Sorry about the poor readability (it looked fine on the monitor of the machine my scanner is attached to); fudging with contrast would probably make it more readable. When I get the MIT V6 Unix tapes read (they have been sent off to a specialist in reading old tapes, results soon, I hope) I might be able to get more info (e.g. date/filename), and machine-readable source. Finally, there is "Recent Changes to C", from November 15, 1978, available here: http://cm.bell-labs.com/cm/cs/who/dmr/cchanges.pdf which documents a few final bits. There is of course also Dennis M. Ritchie, "The Development of the C Language", available here: http://cm.bell-labs.com/who/dmr/chist.html which is a good, interesting history of C. > Also, I have started a note with a list of 'issues with C when you're > backporting V7 and later code to V6' I found several documents which are bits and pieces of this. http://ana-3.lcs.mit.edu/~jnc/history/unix/C_Backport.txt http://ana-3.lcs.mit.edu/~jnc/history/unix/V6_C.txt Too busy to really clean them up at the moment. Noel

10 years, 8 months

1
0
0 0

ISPS

by luca.nini

Back in the 80s in my University days I was using ISPS (Instruction Set Processor Simulator if I remember correctly ) a software tool To simulate CPU. It ran on a Vax with BSD 4.2. I have been unable to find any reference to It on the Internet . Do someone on this list know anything offerte this software ? Thanks Luca

10 years, 8 months

4
4
0 0

Re: [TUHS] Getting Unix v5 to talk

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge > Fortunately we have the file /usr/sys/dmr/vs.c to look at so this could > be compiled into the kernel although I haven't done this as yet. The vs.c seems to be a Votrax speech synthesizer hooked up to a DC11 interface. Do any of the simulators support the DC11? If not, adding the driver won't do you much good. Noel PS: I seem to recall the DSSR group on the 4th floor at LCS actually had one of these, back in the day. The sound quality was pretty marginal, as I recall!

10 years, 8 months

1
0
0 0

Getting Unix v5 to talk

by Mark Longridge

Thanks to the efforts of Jonathan Gevaryahu I have managed to get the Unix v5 speak utility to compile and execute. All this was done using the simh emulator emulating a PDP-11/70. Jonathan managed extract enough of speak.c to reconstruct it to the point it could be compiled with v5 cc. I believe it was necessary to look at speak.o to accomplish this. Jonathan also states that there are more interesting things that could possibly be recovered from v6doc.tar.gz One can look at speak.c source here: http://www.maxhost.org/other/speak.c Now had we have speak compiled we can go a bit further: cat speak.v - | speak -v null generates speak.m from ascii file speak.v speak speak.m computer !p (prints out phonetics for working word) which outputs: ,k,a0,m,p,E2,U1,t,er,-1 ctrl-d exits Looking at speak.c we can see that it opens /dev/vs. Fortunately we have the file /usr/sys/dmr/vs.c to look at so this could be compiled into the kernel although I haven't done this as yet. speak.c looks like Unix v5 era code. My understanding is that Unix v5 appeared in June 1974 and the comments say 'Copyright 1974' so it seems plausible. I'm intrigued by the possibility of getting Unix v5 to talk. Mark

10 years, 8 months

1
0
0 0

Codata restoration - day 1

by Engel, Michael

Hi, after carefully examining the power supply and checking the generated voltages, we were convinced that this wouldn't kill our Multibus boards. Maybe some of you are interested in our progress, so I though I would send you an update. After reconnecting the Multibus backplane, we started the system with only a CPU board and a memory board. On one of our CPU boards the smaller (P2) Multibus connector is masked with tape, I'll have to dig deeper to find out what is deactivated by this… One of our two CPU boards is currently non functional (the one without the masking take, this doesn't say a thing on the console UART, will bring in the scope in Monday to check for details). The other one brings up the monitor startup message and prompt on a connected serial terminal (emulator) - however, we are unable to get any characters echoed back. The serial cable is working, we tried all sorts of handshake configurations. If we get any characters back (the system is running at 9600 baud, I tried all combinations of 7/8 bit, none/even/odd/mark/space parity and 1/2 stop bits), these are garbled and contain mostly "1" bits (0xfc, 0xfe, 0xff or similar). The UART itself seems to work (exchanged it with the one from the non working board - same result), so now I suspect the AM26LS32 RS423 driver to be the culprit. I uploaded some pictures to http://s1372.photobucket.com/user/michaelengel/library/Codata?sort=3&page=1 - there you can see that this machine is far from being in any sort of original condition. Nevertheless, it's great to see it come alive again! Btw., current versions of MAME/MESS include a rudimentary Codata simulator. This doesn't do very much so far, but it can successfully run the firmware ROM code (picture also uploaded to photobucket). Best wishes, Michael

10 years, 8 months

6
7
0 0

Re: [TUHS] 2.9bsd on 11/45 restoration

by Johnny Billquist

On 2014-10-07 03:00, norman(a)oclsc.org (Norman Wilson) wrote: > > The 11/70 service manual is all good, but it's definitely not enough. > Ideally, you should have access to the full drawings, the service manual > for the CPU, the service manual for the memory subsystem, I seem to > remember that the FP11 has its own service manual, and I think the > massbus interface also has its own documentation set. > Also, the memory system consists of both the Unibus map, the cache and > memory bus system, and they you have separate documentation for the > memory boxes (either MJ11 or MK11 box). > > It might be worth while to contact the Living Computer Museum. > I forget whether they have an 11/70 running or just an 11/45, > but I do know that they collect all the documentation they can > get for old computers--I saw the room where they store it. > Whenever they need to use it, or there's some other need to > access it, they try to make time to scan it, so the precious > copy can stay in the archive room. LCM have atleast one 11/70 running. Although they are not really doing anything fun on it. I hope to maybe help them with that next time I'm there. I can't remember seeing any 11/45 running, but I'm pretty sure there are some in their storage if nothing else... I'm not going to try dragging a lot of documentation from Sweden to Seattle, though (I'm not even in Sweden myself lots of the time). On the other hand, I know they have plenty of documentation, so I would hope they (and/or CHM) already have most of it. > Since their goal is to have ancient computers actually > running, they are certainly interested in having all the > documents (even if you can't get the wood, as Warren might > remark at this point), including full engineering drawings. > > It's also a neat place to visit if you have some free time in > Seattle. I'm disappointed to have figured out that, although > I'll be in Seattle for a conference in about a month, I won't > be able to visit LCM while they're open unless I skip some > conference sessions ... or unless I can convince them to open > up specially. Anyone else on this list planning to attend > LISA and interested in visiting a museum of old running > computers? I know of the place, and have known Rich Alderson for a long time. It is a fun place, and I could see myself working there, if I just had the right offer. Don't expect that to happen, though... I'll be there for different reasons in about a month from now. But my weekends are free... :-) Johnny

10 years, 9 months

1
0
0 0

2.9bsd on 11/45 restoration

by Warren Toomey

Also, I had this e-mail sent to me from Jacob who is a long-time TUHS person. Again, he has questions I don't know the answers to. Anybody? Cheers, Warren ----- Forwarded message from Jacob Ritorto ----- Greetings Warren, Â It's been decades since we last corresponded and I'm delighted to see that you're still active in the pdp11 unix community!Â I've found some free time and have been kicking around the idea of repairing the11/45 I scored some years ago (11/45 system number 273 from Stanford University) and installing 2.9bsd on it.Â You helped me out years ago when I had an 11/34 and I managed to do it back then, so I have some hope this time around too, though there are some more serious hurdles now.Â Glad to see that a lot of the license trolling finally appears to be settled and we can have unfettered access to all the good stuff! Â Â Any pointers to who has parts and troubleshooting knowledge would be a big help. Â Softwarewise, I was also thinking I'd like to get my Fuji160 disks working on the machine.Â Has work like this been done already, or would you have pointers as to how to go about it? Â Â Also, has anyone written a miniature httpd for any of the ancient bsds? thanks jake ----- End forwarded message -----

10 years, 9 months

3
2
0 0

Re: [TUHS] 2.9bsd on 11/45 restoration

by norman＠oclsc.org

The 11/70 service manual is all good, but it's definitely not enough. Ideally, you should have access to the full drawings, the service manual for the CPU, the service manual for the memory subsystem, I seem to remember that the FP11 has its own service manual, and I think the massbus interface also has its own documentation set. Also, the memory system consists of both the Unibus map, the cache and memory bus system, and they you have separate documentation for the memory boxes (either MJ11 or MK11 box). It might be worth while to contact the Living Computer Museum. I forget whether they have an 11/70 running or just an 11/45, but I do know that they collect all the documentation they can get for old computers--I saw the room where they store it. Whenever they need to use it, or there's some other need to access it, they try to make time to scan it, so the precious copy can stay in the archive room. Since their goal is to have ancient computers actually running, they are certainly interested in having all the documents (even if you can't get the wood, as Warren might remark at this point), including full engineering drawings. It's also a neat place to visit if you have some free time in Seattle. I'm disappointed to have figured out that, although I'll be in Seattle for a conference in about a month, I won't be able to visit LCM while they're open unless I skip some conference sessions ... or unless I can convince them to open up specially. Anyone else on this list planning to attend LISA and interested in visiting a museum of old running computers? Norman Wilson Toronto ON

10 years, 9 months

1
0
0 0

Re: [TUHS] 2.9bsd on 11/45 restoration

by Johnny Billquist

On 2014-10-05 03:00, Dave Horsfall<dave(a)horsfall.org> wrote: > > On Sat, 4 Oct 2014, Noel Chiappa wrote: > >> >Anyone seriously working on bringing old hardware back to life needs to >> >get in touch with the Classic Computer Talk list: > Is John Dodson on this list? He has an 11/70 in his house. No idea. I occasionally scan cctalk, but most of the time don't bother. Too much noise and irrelevant or ignorant posts. However, unfortunately I don't have any better suggestions where to go if you are trying to restore old hardware and don't have enough knowledge. And yes, I keep lots of different PDP-8, PDP-11 and VAXen running, including 11/70 systems. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

10 years, 9 months

2
2
0 0

Re: [TUHS] 2.9bsd on 11/45 restoration

by random832＠fastmail.us

On Sun, Oct 5, 2014, at 13:47, Jacob Ritorto wrote: > awesome, man, thanks. If I fork tinyhttpd on github, mind if I use 'em? > I'll attribute to you of course If ok, any license preference? I > usually > use MIT.. tinyhttpd itself is not mine and appears to be under the GPL.

10 years, 9 months

1
0
0 0

Re: [TUHS] 2.9bsd on 11/45 restoration

by random832＠fastmail.us

On Sat, Oct 4, 2014, at 12:37, Jacob Ritorto wrote: > nice. may i see your difffs? > > On Sat, Oct 4, 2014 at 4:06 AM, <random832(a)fastmail.us> wrote: > > > > Seeing this question, I figured "it can't be that hard", and managed to > > get tinyhttpd http://tinyhttpd.sourceforge.net/ to compile on 2.11BSD. > > Mostly just required K&R-ification, though I also had to fix some bugs > > in the way it uses buffers to get it to work at all. Normal GET requests > > work; The whole CGI thing I disabled because I couldn't get it to work > > reliably even on modern linux. > > > > Not actually tested, though - I couldn't get simh to emulate a network > > device. Sure. Security note: the httpd itself doesn't appear to do anything about e.g. ".." in pathnames, and I didn't do anything about that.

10 years, 9 months

1
0
0 0

RL02 drives available

by jnc＠mercury.lcs.mit.edu

Some guy on eBay has a flock of RL02 drives available (in New York, USA) for a pretty reasonable price: http://www.ebay.com/itm/261288230510 I just bought a flock of them, and they are in very good condition. They were only recently withdrawn from service (at the FAA, so they were professionally maintained up until they went), and were properly prepared for moving (heads immobilized, _and_ the motor was locked down - very rare to see that last step, as is involves finding the right machine screws - or having saved them). They are late-production ones, too (looked, but couldn't find a date) - they have the anti-RFI/EMI 'finger' strips (the kind that make a pressure-loaded contact with the incoming connector shell), which I personally had never seen on any RL0x drives. Alas, they have no packs or terminators available, nor cables or slides (any more :-). But other than that, recommended. Noel

10 years, 9 months

2
1
0 0

Re: [TUHS] 2.9bsd on 11/45 restoration

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey <wkt(a)tuhs.org> >> have been kicking around the idea of repairing the11/45 I scored some >> years ago (11/45 system number 273 from Stanford University) >> .. >> Any pointers to who has parts and troubleshooting knowledge would be a >> big help. Anyone seriously working on bringing old hardware back to life needs to get in touch with the Classic Computer Talk list: http://www.classiccmp.org/mailman/listinfo/cctalk A wealth of experience and knowledge on every conceivable topic involved in old hardware is available there, and people are very helpful. Noel

10 years, 9 months

2
1
0 0

Re: [TUHS] Unisoft V7 68k sources (reviving a Codata machine)

by Steve Simon

> The machine is a Codata 300 Wow. I went to Leeds Poly (as it was then) in the mid 1980s. There where two Codatas in the electronics dept., one in its original plastic case and one 19inch rackmount - built as a IEEE 488 controller; I assume what you have is one of those. The former machine was loaded with Whitesmiths cross compilers and I learnt z80 assembly language on it ☺ It ran V7 indeed, and was a friend of the Interdata/Perkin Elmer 3210, the main electronics teaching machine. If it is this machine then it should have the V7 source from the 3210 (Xelos as it was called) and the source for the drivers for the codata (which we gained by "accident"). I may be able to remember some other snippets - contat me off-list with specific questions. I can give you the names of the lecturers who would know most about it but I guess they are now retired (though they may still be Headingly somwhere). (fondly remembers Leeds). -Steve

10 years, 9 months

2
1
0 0

made up errno contest, at an early USENIX

by Aharon Robbins

Hi All. This is really gonna stretch the memories. (I may have even asked about it on this list before.) At one of the earlier USENIX conferences that I attended, maybe in Atlanta, there was a contest to make up humorous new errno values. The one that won, which I remember to this day was: EMISTERED: A host is a host from coast to coast, and no-one can talk to host that's close, unless the host that isn't close is busy, hung, or dead. I have quoted this is the gawk doc for many years. I'm wondering if there is a way to find out who was the author of this gem? I'd like to give him/her credit. Thanks, Arnold

10 years, 9 months

10
16
0 0

Unisoft V7 68k sources (reviving a Codata machine)

by Warren Toomey

I just received a new TUHS subscription request along with an interesting query. Can anybody help Michael with his problem? Cheers, Warren ----- Forwarded message from "Engel, Michael" ----- Dear Warren, Could you please subscribe me to the TUHS mailing list? I haven't worked with old Unix systems for quite some time, but I was appointed as a Senior Lecturer at Leeds Beckett University (UK) two months ago and - to my big surprise - I found an old Unix machine collecting dust in a corner.. The machine is a Codata 300, a Multibus-based system using a licensed clone of the original Sun 100U CPU board and a number of additional Multibus controllers. The machine seems to be complete, including two 8" SMD disks and a Cipher 9-track tape drive, we also seem to have a set of replacement boards and the CPU board manual (including schematics and code snippets explaining how to access the onboard devices - some Codata documentation can also be found on bitkeeper). We haven't tried to power up the machine yet (and, built around 1983, it certainly needs a close examination of the power supply and capacitors). From information on the net, this machine runs a Unisoft port of 7th Edition Unix - similar to the Sun 1 machines and probably a Whitesmiths C compiler (there's a Whitesmiths license badge attached to the case). Definitely a very interesting and probably quite rare machine and we would like to revive it (and, if things go well, create a FPGA reimplementation of the system in the context of a student design project). Now, I would love to know more details about the implementation of 7th Edition Unix on the 68000 and the use of the custom MMU built out of fast SRAM and TTL logic. I do not think that source code to any of the various 68k 7th Edition ports produced by Unisoft is available somewhere - do you know of a possible source? Alternatively, do you think it would be worthwhile asking Unisoft for the source code or do you know if anyone has tried this already? According to the Unisoft history web page (http://www.unisoft.com/history.html) they still seem to know that they were porting Unix 30 years ago... The only remotely related source code I could find in my archives is the A/UX 0.7 source (SVR2, if I'm not mistaken), which probably already required a 68020 with 68851 MMU. Best regards, Michael Engel ----- End forwarded message -----

10 years, 9 months

2
1
0 0

Re: [TUHS] made up errno contest, at an early USENIX

by norman＠oclsc.org

arnold(a)skeeve.com: Can you grep for EMRED? (Doesn't match ENO). ==== Why not grep for E[A-Z][A-Z]*? Norman Wilson Toronto ON

10 years, 9 months

1
0
0 0

Re: [TUHS] TMG and B

by jnc＠mercury.lcs.mit.edu

> From: arnold(a)skeeve.com > it was clear at the time that UNIX and what was happening was extremely > special .. Those of you who were there really were part of a "golden > age". I once observed to Jerry Saltzer that when I started at the MIT CS labs, I had been bummed because I had missed what I considered their 'Golden Age' - the work on CTSS and Multics. When I showed up there, I did a deal where they let me use a PDP-11/40 to explore some OS ideas I had, if I woule write diagnostics on it for a ring interface they were working on - part of a project on networking that included work on something called internetworking. I had no idea what I was getting into! And of course the networking work soon sucked me in completely. In that message to Jerry, I said something to the effect of 'clearly I've lived through a second golden age, and only now am I understanding that'. Noel

10 years, 9 months

6
8
0 0

Re: [TUHS] TMG and B

by Doug McIlroy

TMG was in v2-v6, sometimes in man1 and sometimes in man6. I have an apparently complete source listing. The year is uncertain. (Back then date headings from pr didn't mention the year!) The accompanying manual, though, is dated 1972. There is also, besides the TMGL definition of TMGL, a TMGL definition of pig Latin as a simple test case. None of this is useful, though, without a PDP-11 binary for tmg-- the usual chicken-and-egg problem with a full-blown compiler written in its own language. Doug > >Speaking of TMG, is there an implementation for FreeBSD/Mac/Linux? Or do > > I have to find a CDC/PDP-7 emulator first? :-) > > > >-- Dave > > TMG is mentioned in the v3 manual: > > /sys/tmg/tmgl.o -- the compiler-compiler > > There's no files for it for v5 but it is in v6 and it seems to > disappear after that. > On TUHS V6/usr/source/tmg/tmgl.t would seem to be a source file. > > I did manage to get something running for pdp-7 on simh and got to the > GA prompt. > Didn't get it to do much beyond printing "CAB DECSYS7 COPY 15 JUNE 1966" > > Mark

10 years, 9 months

2
1
0 0

Re: [TUHS] TMG and B

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy <doug(a)cs.dartmouth.edu> > None of this is useful, though, without a PDP-11 binary for tmg There seems to be be binary for TMG on the V6 distribution. Noel

10 years, 9 months

1
0
0 0

Fwd: [tz] Time, Clock, and Calendar Programming In C, by Eric S. Raymond

by random832＠fastmail.us

Eric S. Raymond has written an article about the history of the time.h functions at http://www.catb.org/esr/time-programming/ >From his blog post announcing it (http://esr.ibiblio.org/?p=6311) > The C/UNIX library support for time and calendar programming is a nasty mess of historical contingency. I have grown tired of having to re-learn its quirks every time I’ve had to deal with it, so I’m doing something about that. > > Announcing Time, Clock, and Calendar Programming In C, a document which attempts to chart the historical clutter (so you can ignore it once you know why it’s there) and explain the mysteries. > > What I’ve released is an 0.9 beta version. My hope is that it will rapidly attract some thoroughgoing reviews so I can release a 1.0 in a week or so. More than that, I would welcome a subject matter expert as a collaborator. When I saw it I thought it might be generally interesting to people who subscribe to this list.

10 years, 9 months

1
0
0 0

Re: [TUHS] TMG and B

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy <doug(a)cs.dartmouth.edu> > Sorry for straying from direct Unix history Au contraire. This was a fascinating account, and very valuable to have it noted down for history. Please stray like that anytime you feel like it! :-) Noel

10 years, 9 months

3
2
0 0

TMG and B

by Doug McIlroy

scj wrote: > There was a compiler/compiler in use at the Labs, imported I think by Doug > McIlroy, called TMG. Sorry for straying from direct Unix history, but this remark spurred a lot of memories. TMG (from "transmogrify", defined in Webster as "to change or alter, often with grotesque or humorous effect") was imported from Bob McClure, erstwhile Bell Labs person, then at Texas Instruments. And an interesting import job it was. McClure had written TMG for the CDC 1604 in machine language. He sent me green coding sheets hand-transliterated into 7090 code. Interesting debugging: one knew that the logic of the code was sound, but the opcodes might not always be right. Sometimes, for example, the wrong one of the two accumulator-load instructions, CLA and CAL, was used. Clem Pease converted TMG to the GE 635 for Multics by the artifice of defining 7090 opcodes as 635 macros--sometimes many instructions long to slavishly emulate the 7090's peculiar accumulator (which mixed 38-bit sign-magnitude with 37-bit twos-complement and 36-bit ones-complement arithmetic). It's amusing to speculate about the progressive inflation of TMG had McClure sent me a similar translation for the 7090. TMG had a higher-level language written in TMG, which evolved during the Multics project into something considerably more elaborate than McClure's original, including features like syntax functions, e.g. seplist(a,b) denoted a sequence of a's separated by b's, for arbitary syntactic categories a and b. Syntax functions took TMG beyond the domain of context-free languages. Multics was to be written in PL/I, a compiler for which was commissioned from Digitek. They had brilliant Fortran technology, but flubbed PL/I. When it appeared that the Digitek compiler was hopeless, Bob Morris proposed that we write a quick and dirty one in TMG. Despite being slow (an interpreter running on an emulated 7090) and providing only three diagnostics, this compiler carried the project for a couple of years. When Unix came along, we were again faced with how to bootstrap TMG across machines. This time I wrote a bare-bones interpreter in PDP7 assembler, then by stages grew the language back to the Multics state. Ken, in a compliment I still treasure, once called this the most amazing program on the original Unix machine. I believe TMG was involved in the initial evolution of B, but the real tour-de-force in B was the ability of an interpreted version to exploit software paging and transcend the limited memory of the PDP-11. The following scenario was to be repeated several times in the early days of Unix. When the native version of B ran out of steam, the interpreted version would be used to introduce some new optimization that would squeeze the native version back to fit. (Bigger input, smaller output!) Subsequently we saw the same thing happen with C and the kernel. When the kernel grew too big, a new optimization would be introduced in C to squeeze it. (And to squeeze the compiler, too. The compiler, though, never enjoyed B's advantage of being able temporarily to run in a bigger arena.) Doug

10 years, 9 months

2
1
0 0

yacc for Unix v5

by Mark Longridge

I've been looking into the history of yacc (yet another compiler compiler). The earliest reference I can find is the man page for yacc from v3 which indicates that yacc was written in B language. The files actn.b and /crp/scj/bigyacc are mentioned. No luck so far in locating those files. There is a man page for v4 which is very brief. There is a yacc executable for v5 but so far I haven't found any v5 era code that works with it. My attempts to compile bc.y from v6 using yacc from v5 were not successful. Also the source code for yacc in v5 is missing. On a happier note I was able to use yacc and cc to regenerate the bc calculator in v6. It needed a fair amount of swap space to compile otherwise an "Intermediate file error" will occur. It seemed to require at least 300 blocks of hard drive space. It's a bit mysterious what the Unix v5 yacc was used on. It predated bc and expr. There's no v5 era *.y files available to look at. Mark

10 years, 9 months

2
1
0 0

where is ecvt?

by Mark Longridge

I've been comparing Unix v5 libc to modern linux and various other Unix versions and I found something odd. I made a list of functions which occur in Unix v5 libc.a and modern linux glibc.a and while there is no problem using the ecvt function in modern linux it doesn't seem to appear: ar t /usr/lib/libc.a | grep ecvt ...doesn't find ecvt. But if you do: grep ecvt /usr/lib/libc.a then Binary file /usr/lib/libc.a matches So it seems it is in there somewhere. While searching for ecvt.c I found it as part of openbsd. I assume in modern Linux ecvt must be part of a larger function but I couldn't find it in the glibc source. Of course in Unix v5 things were completely straightforward as TUHS has the file V5/usr/source/s3/ecvt.s I just want to find all the functions that are still in modern glibc.a which also existed in Unix v5 libc.a

10 years, 9 months

6
6
0 0

Re: [TUHS] Teletype

by John Foust

At 01:04 PM 8/15/2014, Brian Zick wrote: >Would it still be possible today for someone like me to go out, and find an old teletype terminal (an old ASR or DECwriter or something), set up a phone line and modem and get a roll of paper, and then actually use it to connect to other computers? Yes, lots of people do it. There is a "Greenkeys" mailing list http://mailman.qth.net/mailman/listinfo/greenkeys populated by mostly ham radio RTTY types, but it's also a great archive of posts about hook-ups and repairs. Yes, there are current-loop adapters and RS-232 to USB adapters that can be used to connect to contemporary machines. There are also streaming audio web sites that send RTTY-style signals if you'd like to emulate your old radio over the Internet but still use your RTTY audio decoding hardware. There's also a fellow http://aetherltd.com/ who connects even older teletype hardware to cell-phone texting. The Teletype Model 33 was very popular among early computer users because it was relatively low-priced compared to heavier-duty teletypes. The old RTTY folks tend to look down their nose at it because it wasn't as robust as other models. They routinely huff and puff at recent auction prices for the Model 33, though, as old computer collectors routinely pay $1,000 for them, while it's tough to give away the better-built (and heavier!) teletypes. Last summer I picked up a Western Union-branded Teletype Model 28 KSR (circa mid-1950s) in near-pristine condition for $50. Almost twenty years ago I found a Model 33 in a university dumpster. - John

10 years, 9 months

3
2
0 0

Re: [TUHS] another Web site on computer history

by John Foust

At 07:46 PM 9/8/2014, you wrote: >Traffic this evening on the pcc compiler list <pcc.lists.ludd.ltu.se> >alerted me to the existence of the Software Preservation Group, a >branch of the Computer History Museum, with a Web site at > > http://www.softwarepreservation.org/ Also at http://www.computerhistory.org/groups/spg/ . It's run by Al Kossow: http://www.computerhistory.org/staff/Al,Kossow/ He worked at Apple for a long time. His early years were at UW-Milwaukee. He also frequents the Classic Computer Collector mailing list, a place where you might acquire and learn to repair the old iron. - John

10 years, 9 months

1
0
0 0

UUCP Maps

by Lyndon Nerenberg

The recent UUCP network conversation has me wondering ... is anyone collecting/curating the UUCP maps that represented the way we communicated (outside the ARPANET) from the time of Chesson's paper until the death of comp.mail.maps? Brian Reid's postscript maps were a work of genius; the hand-drawn ASCII maps that predated those are even more wonderful bits of Internet history, let alone art. --lyndon

10 years, 9 months

12
16
0 0

Re: [TUHS] Etymology of bc

by Doug McIlroy

> Speaking of using a pipe to an existing command, I originally mis-read the > code to think there was only _one_ process involved, and that it was buffering > its output into the pipe before doing the exec() itself - something like this: > > pipe(p); > write_stuff(p[1]); > close(0); > dup(p[0]); > close(p[0]); > close(p[1]); > execl("/bin/other", "other", arg, 0); > > Which is kind of a hack, but... it does avoid using a second process, although > the amount of data that can be passed is limited. (IIRC, a pipe will hold at > most 8 blocks, at least on V6.) Did this hack ever get used in anything? I didn't notice anybody commenting on the fact that this hack doesn't work for the purpose--an interactive desk calculator. Running bc then dc serially defeats interactivity. The scheme of filling a pipe completely before emptying it is used in Rob Pike's plan9 editor, sam, to pipe text through some transforming process. Because the transformer (think sort) may not produce any output until it has read all its input, sam can't read the result back until it has finished stuffing the pipe. Of course sam has to create two pipes, not just one, and it happens that the initial writer and ultimate reader are the same. But the basic idea is the same. Doug

10 years, 9 months

1
0
0 0

Etymology of dsw(1)

by Dave Horsfall

Speaking of things etymological, I've heard two versions of that for dsw(1). Delete from Switch Register (delete file whose i-num is in CSR) Delete Sh*t Work (same, but expressed a bit more robustly) -- Dave

10 years, 9 months

5
5
0 0

Re: [TUHS] Etymology of bc(1)

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > On the *nix systems to which I have access, bc(1) is a standalone > program on FreeBSD and OSX, but pipes to dc(1) on OpenBSD. I cannot > check my Penguin box (Ubuntu) Dude! Trying to answer questions about the origins of BC by looking at systems this late is like trying to learn Latin by studying Italian! :-) I looked at the Version 6 source, and it's a bunch of YACC code, but it pulls the same technique of using a pipe to an instance of DC, viz: pipe(p); if (fork()==0) { close(1); dup(p[1]); close(p[0]); close(p[1]); yyinit(argc, argv); yyparse(); exit(); } close(0); dup(p[0]); close(p[0]); close(p[1]); execl("/bin/dc", "dc", "-", 0); There's likely even older versions than the V6 one, but that's the earliest source I have online on my PC for easy access. Noel

10 years, 9 months

9
12
0 0

Disassembler

by random832＠fastmail.us

Does anyone know of a good PDP-11 disassembler? -- Random832

10 years, 9 months

5
5
0 0

Etymology of bc(1)

by Christian Neukirchen

Hello, on de.comp.os.unix.shell there is a recent thread about bc(1) which turned into a discussion about why it is called "bc". dc(1) is pretty clearly "desk calculator" as by the man page, but the etymology of bc seems to be unclear. I've heard the following plausible theories: - basic calculator (Wikipedia) - beauty calculator (some people apparently dislike RPN) - better calculator - bench calculator (Wikipedia) - b is the letter d mirrored (RPN vs algebraic) - bundle calculator (the word "bundle" appears 97 times in bc.y of V6) ...but nobody had a really conclusive argument. Perhaps someone here remembers the real story? Thanks, -- Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org

10 years, 9 months

7
8
0 0

Re: [TUHS] Etymology of bc(1)

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge <cubexyz(a)gmail.com> > I have a version of Unix v6 that has a file called /usr/doc/bc that > describes bc at length Oh, right, I missed that. I'm a source kind of person... :-) Speaking of using a pipe to an existing command, I originally mis-read the code to think there was only _one_ process involved, and that it was buffering its output into the pipe before doing the exec() itself - something like this: pipe(p); write_stuff(p[1]); close(0); dup(p[0]); close(p[0]); close(p[1]); execl("/bin/other", "other", arg, 0); Which is kind of a hack, but... it does avoid using a second process, although the amount of data that can be passed is limited. (IIRC, a pipe will hold at most 8 blocks, at least on V6.) Did this hack ever get used in anything? Noel

10 years, 10 months

3
2
0 0

another Web site on computer history

by Nelson H. F. Beebe

Traffic this evening on the pcc compiler list <pcc.lists.ludd.ltu.se> alerted me to the existence of the Software Preservation Group, a branch of the Computer History Museum, with a Web site at http://www.softwarepreservation.org/ I do not recall hearing of it before today, and perhaps a few TUHS list readers have not either. It may be desirable to add a link to it from the Unix block of the http://minnie.tuhs.org/ site. I think that it could also be good to record a link to the Bitsaver's site at http://bitsavers.trailing-edge.com/ and to make a list of TUHS mirrors more prominent (e.g., we have one at http://www.math.utah.edu/mirrors/minnie.tuhs.org/ ). ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

10 years, 10 months

1
0
0 0

networking on unix before uucp

by Mark Longridge

Hi folks, I was wondering if Unix had any form of networking before uucp appeared in Unix v7. It would be interesting to know if one could pass a file from one Unix v5 machine to another without having to store it on a magnetic tape. There's some reference to a mysterious "Spider Interface" in the Unix v5 manual. It seems to have something to do with DR-11B (which is a general purpose direct memory access interface to the PDP-11 Unibus). There's also reference to the "Spider line-printer" :) Mark

10 years, 10 months

13
23
0 0

Re: [TUHS] networking on unix before uucp

by jnc＠mercury.lcs.mit.edu

> From: "Jeremy C. Reed" <reed(a)reedmedia.net> > Later, they considered an LNI, an early token ring (if I understand > correctly), device Yes. See: http://ana-3.lcs.mit.edu/~jnc/history/RingMIT.txt for more - that's a pre-print version of an article just published in the _IEEE Annals of the History of Computing_; slight differences with the final version, but nothing significant. Thumbnail: There were two versions; V1 was 1MBit/second, produced in very limited numbers (~10 or so) at MIT, most used there, although IIRC correctly at pair (at least - one would be of no use :-) went to UCLA (I remember flying out to LA to help them get them going). V2 was 10Mbit/second, produced as a commercial product by Proteon in cooperation with MIT, large numbers sold. Noel

10 years, 10 months

1
0
0 0

Re: [TUHS] networking on unix before uucp

by Jason Stevens

The 3b1 emulator now kind of boot!.. There is some issues with stuff, but for the most part, it works http://virtuallyfun.superglobalmegacorp.com/?p=4149 -----Original Message----- From: arnold(a)skeeve.com [mailto:arnold@skeeve.com] Sent: Tuesday, August 26, 2014 2:17 PM To: lyndon(a)orthanc.ca; lm(a)mcvoy.com Cc: rob(a)bolabs.com; tuhs(a)minnie.tuhs.org Subject: Re: [TUHS] networking on unix before uucp Larry McVoy <lm(a)mcvoy.com> wrote: > On Mon, Aug 25, 2014 at 01:00:45PM -0700, Lyndon Nerenberg wrote: > > It was quite astounding to see the wide range of performance impacts > > this had on various systems. 3B* systems would tip over and die, except > > for the (built by Convergent Tech) 3B1. > > Sheesh, you people keep bringing up stuff from my past. My buddy Rob > Netzer (used to be a prof at Brown, now works on BitKeeper with me) > had one of those 3B1s. Neat machine. Sort of like a desktop VAX. I had one too. (Also a trailblazer and then a worldblazer.) The 3B1 ran SVR2; the BSD networking was available as an add-on with the ethernet card. I spent many happy hours working on that box, developing gawk and its documentation; it was slow enough that you could see algorithmic differences, e.g. standard diff vs. GNU diff. It had one of those great AT&T keyboards (as did the blit). The UI wasn't anything special to write home about though. For a while there was a separate 3b1.* set of newsgroups and an archive of stuff at Ohio State; there remains a comp.sys.3b1 group that still has some activity as new people try to revive some of these machines and others who had them help out. Someone was writing an emulator, but I don't think it ever got finished. Ah, the memories .... :-) Arnold _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs

10 years, 10 months

1
0
0 0

Re: [TUHS] networking on unix before uucp

by Larry McVoy

On Mon, Aug 25, 2014 at 08:42:53AM -0600, emanuel stiebler wrote: > On 2014-08-23 22:59, Larry McVoy wrote: > > On Sat, Aug 23, 2014 at 03:32:45PM -0400, Clem Cole wrote: > >> BEGIN - old guy's memories .... > > > > I see your old guy memories and "raise" my sort of old guy memories. > > This is a bell labs blit story. It relies heavily on 7 bit clean stuff. > > I'm not entirely sure this ever worked reliably but here is what we did. > > > > I was a grad student at UW Madison and shared an office with > another guy. We > > had a serial line to the computing center across the street. We > had a blit, > > loved it. We wanted two. > > Any chance, you still have any software for the BLIT? Nope, all we were doing was muxing a serial line and that was 8051 assembler. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

10 years, 10 months

6
10
0 0

Re: [TUHS] networking on unix before uucp

by Brian Walden

Doug McIlroy wrote: > > I was wondering if Unix had any form of networking before uucp > > Right from the time Unix came up on the PDP-11 it was > networked in the sense that it had dial-in and dial-out > modems. Fairly early on, when Unixes appeared in other > Bell Labs locations, Charlie Roberts provided a program > for logging into another machine. It had an escape for > file transfer, so it covered the basic functionality > of rsh and ftp. It was not included in distributions, > however, and its name escapes me. Maybe scj can add > further details. > > Doug Are you thinking of the cu (call unix) command? But that was included in v7, and don't think it was part of uucp. The escape was ~ So a ~. to hangup, ~%put to send a file to the remote and ~%take to get one, and ~~ to send a ~ later on, there was a ct (call terminal) command, expecting a terminal at the end of phone line instead of another machine.

10 years, 10 months

4
3
0 0

Re: [TUHS] networking on unix before uucp

by Larry McVoy

On Sat, Aug 23, 2014 at 07:01:40AM +1000, Dave Horsfall wrote: > On Fri, 22 Aug 2014, Larry McVoy wrote: > > > If anyone wants the stuff we use, the stuff mentioned above, I can put > > it up on the web. > > Pretty please! For private use only, of course. You'all can use it anywhere you like. http://www.mcvoy.com/lm/tcp.shar It's not that big a deal (other than 20 years of bug fixes :) Somewhere I have a bigger deal, at least I think it is, I made a library to talk to Sun RPC servers in parallel. I called it rpc vectors and Ron Minnich used it to put a bunch of nfs servers together, he called that bigfoot. Paper below, if someone wants that code I can ship that too. It was pretty neat, back in the days of 10Mbit ethernet I was querying thousands of machines in a single call. The code dealt with the fact that you had to start eating the replies before you were done sending the question :) http://wenku.baidu.com/view/797c4ac62cc58bd63186bd1c.html or for old school people http://www.mcvoy.com/lm/bitmover/lm/papers/bigfoot.ps The code was pretty small, pretty clever, it's a shame it didn't catch on. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm

10 years, 10 months

1
0
0 0

Re: [TUHS] TUHS Digest, Vol 115, Issue 29

by Doug McIlroy

> I was wondering if Unix had any form of networking before uucp Right from the time Unix came up on the PDP-11 it was networked in the sense that it had dial-in and dial-out modems. Fairly early on, when Unixes appeared in other Bell Labs locations, Charlie Roberts provided a program for logging into another machine. It had an escape for file transfer, so it covered the basic functionality of rsh and ftp. It was not included in distributions, however, and its name escapes me. Maybe scj can add further details. Doug

10 years, 10 months

1
0
0 0

Re: [TUHS] networking on unix before uucp

by jnc＠mercury.lcs.mit.edu

> From: Dan Cross <crossd(a)gmail.com> > Unix was on the ARPAnet circa 1975 (if not earlier): > http://tools.ietf.org/html/rfc681 Good catch; I didn't know of that document. There is a later, more extensive document (set) about it, "A Network Unix System for the ARPANET", but that's from several years later, and doesn't include anything about the history of the implementation. > it's entirely possible that the ARPAnet Unix work was done before V6 > ... > if I had to hazard a guess I'd say they were running V5; perhaps > heavily patched. The RFC says this (translated to lower case since the all-upper made my eyes hurt :-): FOr further information concerning the different I/O calls the reader is directed to The Unix Programmer's Manual, Fifth Edition, K. Thompson, D. M. Ritchie, June 1974. which I think makes it pretty definitive... Noel

10 years, 10 months

1
0
0 0

Re: [TUHS] networking on unix before uucp

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge <cubexyz(a)gmail.com> > I was wondering if Unix had any form of networking before uucp appeared > in Unix v7. In general, no, but I know of a number of networked Unixes prior to V6. ISTR that there were a number of Unixes attached to the ARPANET; I know at least one (at UIllinois) was - that was a V6 machine. There were several different TCP/IP implementations done under V6; the UIllinois guys did one (in C), BBN did one (by Jack Haverty, who ported one done in assembler by IIRC SRI), and one was done at MIT (by Liza Martin, in C). I don't think any of them saw significant deployment. Noel

10 years, 10 months

2
2
0 0

Re: [TUHS] Teletype

by jnc＠mercury.lcs.mit.edu

> From: Brian Zick <brian(a)zickzickzick.com> > The fun of trying to do something in this now novel way is really > great. I was thinking I might try using it for my email. The > news-ticker idea also seems great I suspect you'll find that the charm wears off pretty quickly, if you try and use it for Real Stuff, day in, and day out. There's a reason this technology is not used any more! :-) > I'm really excited that this not only seems possible but nearly in > reach. I share you enthusiasm for the fun of computer archaeology. (Thanks to Milo, I now have an 11/84 that I'm in the process of trying to get up.) Good luck! Noel

10 years, 10 months

1
0
0 0

Re: [TUHS] Teletype

by Brian Zick

On Fri, Aug 15, 2014 at 11:27 AM, Lyndon Nerenberg <lyndon(a)orthanc.ca> wrote: > > On Aug 15, 2014, at 11:04 AM, Brian Zick <brian(a)zickzickzick.com> wrote: > > > Would it still be possible today for someone like me to go out, and find > an old teletype terminal (an old ASR or DECwriter or something), set up a > phone line and modem and get a roll of paper, and then actually use it to > connect to other computers? > > > > I know it's not really practical today - but is it possible? > > Certainly it's possible. Although you would really only be able to do it > with an ASCII terminal. A DECwriter would work fine. For a Teletype > beast, you would need to make sure it used ASCII. But lacking lower case, > I think you would find it too painful to use, even though all the current > versions of UNIX (and Linux) I'm aware of still seem to support the > necessary case conversion in the tty drivers. > Hmm. So for a TTY that old there would probably be no option for lowercase. That does sound a little painful, especially if I wanted to edit modern programs.. > Your biggest obstacle might be finding a host machine that still has a > modem attached that you could dial in to :-) > So perhaps I could simplify it and attach to a machine sitting next to the TTY - which then in theory could connect to the outside world via the usual means. I wonder, has anyone tried something like this? > And, of course, everyone KNOWS the entire universe runs in terminals that > support ANSI escape sequences for colour and cursor positioning. Who needs > termcap? (I'm looking at you, git. And clang.) So you might find setting > TERM=dumb isn't quite enough. > > Also, ed(1) is a wonderful editor on a hardcopy terminal. Unless you run > it on Linux, which KNOWS the whole world runs on 24 line terminal windows, > and therefore ed needs to pause its output. I usually use vim, but before learning vim I learned ed and used it for about a 2 month space for editing config files and things, so that should hopefully be the easy part. :-) Brian Zick zickzickzick.com .:/ ,,///;, ,;/ o:::::::;;/// >::::::::;;\\\ ''\\\\\'' ';\ \

10 years, 10 months

6
6
0 0

Re: [TUHS] Teletype

by jnc＠mercury.lcs.mit.edu

> From: Ernesto Celis <ecelis(a)sdf.org> > I own an USRobotics modem which I've been thinking about connect to the > home server and use it to dial in to get acces to my shell Just out of curiousity, what are you going to dial in _with_? :-) Noel

10 years, 10 months

1
0
0 0

Re: [TUHS] Teletype

by jnc＠mercury.lcs.mit.edu

> From: Brian Zick <brian(a)zickzickzick.com> > Would it still be possible today for someone like me to go out, and > find an old teletype terminal (an old ASR or DECwriter or something), > set up a phone line and modem and get a roll of paper, and then > actually use it to connect to other computers? Well, although I used ASR33's for two years (attached to an 11/20 running RSTS :-), it was a long time ago (I was 15/16 :-), and they aren't something I _really_ know about, but ... Here are some issues you need to watch out for: First, I think most Teletypes used what is called '20mA current loop' serial line electrical interface standard (although some of the later ones could use 'EIA' - the now-usual, although fast disappearing, serial line electrical interface standard). They are logically (i.e. at the framing level) the same, but the voltages/etc are different. The only Teletype I see listed (in a _very_ quick search, don't take this for gospel) that used EIA is the Model 37. So if you get a Teletype Model 33 or 35, and want to plug it into a computer, either the computer is going to have to have an _old_ serial line interface (e.g. DL-11A/C, on a PDP-11), or you're going to have to locate a 20mA/EIA converter (I've never seen such a thing, but I expect they existed). And if you want to plug it into a modem... all modems I ever heard of are EIA (at least, the ones you could plug terminals into - e.g. in most PC modem cards, the serial interface is entirely internal to the card). Second, most of those Teletypes were 110 baud (mechanical hardware limitation). So that means that first, if you plug into a computer, your serial interface has to be able to go that slow. Second, if you're dialing up, you need to find a dial-up port that supports 110 baud. (I would be seriously amazed if any are left...) Of course, if you go with a DecWriter, some of these issues go away, but be careful: some older DecWriters were 20mA too, and the speeds were almost as slow on many (probably 300 baud, but I don't know much about DecWriters). Sorry to be so much cold water, but... As for finding one... I suggest eBay. There's a broken ASR33 there at the moment - if you're _really_ serious, might be worth buying as a parts source. But if you wait, I'm pretty sure one will eventually float by... Noel

10 years, 10 months

5
5
0 0

Teletype

by Brian Zick

Howdy folks - So I'm mostly a lurker here and love the history and the way things used to be done. But being born in '91 I pretty much missed all of it, although I did grow up with 80s machines in the house. There is one thing that I would love to do, and may seem a curious thing to most, but I think about it from time to time, and it's enticing. But I'm not sure where one would get started. Would it still be possible today for someone like me to go out, and find an old teletype terminal (an old ASR or DECwriter or something), set up a phone line and modem and get a roll of paper, and then actually use it to connect to other computers? I know it's not really practical today - but is it possible? Brian Zick zickzickzick.com .:/ ,,///;, ,;/ o:::::::;;/// >::::::::;;\\\ ''\\\\\'' ';\ \ On Fri, Aug 1, 2014 at 8:13 AM, Andy Kosela <akosela(a)andykosela.com> wrote: > > > On Friday, August 1, 2014, Dario Niedermann <dnied(a)tiscali.it> wrote: > >> Tim Newsham <tim.newsham(a)gmail.com> wrote: >> >> > just for fun, you might want to run your >> > ancient unix in simh using this terminal: >> > https://github.com/Swordifish90/cool-old-term >> >> Cool! I've been waiting for ages for something like the Cathode terminal >> emulator >> to appear on Linux too. Cathode is Mac OS X only, unfortunately. >> Homepage: http://devio.us/~ndr/ >> Gopherhole: gopher://retro-net.org/1/dnied/ >> >> > I still prefer my old Digital VT terminal though. Nothing will beat CRT > screen when it comes to low resolution text-only mode. > > --Andy > > _______________________________________________ > TUHS mailing list > TUHS(a)minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > >

10 years, 10 months

4
3
0 0

Re: [TUHS] Teletype

by jnc＠mercury.lcs.mit.edu

> From: John Cowan <cowan(a)mercury.ccil.org> >> if you're dialing up, you need to find a dial-up port that supports >> 110 baud. > I dialed up The World's local dialup line for my area, and heard a > large variety of tones including Bell 103-compatible FSK, which is 300 > baud. I suspect that anything that can do Bell 103 can fall back to > Bell 101, which was 110 baud. There are two more things one needs to have for the port to support 110: i) the serial interface needs to support 110 (even if the modem is integrated with the serial hardware on one board, the serial hardware might not do 110), and ii) the software needs to be willing to go 110. I don't know anything about how contemporary dial-up ports work, so maybe there's some side-channel from the modem to the interface which allows the software to find out directly what speed the modem is using. However, 'back in the day' with multi-speed ports, there was no such mechanism (the RS-232 interface spec didn't provide for speed indication), and one had to hit BREAK and the serial line device driver would see that, and try the next speed in a list. You can still see this in the big table of terminal types in getty.c, e.g.: /* table '0'-1-2 300,150,110 */ which tried 300, 150, 110. So if the software isn't looking for 110... Noel

10 years, 10 months

1
0
0 0

Re: [TUHS] Teletype

by ckeck＠texoma.net

Rats :( :( :( Did they have power supplies, and did they still work? On Fri, 15 Aug 2014, Clem Cole wrote: > Date: Fri, 15 Aug 2014 17:07:28 -0400 > From: Clem Cole <clemc(a)ccc.com> > To: Brian Zick <brian(a)zickzickzick.com> > Cc: "tuhs(a)minnie.tuhs.org" <tuhs(a)minnie.tuhs.org> > Subject: Re: [TUHS] Teletype [...] > > Funny, just this AM, I put into the the electronics recycling box at work 4 > telebit "Worldblazer" modems and a POTS line emulator (and a bunch of other > old junk). I've been clean out my basement and I knew I would never use > those again. > --------------------------------------------- This message was sent using Endymion MailMan. http://www.endymion.com/products/mailman/

10 years, 10 months

1
0
0 0

Re: [TUHS] Unix taste

by norman＠oclsc.org

Doug McIlroy: The single-token rule meant that, if you wanted to supply an option to wc in the pipeline ls > wc > you couldn't write ls > wc -l > as one would expect, but instead had to write ls > "wc -l" > Yet a quoted "wc -l" as a bare command or (I suspect) as the first command in a pipeline would lead to "command not found". What a mess! ====== Then as now, a quoted "wc -l" would be taken by the shell to be a single world, so "wc -l" file would be a request to find a file named "wc -l" (without the quotes but with the embedded blank) somewhere in the search path, and execute it with argv[0] = "wc -l" and argv[1] = "file". But the shell's parser bound only the word following > or < to the operator, so the command had to be quoted (if it had arguments) to make it a single word. So in the old syntax, if you needed to quote an argument of a command that was part of a pipeline but not at the head, you'd have to embed quotes within quotes; e.g. ls > "grep '[0-9]'" > Decidedly a quick hack, just like the original implementation of fork(2) (which was, approximately, swap the current process out, but keep the in-core copy, and give one of the two a new process ID and process-table entry). Though unlike the original fork, the original pipeline syntax was rough enough to be worth fixing early on. As a side note, when I was writing my earlier message, I was going to construct an example using wc -l, until I checked the manual and discovered that when pipelines were invented wc didn't yet take options. I also thought about an example using grep, except grep hadn't appeared yet either. Pipelines (especially once they were attractive and convenient to use) made a bigger difference than we remember in how commands worked and which commands were useful. And of course Doug gets at least as much credit as Ken for changing our lives with all that. Norman Wilson Toronto ON

10 years, 10 months

2
1
0 0

Re: [TUHS] unix v5 limitations

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge <cubexyz(a)gmail.com> > The first problem I had was I couldn't just cp over all the > /usr/source/s1 files to the new drive because of "Arg list too long" John Cowan nailed this; as an aside, I don't know about V5, but in vanilla V6 the entire argument list had to fit into one disk buffer (I would assume V5 is the same). The PWB changes to v6 included a rewrite of exec() to accumulate the argument list in swap space, so it could be much longer; the maximum length was a parameter, NCARGS, which was set to 5120 (10 blocks) by default. Noel

10 years, 11 months

2
1
0 0

rebuilding the unix v5 man pages

by Mark Longridge

Since there's a pdf of the unix v5 man pages I figured I might as well recreate all the necessary files to have man pages in v5. There's a very simple thompson shell script that I used from v6 to create man: if X$2 != X"" nroff man0/naa man$1/$2.$1 if X$2 = X"" nroff man0/naa man1/$1.1 I borrowed the assembly language source from v6 to recreate nroff for v5. After that it was just a matter of matching the date from various files in v4 and v6. If the date was exactly the same for a given man page file I just copied it straight into v5. If the date was different then I used the version in v6 and just edited it until it matched what was shown in the v5 manual pdf. It should also help me figure out a lot of the differences between v5 and v6. When it's all done I'll put the disk images and configuration files on archive.org and post the URL here. I developed a sort of philosophy for adding stuff to unix v5 which goes beyond the v5root.tar.gz files donated by Dennis Ritchie: No changing of cc or as. No changing of the kernel code beyond recompiling the existing v5 code. No changing of the existing device drivers (adding new ones is OK). No backporting of iolib or stdio into v5. No changing libc. Adding userland programs is OK as long as the above rules are followed. Mark

10 years, 11 months

1
0
0 0

Possible way to get more old unix source

by Mark Longridge

Ok, I was just thinking that we have a lack of Unix version 5 (and older) source code but since the Unix v5 era was the era of teletypewriters perhaps there could be a stockpile of old teletype printouts somewhere. Assuming they didn't run out of paper all the time there would have been an automatic record generated of everything Thompson and Ritchie did. Some of those printouts must have been kept somewhere. Mark

10 years, 11 months

3
2
0 0

unix v5 limitations

by Mark Longridge

Firstly, I should mention I'm using simh to simulate Unix version 5. Well I tried to reorganize the files in unix v5. Mainly I wanted more room on rk0 so I figured I'd create a new drive and put all the source from /usr/source/s1 on it. The first problem I had was I couldn't just cp over all the /usr/source/s1 files to the new drive because of "Arg list too long" so I figured I would just create an archive file called all.a which would include all the files in /usr/source/s1 and copy that over. But then I got "phase error" when I tried to keep adding files to the archive (I had to do this in stages, e.g. ar r all.a /usr/source/s1/a* then ar u all.a /usr/source/s1/b* etc). Phase error seemed to occur when the archive got larger than around 160,000 bytes. So I ended up creating 3 archive files to keep from getting "phase error". I was wondering does anyone understand what the limits are for the cp and ar commands? Mark

10 years, 11 months

2
1
0 0

Re: [TUHS] Unix taste

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy <doug(a)cs.dartmouth.edu> > Yet a quoted "wc -l" as a bare command or (I suspect) as the first > command in a pipeline would lead to "command not found". I don't know about earlier versions of Unix, but FWLIW on V6 it does indeed barf in both of these cases (just tried it). Noel

10 years, 11 months

1
0
0 0

Re: [TUHS] Unix taste

by Doug McIlroy

Thanks, Norman, for reminding me of the actual pipe syntax in v3. This reinforces the title of one history item on Dennis's website: "Why Ken had to invent |". I'd suppressed all memory of the fact that in the pipeline ... > cmd > ... cmd had to be a single token. That was certainly not the intent of my original proposal. It is understandable, though, as a minimal hack to the existing shell syntax and its parser, which accepted occurrences of <token and >token anywhere in a command. The single-token rule meant that, if you wanted to supply an option to wc in the pipeline ls > wc > you couldn't write ls > wc -l > as one would expect, but instead had to write ls > "wc -l" > Yet a quoted "wc -l" as a bare command or (I suspect) as the first command in a pipeline would lead to "command not found". What a mess! Soon after, Ken was inspired to invent the | operator, lest he should have to describe an ugly duckling in public at an upcoming symposium in London. Is it possible that the ugliness of the token hack was the precipitating factor that gave us the sublime | ? But for the hack, perhaps we'd still be writing ls > wc > Doug

10 years, 11 months

1
0
0 0

Re: [TUHS] alloc.s is missing from unix v5

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge <cubexyz(a)gmail.com> > In Unix v6 there is a file in the TUHS archives > V6/usr/source/s4/alloc.s > .. > In v5 the command "ar t /lib/libc.a" lists the files in the c library > and that includes alloc.o Well, at least you have the binary. Dis-assembly time! :-) > so there should be a source file somewhere. Ha-ha-ha-ha-HAH! You _are_ an optimist! I'm not joking about the dis-assembly. Not to worry, it's not too bad (I had to do it to retrieve the source for the V6 RL bootstraps - and you've got symbols too), and you've got the V6 alloc.s to guide you - with luck, it did not get re-written between V5 and V6, and you may have minimal (no?) changes to deal with? I don't know which debugger V5 has (db or cdb); if neither, you can spin up a V6 and do the disassembly there. Do "db alloc.o > alloc.s" and then type '0?<RETURN>' followed by a whole bunch of RETURNs. (You can do plain 'db alloc.o' first, to see about how many CR's you need.) Next do a "nm alloc.o" to get as many symbols as you can. At that point, I would extract your prototype alloc.s from the emulated machine so you can use a real editor to work on it. (You should have a way to get files in and out of the simulated machine; that was one of the first things I did with my V6 work: http://www.chiappa.net/~jnc/tech/V6Unix.html although if you're using SIMH I don't know if that has a way to import files - a big advantage to using Ersatz-11, although one I didn't know about when I picked it.) You may need to go back and do a "xxx/" {with appropriate value for "xxx"} plus a few CR's to get static constants, but at that point you should have all the raw data you need to re-create the V5 alloc.s. Obviously, start by having your proto-allocV5.s in one window, and compare with the allocV6.s in another... like I said, you may luck out. The final step, of course, is 'as alloc.s', and then 'cmp a.out alloc.o'. Noel

10 years, 11 months

1
0
0 0

Re: [TUHS] terminal - just for fun

by Doug McIlroy

> Interesting that they had both - I don't remember hearing about the 37 > but that doesn't mean much. :-) The only model 33 on any PDP11 in Bell Labs research was the console. Otherwise all terminals were ASCII devices. Model 37's predated Unix. doug

10 years, 11 months

13
20
0 0

alloc.s is missing from unix v5

by Mark Longridge

Ok, I was trying to understand exactly what the alloc(III) subroutine does in unix version 5 and I've discovered that the source code for it appears to be missing. In Unix v6 there is a file in the TUHS archives V6/usr/source/s4/alloc.s so I assume there should be a V5/usr/source/s4/alloc.s as well but I can't find it anywhere. In v5 the command "ar t /lib/libc.a" lists the files in the c library and that includes alloc.o so there should be a source file somewhere. Mark

10 years, 11 months

1
0
0 0

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by norman＠oclsc.org

Davwe Horsfall: I was surprised when "chdir" became "cd", but I suppose it fits the philosophy of 2-letter commands. ====== Don't forget that the original spelling, in the PDP-7 UNIX that had no published manual, was ch. The 1/e manual spells it chdir. I remember that in one of Dennis's retrospective papers, he remarks on the change, and says he can't remember why. I once asked in the UNIX room if anyone could recall why ch changed to chdir. Someone, I forget who, suggested it was because the working directory was the only thing that could be changed: no chmod or chown in the PDP-7 days. I don't know whether that's true. Norman Wilson Toronto ON

10 years, 11 months

1
0
0 0

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by norman＠oclsc.org

Lyndon Nerenberg: Do you still consider '^' the shell's inter-command pipe character? ====== No. By the time I first used UNIX, | was well-established as the official pipeline character; ^ was just a quirky synonym. I had the impression somehow that ^ was there just to make life easier on the Model 33 Teletype, which had no | key. Digging into old manuals, ^ and | appear simultaneously, in sh(1) in the Fourth Edition. Pipelines first appeared in 3/e, though with a clumsier syntax (not supported by any current shell I know): where we would now type ls | wc the original syntax was ls > wc > The trailing > was required to tell the shell to make a pipeline of the two commands, rather than to redirect output to a file named wc. One could of course redirect the final command's output to a file as well: ls > wc > filecount Even clumsier: where we would now type ls | pr -h 'Look at all these files!' the 3/e shell expected ls > "pr -h 'Look at all these files!'" > because its parser bound > to only the single following word. The original syntax could be reversed too: wc < ls < The manual implies this was required if the pipeline's ultimate input came from a file. Maybe someone with more energy than I have right now can dig out the source code and see. I was originally going to use an example like who | grep 'r.*' | wc -l but the old-style version would be anachronistic. There was no grep yet in 3/e, and wc took no arguments. I do still have the habit of quoting ^ in command arguments, but that's still necessary on a few current systems; e.g. /bin/sh on Solaris 10. Fortunately, that makes it easier to remember to quote ! as well, something required by the clumsy command-history mechanism some people like but I don't. (I usually turn off history but occasionally it gets turned on by accident anyway.) Norman Wilson Toronto ON

10 years, 11 months

1
0
0 0

changes for modern -> v7 -> v6 -> v5

by Mark Longridge

>> From: Mark Longridge <cubexyz(a)gmail.com> >> I thought you folks might be interested in looking at the changes I had >> to make. It was a bit harder than the port to v6 but porting to v6 >> first did make things a bit easier. > To save me from poring over 'diff' output :-), what (at a high level) were > the changes you had to make to get it to run on v5? > Noel Briefly the differences were these: modern to v7: remove all references to void no vi on v7, v6, and v5 so using ed instead. no conditional compilation so no way to make a truly universal version which works on everything. v7 to v6: use iolib instead of stdio: fopen -> copen, fclose -> cclose, fgetc -> cgetc, fputc -> cputc use int (no long or short in v6) call to srand uses different argument copen returns an int instead of a file pointer no strcat in v6 so the function had to be added v6 to v5: no iolib: fopen -> creat + open, copen -> open, cgetc -> read, cputc -> write, cclose -> close no scanf in v5 so I used the source for gets from v7 instead getchar() leaves a newline in the buffer so I added an extra call to getchar() immediately before each call to gets The size of the unirubik executable was 8K for modern Linux, 10K for v7, 10K for v6, and 5492 bytes for v5. Generally I was a lot slower trying to edit files with ed rather than vi but I'm a lot better with ed now. There wasn't really much unix v5 code to look at and I found the v5 manual a bit spartan. Mark

10 years, 11 months

3
2
0 0

terminal - just for fun

by Tim Newsham

just for fun, you might want to run your ancient unix in simh using this terminal: https://github.com/Swordifish90/cool-old-term -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com

10 years, 11 months

16
37
0 0

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by Norman Wilson

Larry McVoy: Looking at git like that is sort of like looking at the size of a dynamically linked app. Ya gotta add in libc and all the extensions people use to make it not suck. ===== In which case one should also add the size of the kernel, or at least the code paths exercised by a given program. Not to mention the layers of window systems, networking, desktops, message buses, name-space managers, programs to emulate 40-year-old terminal hardware, flashy icons, and so on. I say all this to underscore Larry's point, not to dispute it. Everything has gotten more complicated. Some of the complexity involves reasonable tradeoffs (the move toward replacing binary interfaces with readable text where space and time are nowhere near critical, like the /proc and /sys trees in modern Linux). Some reflects the more-complex world we live in (networking). But a lot of it seems, to my mind that felt really at home when it first settled into UNIX in 1981, just plain tasteless. There are certainly legitimate differences in aesthetic taste involved, though. I think taste becomes technically important when it can be mapped onto real differences in how easily a program can be understood, whether its innards or its external interface; how easily the program can adapt to different tasks or environments; and so on. Norman Wilson Toronto ON

10 years, 11 months

8
10
0 0

Re: [TUHS] terminal - just for fun

by Norman Wilson

Tim Newsham: I was referring to the bell labs guys who wrote linux and later plan9... ======= Which Bell Labs guys wrote Linux? I assume you're not referring to Andy Tanenbaum, erstwhile teacher of a certain famous Finn ... Norman Wilson Toronto ON PS: it's true that the Plan 9 folks at Bell Labs were early champions of both Unicode and the UTF-8 encoding. Source: personal memory.

10 years, 11 months

2
1
0 0

Re: [TUHS] terminal - just for fun

by Doug McIlroy

> Remember that writing programs on terminals was a relative latecomer -- > FORTRAN was designed for punched cards. Remember that FORTRAN also was a latecomer. It was a shock to convert from the full character set of the Flexowriters at Whirlwind to the rebarbative upper-case-only of the 704. In that vein, there was a period when the Chicago Manual Style disparaged uppercase text, with an exception being made for computer programs, which of course should be presented in upper case. Doug

10 years, 11 months

1
0
0 0

Subject: changes for modern -> v7 -> v6 -> v5

by Doug McIlroy

> no conditional compilation so no way to make a truly universal version > which works on everything. If cc -I is there, it should be able to do the tailoring. Also conditional compilation of non-declaration statements can be replaced by regular if statements that typically can be optimized away (though the old C compilers may not do so). Incidentally, I would say that the use of conditional compilation is evidence that the code is NOT truly universal, but has to be specially adapted to various environments. Doug

10 years, 11 months

2
1
0 0

Re: [TUHS] Unix style

by Doug McIlroy

> "Reining in", please (peeve, peeve) Ouch. Doubly so for the erstwhile curator of "spell". (COuld "reigning in" somehow have been implanted by this headline that I saw in The Economist a few days ago: "The reign in Maine is easy to explain"?) Doug

10 years, 11 months

6
6
0 0

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by jnc＠mercury.lcs.mit.edu

> From: "A. P. Garcia" <a.phillip.garcia(a)gmail.com> > the spirit of emacs without the bloat :-) Exactly. I've often wondered what the heck exactly it is that GNU Emacs, GCC, etc are all doing with those megabytes of code. (In part, probably all those options: "Options. We've got lots of them. So many in fact, that you need two strong people to carry the documentation around.", as that classic hack says. But there's no way the options alone can explain it all.) The thing is that it's not just aesthetics that makes large programs bad; there are very good practical reasons why they are bad, too. The 'takes more resources' isn't such a big deal today, because memory is massive, and there's a ton of computing power to be thrown at things. (Although I'm always amazed at how the active content in Web pages seems to run incredibly slowly on all but the very latest and greatest machines. WTF are they doing?) But more code = more material that someone new has to understand before they can make some change (and long-lived code is always being changed/upgraded by new people). And when people understand a system poorly, their changes tend to be 'a bag on the side', and that's the kind of 'code cancer' that tends to kill systems in the long run. More code also is also more places where there can be bugs (especially when it's changed by someone who understands it poorly, repeat previous comment). Etc, etc. And those will never go away - human brain power is finite, and unlike hardware, not expanding. There's just no reason to have N megabytes of code when .N will do. (I've often thought we ought to make new programmers serve an apprenticeship of a year of two on a PDP-11 - to teach them to 'think small', and to realize you _can_ do a lot in a small space.) Noel

10 years, 11 months

5
4
0 0

Unix taste (Re: terminal - just for fun)

by norman＠oclsc.org

Doug McIlroy: A symptom of why I have always detested emacs and vi. With ^D, ^C, and ^\, Unix has more than enough mystery chords to learn. ==== What is this ^C mystery chord? Or can it be that I am actually more wedded to the past than Doug, in that I still use DEL as my interrupt character? And, for that matter, @ for kill (though in the modern world one has to type @ often enough to require learning a different modern-world mystery chord, ^V). I break with the past for character-erase, though: backspace, not #. Norman Wilson Toronto ON

10 years, 11 months

4
3
0 0

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by jnc＠mercury.lcs.mit.edu

> From: John Cowan <cowan(a)mercury.ccil.org> > because of all the Elisp code it ships with So why is /usr/bin/emacs 4.5 megabytes? > That's basically just the kind of peeving that objects to the use of > computers as calculators and spelling checkers. I just gave several good reasons why large programs (well, technically, systems) are bad. Are you saying those reasons are fallacious? Noel

10 years, 11 months

2
1
0 0

Re: [TUHS] unirubik port to unix v5 is complete

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge <cubexyz(a)gmail.com> > I thought you folks might be interested in looking at the changes I had > to make. It was a bit harder than the port to v6 but porting to v6 > first did make things a bit easier. To save me from poring over 'diff' output :-), what (at a high level) were the changes you had to make to get it to run on v5? Noel

10 years, 11 months

1
0
0 0

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by jnc＠mercury.lcs.mit.edu

> From: "A. P. Garcia" <a.phillip.garcia(a)gmail.com> > Being so small, I expected the editor to lack a scripting language. Well, there is a companion 'compiler' which converts extension source into the intermediate form (byte-code) which is interpreted by the editor. But it's even smaller (67KB!) and as fast as the editor itself. > I was pleasantly surprised that it does have one, and that it's a c > derivative ... "Extensible and modifiable" doesn't always mean the same > thing to everyone, and well, you're a kernel hacker. Take a quick look at a source file, e.g. one of mine: http://ana-3.lcs.mit.edu/~jnc/tech/cmd.e and you'll see i) what it's like (except for a few new editing-specific keywords, such as 'on <key>' in function definitions, it's pretty much C), and ii) it will give you a sense of the kind of things one writes in it, and how easy it is to do so. The underlying run-time basically just provides buffer, display, etc primitives, and pretty much all the actual editor commands are written in the 'extension' languge, even simple things like 'forward character' (^F), etc. The complete manual is available online, the run-time system is described here: http://www.lugaru.com/man/Primitives.and.EEL.Subroutines.html Epsilon comes (as of a few versions back, I haven't bothered to upgrade) with about 22K lines of source, which is the bulk of the actual editor; that turns into about 190KB of intermediate code. Noel

10 years, 11 months

3
2
0 0

unirubik port to unix v5 is complete

by Mark Longridge

Hi folks, I finally managed to get unirubik working on unix v5. I thought you folks might be interested in looking at the changes I had to make. It was a bit harder than the port to v6 but porting to v6 first did make things a bit easier. I've included links to all three versions. unirubik.c.v5 needs gets.c http://www.maxhost.org/other/unirubik.c.v7 http://www.maxhost.org/other/unirubik.c.v6 http://www.maxhost.org/other/unirubik.c.v5 http://www.maxhost.org/other/gets.c The unirubik for v5 was considerably smaller than the other versions, a mere 5492 bytes. Mark

10 years, 11 months

1
0
0 0

Re: [TUHS] terminal - just for fun

by Dave Horsfall

On Sat, 2 Aug 2014, John Cowan wrote: > > Hadn't really noticed; I went straight from CP/M to Unix, giving > > MS-DOS a miss. > > I was actually thinking about OS/8 and RT-11. Ahh... RT-11 and TECO... Who here hasn't typed their name into it to see what it did? I was thinking of home systems. -- Dave

10 years, 11 months

5
4
0 0

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by jnc＠mercury.lcs.mit.edu

> From: Benjamin Huntsman <BHuntsman(a)mail2.cu-portland.edu> > I thought it stood for Escape-Meta-Alt-Control-Shift :) > From: Dave Horsfall <dave(a)horsfall.org> > EMACS - Editor too large Those are both pretty funny! BTW, Epsilon (that 250KB Emacs that I was raving about) not only runs under Windows, it also runs under Linux, Mac OS, FreeBSD, etc. Here: http://lugaru.com/ I can't say enough good things about it (hence my 30-year addiction to it). If you want an Emacs clone that is very small; very fast; and wildly extensible and modifiable (it comes with almost all the source), in C (effectively); this is the one. Noel

10 years, 11 months

2
1
0 0

Unix taste (Re: terminal - just for fun)

by Doug McIlroy

> To each their own. Indeed. > As a Vi user, nothing beats having Esc on the home row. A symptom of why I have always detested emacs and vi. With ^D, ^C, and ^\, Unix has more than enough mystery chords to learn. Emacs and vi raised that number to a high power--an interface at least as arcane and disorganized as the DD card in OS 360--baroque efflorescences totally out of harmony with the spirit of Unix. (Perhaps one could liken learning vi to learning how to finger the flute, but the flute pays off with beautiful music. To put the worst face on vi, it "pays off" only by promoting frantic tinkering.) A modern-day analog of the undisciplined exuberance of emacs and vi: for a good time on linux try less --help | wc Does comment on taste belong in a discussion of history? I think so. Unix was born of a taste for achieving big power by small means rather than by unbounded accumulation of facilities. But evolution, including the evolution of Unix, does not work that way. An interesting question is how the corrective of taste manages ever to recenter the exuberance of evolution. The birth of Unix shows it can happen. When will it happen again? Can one cite small-scale examples that gained traction within the larger evolution of Unix? Doug

10 years, 11 months

7
8
0 0

Re: [TUHS] Unix taste (Re: terminal - just for fun)

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy <doug(a)cs.dartmouth.edu> > A symptom of why I have always detested emacs and vi. With ^D, ^C, and > ^\, Unix has more than enough mystery chords to learn. Emacs and vi > raised that number to a high power--an interface at least as arcane and > disorganized as the DD card in OS 360--baroque efflorescences totally > out of harmony with the spirit of Unix. I will agree that the Emacs user interface is not simple - although there are levels, and one can start out e.g. without knowing the commands to move by word, and get by with the commands to move by character - and of course nowadays, the arrows, etc, keys on keyboards are bound to the appropriate commands, for novices. But it's a subtle debate; yes, it's not for everyone, but i) as an application, not everyone has to use it (unlike a kernel), and ii) as the editor is the principal tool which most programmers spend hours a day using, it is not insensible to have a more complex but powerful tool which takes a while to fully master. (Like playing a violin...) Back on V6, we started using one written by someone at BBN (memory fails me as to exactly who), and it improved my productivity immensely (with 'WYSIWG' editing - i.e. you always see the current contents of the buffer, multiple buffers, multiple windows, etc). I had been using 'ed' (although I had access to Emacs on the ITS machines), and although I was (and remain) fairly skilled at 'ed', the factors I just listed are immense, IMO. Being able to see the code as I work on it really, really helps (for me, at least). But a lot of that is orthogonal to Emacs command interface; you can have 'WYSIWYG', multiple buffers, etc with a wholly different command interface, and get much the same benefit. (E.g. uSoft Word has most of those; real WYSIWG [i.e. with multiple fonts], multiple files open at once, etc, etc.) Does something like Word produce the same reaction for you? I don't use it much, but my wife does (she's an engineer, and uses it to write papers), and its complexity drives her crazy sometimes. As for the size of Emacs, everyone needs to distinguish between GNU Emacs, and Emacs-like editors. Just as GCC is a beast, but other C compilers are and were much smaller, there are small Emacses out there. Back on V6 (on a PDP-11, of course), it had to fit into 64KB; the one we used didn't have the kind of extensibility common in them now, but it was still a much better tool for me than 'ed'. As I recall the performance was pretty good (albeit it chewed CPU time, since it woke up on every character - Multics had an Emacs which tried to avoid that, and only woke up on non-printing characters, and used system echoing for the others). I don't know for sure (I don't have the source to hand at the moment - that's one of the things I hope to recover if/when I can read those backup tapes), but I suspect that it 'windowed' files (i.e. didn't read the whole thing in); with the 65KB address space of the 11, that would be almost inevitable. I have been using another Emacs, Epsilon, for almost 30 years now; it started as basically Emacs for MS-DOS, and later became Emacs for Windows, and it is small and very fast. The Windows executable is about 250KB, and it loads a 'state file' (mostly interpreted 'compiled' intermediate code, written in something that's 99.2% 'C', in which a lot of the editor is actually written) of about 200K (for mine, which has a lot of extensions I wrote). It starts fast, and runs blindingly fast. It also uses the file 'windowing' techniques, and can handle much larger files than its address space (this dates back to its MS-DOS days). So Emacs != big (at least, not necessarily). > A modern-day analog of the undisciplined exuberance of emacs and vi: > for a good time on linux try I basically agree with you on this; I want to go away and collect my thoughts before responding, though. Noel

10 years, 11 months

2
1
0 0

Re: [TUHS] Unix taste

by Ed

Arrow keys? Vi does arrow keys? But then I'd have to move my hand from home. That's not vi. -- Ed Skinner, ed(a)flat5.net, http://www.flat5.net/ -------- Original message -------- From: Doug McIlroy <doug(a)cs.dartmouth.edu> Date: 08/02/2014 8:38 AM (GMT-07:00) To: tuhs@minnie.tuhs.org,lm@mcvoy.com Subject: Re: [TUHS] Unix taste > So Doug, ed? Or what? Yes, ed for small things. It loads instantly and works in the current window without disturbing it. And it has been ingrained in my fingers since Multics days. But for heavy duty work, I use sam, in Windows as well as Linux. Sam marries ed to screen editing much more cleanly than vi. It has recursive global commands and infinite undo. Like qed (whence came ed's syntax) and Larry's xvi it can work on several files (or even several areas in one file) at once. I would guess that a vi adept would miss having arrow keys as well as the mouse, but probably not much else. Sam offers one answer for my question about examples of taste reigning in featurism during the course of Unix evolution. Doug _______________________________________________ TUHS mailing list TUHS(a)minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/tuhs

10 years, 11 months

1
0
0 0

Re: [TUHS] Unix taste

by Doug McIlroy

> So Doug, ed? Or what? Yes, ed for small things. It loads instantly and works in the current window without disturbing it. And it has been ingrained in my fingers since Multics days. But for heavy duty work, I use sam, in Windows as well as Linux. Sam marries ed to screen editing much more cleanly than vi. It has recursive global commands and infinite undo. Like qed (whence came ed's syntax) and Larry's xvi it can work on several files (or even several areas in one file) at once. I would guess that a vi adept would miss having arrow keys as well as the mouse, but probably not much else. Sam offers one answer for my question about examples of taste reigning in featurism during the course of Unix evolution. Doug

10 years, 11 months

2
1
0 0

Re: [TUHS] First Unix that could run on a PDP-11 with QBUS

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > I recall that there were other differences as well, but only minor. In > my paper in AUUGN titled "Unix on the LSI-11/23" it will reveal all > about porting V6 to the thing. I did a google for that, but couldn't find it. Is it available anywhere online? (I'd love to read it.) I seem to recall vaguely that AUUGN stuff were online, but if so, I'm not sure why the search didn't turn it up. > I vaguely remember that the LTC had to be disabled during the boot > process, for example, with an external switch. I think you might be right, which means the simulated 11/23 I tested on wasn't quite right - but keep reading! I remember being worried about this when I started doing the V6 11/23 version a couple of months back, because I remembered the 11/03's didn't have a programmable clock, just a switch. So I was reading through the 11/23 documentation (I had used 11/23s, but on this point my memory had faded), trying to see if they too did not have a programmable clock. As best I can currently make out, the answer is 'yes/no, depending on the exact model'! E.g. the 11/23-PLUS _does_ seem to have a programmable clock (see pg. 610 of the 1982 edition of "microcomputers and memories"), but the base 11/23 _apparently_ does not. Anyway, the simulated 11/23 (on Ersatz11) does have the LTC (I just checked, and 'lks' contains '0177546', so it thinks it has one :-). But this will be easy to code around; if no link clock is found (in main.c), I'd probably set 'lks' to point somewhere harmless (054, say - I'm using 050/052 to hold the pointer to the CSW, and the software CSW if there isn't a hardware one). That way I can limit the changes to be in main.c, I won't have to futz with clock.c too. Noel PS: On at least the 11/40 (and maybe the /45 too), the line clock was an option! It was a single-height card, IIRC.

10 years, 11 months

5
5
0 0

Re: [TUHS] First Unix that could run on a PDP-11 with QBUS

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge <cubexyz(a)gmail.com> > I was digging around trying to figure out which Unixes would run on a > PDP-11 with QBUS. It seems that the very early stuff like v5 was > strictly UNIBUS and that the first version of Unix that supported QBUS > was v7m (please correct me if this is wrong). That may or may not be true; let me explain. The 11/23 is almost indistinguishable, in programming terms, from an 11/40. There is only one very minor difference (which UNIX would care about) that I know of - the 11/23 does not have a hardware switch register. Yes, UNIBUS devices can't be plugged into a QBUS, and vice versa, _but_ i) there a programming-compatible QBUS versions of many UNIBUS devices, and ii) there were UNIBUS-QBUS converters which actually allowed a QBUS processor to have UNIBUS peripherals. So I don't know which version of Unix was the first run on an 11/23 - but it could have been almost any. It is quite possible to run V6 on an 11/23, provided you make a very small number of very minor changes, to avoid use of the CSWR. I have done this, and run V6 on a simulated 11/23 (I have a short note explaining what one needs to do, if anyone is interested.) Admittedly, this is not the same as running it on a real 11/23, but I see no resons the latter would not be doable. I had started in on the work needed to get V6 running on a real 11/23, which was the (likely) need to load Unix into the machine over a serial line. WKT has done this for V7: http://www.tuhs.org/Archive/PDP-11/Tools/Tapes/Vtserver/ but it needs a little tweaking for V6; I was about to start in on that. > I have hopes to eventually run a Unix on real hardware As do a lot of us... :-) > It seems like DEC just didn't make a desktop that could run Bell Labs > Unix, e.g. we can't just grab a DEC Pro-350 and stick Unix v7 on it. I'm not sure about that; I'd have to check into the Pro-350. If it has memory mapping, it should not be hard. Also, even if it doesn't have memory mapping, there was a Mini-Unix done for PDP-11's without memory mapping; I can dig up some URLs if you're interested. The feeling is, I gather, very similar. > it would be nice to eventually run a Unix with all the source code at > hand on a real machine. Having done that 'back in the day', I can assure you that it doesn't feel that different from the simulated experience (except that the latter are noticeably faster :-). In fact, even if/when I do have a real 11, I'll probably still mostly use the simulator, for a variety of reasons; e.g. the ability to edit source with a nice modern editor, etc, etc is just too nice to pass up! :-) Noel

10 years, 11 months

6
5
0 0

First Unix that could run on a PDP-11 with QBUS

by Mark Longridge

Hi folks, I was digging around trying to figure out which Unixes would run on a PDP-11 with QBUS. It seems that the very early stuff like v5 was strictly UNIBUS and that the first version of Unix that supported QBUS was v7m (please correct me if this is wrong). I was thinking that the MicroPDP-11's were all QBUS and that it would be easier to run a Unix on a MicroPDP because they are the most compact. So I figured I would try to obtain a Unix v7m distribution tape image. I see the Jean Huens files on tuhs but I'm not sure what to do with them. I have hopes to eventually run a Unix on real hardware but for now I'm going to stick with simh. It seems like DEC just didn't make a desktop that could run Bell Labs Unix, e.g. we can't just grab a DEC Pro-350 and stick Unix v7 on it. Naturally I'll still have fun checking out Unix v5 on the emulator but it would be nice to eventually run a Unix with all the source code at hand on a real machine. Mark

10 years, 11 months

2
1
0 0

Re: [TUHS] First Unix that could run on a PDP-11 with QBUS

by norman＠oclsc.org

Many Q-bus devices were indeed programmed exactly as if on a UNIBUS. This isn't surprising: Digital wanted their own operating systems to port easily as well. That won't help make UNIX run on a Pro-350 or Pro-380, though. Those systems had standard single-chip PDP-11 CPUs (F11, like that in the 11/23, for the 350; J11, like that in the 11/73, for the 380), but they didn't have a Q-bus; they used the CTI (`computing terminal interconnect'), a bus used only for the Pro-series systems. DEC's operating systems wouldn't run on the Pro either without special hacks. I think the P/OS, the standard OS shipped with those systems, was a hacked-up RSX-11M. I don't know whether there was ever an RT-11 for the Pro. There were UNIX ports but they weren't just copies of stock V7. I vaguely remember, from my days at Caltech > 30 years ago, helping someone get a locally-hacked-up V7 running on an 11/24, the same as an 11/23 except is has a UNIBUS instead of a Q-bus. I don't think they chose the 11/24 over the 11/23 to make it easier to get UNIX running; probably it had something to do with specific peripherals they wanted to use. It was a long time ago and I didn't keep notebooks back then, so the details may be unrecoverable. Norman Wilson Toronto ON

10 years, 11 months

4
3
0 0

Re: [TUHS] Excise process from a pipe

by jnc＠mercury.lcs.mit.edu

>> the downstream process is in the middle of a read call (waiting for >> more data to be put in the pipe), and it has already computed a pointer >> to the pipe's inode, and it's looping waiting for that inode to have >> data. > I think it would be necessary to make non-trivial adjustments to the > pipe and file reading/writing code to make this work; either i) some > sort of flag bit to say 'you've been spliced, take appropriate action' > which the pipe code would have to check on being woken up, and then > back out to let the main file reading/writing code take another crack > at it > ... > I'm not sure I want to do the work to make this actually work - it's > not clear if anyone is really that interested? And it's not something > that I'm interested in having for my own use. So I decided that it was silly to put all that work into this, and not get it to work. I did 'cut a corner', by not handling the case where it's the first or last process which is bailing (which requires a file-pipe splice, not a pipe-pipe; the former is more complex); i.e. I was just doing a 'working proof of concept', not a full implementation. I used the 'flag bit on the inode' approach; the pipe-pipe case could be dealt with entirely inside pipe.c/readp(). Here's the added code in readp() (at the loop start): if ((ip->i_flag & ISPLICE) != 0) { closei(ip, 0); ip = rp->f_inode; } It worked first time! In more detail, I had written a 'splicetest' program that simply passed input to its output, looking for a line with a single keyword ("stop"); at that point, it did a splice() call and exited. When I did "cat input | splicetest | cat > output", with appropriate test data in "input", all of the test data (less the "stop" line) appeared in the output file! For the first time (AFAIK) a process succesfully departed a pipeline, which continued to operate! So it is do-able. (If anyone has any interest in the code, let me know.) Noel

10 years, 11 months

1
0
0 0

Hazards of open source.

by Doug McIlroy

10 years, 11 months

1
0
0 0

shutdown for pre-v7 unix

by Mark Longridge

Hi folks, I've been typing sync;sync at the shell prompt then hitting ctrl-e to get out of simh to shutdown v5 and v6 unix. So far this has worked fairly well but I was wondering if there might be a better way to do a shutdown on early unix. There's a piece of code for Unix v7 that I came across for doing a shutdown: http://www.maxhost.org/other/shutdown.c I doesn't work on pre-v7 unix, but maybe it could be modified to work? Mark

10 years, 11 months

10
13
0 0

Re: [TUHS] Excise process from a pipe

by jnc＠mercury.lcs.mit.edu

> the downstream process is in the middle of a read call (waiting for > more data to be put in the pipe), and it has already computed a pointer > to the pipe's inode, and it's looping waiting for that inode to have > data. > So now I have to regroup and figure out how to deal with that. My most > likely approach is to copy the inode data across So I've had a good look at the pipe code, and it turns out that the simple hack won't work, for two reasons. First, the pipe on the _other_ side of the middle process is _also_ probably in the middle of a write call, and so you can't snarf its inode out from underneath it. (This whole problem reminds me of 'musical chairs' - I just want the music to stop so everything will go quiet so I can move things around! :-) Second, if the process that wants to close down and do a splice is either the start or end process, its neighbour is going to go from having a pipe to having a plain file - and the pipe code knows the inode for a pipe has two users, etc. So I think it would be necessary to make non-trivial adjustments to the pipe and file reading/writing code to make this work; either i) some sort of flag bit to say 'you've been spliced, take appropriate action' which the pipe code would have to check on being woken up, and then back out to let the main file reading/writing code take another crack at it, or ii) perhaps some sort of non-local goto to forcefully back out the call to readp()/writep(), back to the start of the read/write sequence. (Simply terminating the read/write call will not work, I think, because that will often, AFAICT, return with 0 bytes transferred, which will look like an EOF, etc; so the I/O will have to be restarted.) I'm not sure I want to do the work to make this actually work - it's not clear if anyone is really that interested? And it's not something that I'm interested in having for my own use. Anyway, none of this is in any way a problem with the fundamental service model - it's purely kernel implementation issues. Noel

10 years, 11 months

1
0
0 0

Program compiled on unix v6 works on unix v5

by Mark Longridge

Ok, this is cheating a bit but I was wondering if I could possibly compile my unix v6 version of unirubik which has working file IO and run it under unix v5. At first I couldn't figure out how to send a binary from unix v6 to unix v5 but I did some experimenting and found: tp m1r unirubik which would output unirubik to mag tape #1 and tp m1x unirubik which would input unirubik from mag tape #1. I don't know what cc does exactly but I thought "well if it compiles to PDP-11 machine code and it's statically linked it could work". And it actually does work! I still want to try to get unirubik to compile under Unix v5 cc but it's interesting that a program that uses iolib functions can work under unix v5. Mark

10 years, 11 months

1
0
0 0

Re: [TUHS] shutdown for pre-v7 unix

by jnc＠mercury.lcs.mit.edu

> From: Norman Wilson <norman(a)oclsc.org> > I believe that when sync(2) returned, all unflushed I/O had been queued > to the device driver, but not necessarily finished Yes. I have just looked at update() (the internal version of 'sync') again, and it does three things: writes out super-blocks, any modified inodes, and (finally) any cached disk blocks (in that order). In all three cases, the code calls (either directly or indirectly) bwrite(), the exact operation of which (wait for completion, or merely schedule the operation) on any given buffer depends on the flag bits on that buffer. At least one of the cases (the third), it sets the 'ASYNC' bit on the buffer, i.e. it doesn't wait for the I/O to complete, merely schedules it. For the first two, though, it looks like it probably waits. > so the second sync was just a time-filling no-op. If all the disks were > in view, it probably sufficed just to watch them until all the lights > ... had stopped blinking. Yes. If the system is single-user, and you say 'sync', if you wait a bit for the I/O to complete, any later syncs won't actually do anything. I don't know of any programmatic way to make sure that all the disk I/O has completed (although obviously one could be written); even the 'unmount' call doesn't check to make sure all the I/O is completed (it just calls update()). Watching the lights was as good as anything. > I usually typed sync three or four times myself. I usually just type it once, wait a moment, and then halt the machine. I've never experienced disk corruption from so doing. With modern ginormous disk caches, you might have to wait more than a moment, but we're talking older machines here... Noel

10 years, 11 months

1
0
0 0

Re: [TUHS] shutdown for pre-v7 unix

by Norman Wilson

After a day and an evening of fighting with modern hardware, the modern tangle that passes for UNIX nowadays, and modern e-merchandising, I am too lazy to go look up the details. But as I remember it, two syncs was indeed probably enough. I believe that when sync(2) returned, all unflushed I/O had been queued to the device driver, but not necessarily finished, so the second sync was just a time-filling no-op. If all the disks were in view, it probably sufficed just to watch them until all the lights (little incandescent bulbs in those days, not LEDs) had stopped blinking. I usually typed sync three or four times myself. It gave me a comfortable feeling (the opposite of a syncing feeling, I suppose). I still occasionally type `sync' to the shell as a sort of comfort word while thinking about what I'm going to do next. Old habits die hard. (sync; sync; sync) Norman Wilson Toronto ON

10 years, 11 months

1
0
0 0

Re: [TUHS] the sin of buffering [offshoot of excise process from a pipeline]

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy <doug(a)cs.dartmouth.edu> > Process A spawns process B, which reads stdin with buffering. B gets > all it deserves from stdin and exits. What's left in the buffer, > intehded for A, is lost. Ah. Got it. The problem is not with buffering as a generic approach, the problem is that you're trying to use a buffering package intended for simple, straight-forward situations in one which doesn't fall into that category! :-) Clearly, either B has to i) be able to put back data which was not for it ('ungets' as a system call), or ii) not read the data that's not for it - but that may be incompatible with the concept of buffering the input (depending on the syntax, and thus the ability to predict the approaching of the data B wants, the only way to avoid the need for ungetc() might be to read a byte at a time). If B and its upstream (U) are written together, that could be another way to deal with it: if U knows where B's syntatical boundaries are, it can give it advance warning, and B could then use a non-trivial buffering package to do the right thing. E.g. if U emits 'records' with a header giving the record length X, B could tell its buffering package 'don't read ahead more than X bytes until I tell you to go ahead with the next record'. Of course, that's not a general solution; it only works with prepared U's. Really, the only general, efficient way to deal with that situation that I can see is to add 'ungets' to the operating system... Noel

10 years, 11 months

1
0
0 0

Re: [TUHS] Excise process from a pipe

by jnc＠mercury.lcs.mit.edu

>> From: Doug McIlroy <doug(a)cs.dartmouth.edu> >> The spec below isn't hard: just hook two buffer chains together and >> twiddle a couple of file desciptors. > In thinking about how to implement it, I was thinking that if there was > any buffered data in an output pipe, that the process doing the > splice() would wait (inside the splice() system call) on all the > buffered data being read by the down-stream process. > ... > As a side-benefit, if one adopted that line, one wouldn't have to deal > with the case (in the middle of the chain) of a pipe-pipe splice with u > buffered data in both pipes (where one would have to copy the data > across); instead one could just use the exact same code for both cases So a couple of days ago I suffered a Big Hack Attack and actually wrote the code for splice() (for V6, of course :-). It took me a day or so to get 'mostly' running. (I got tripped up by pointer arithmetic issues in a number of places, because V6 declares just about _everything_ to be "int *", so e.g. "ip + 1" doesn't produce the right value for sleep() if ip is declared to be "struct inode *", which is what I did automatically.) My code only had one real bug so far (I forgot to mark the user's channels as closed, which resulted in their file entries getting sub-zero usage counts when the middle (departing) process exited). However, now I have run across a real problem: I was just copying the system file table entry for the middle process' input channel over to the entry for the downstream's input (so further reads on its part would read the channel the middle process used to be reading). Copying the data from one entry to another meant I didn't have to go chase down file table pointers in the other process' U structure, etc. Alas, this simple approach doesn't work. Using the approach I outlined (where the middle channel waits for the downstream pipe to be empty, so it can discard it and do the splice by copying the file table entries) doesn't work, because the downstream process is in the middle of a read call (waiting for more data to be put in the pipe), and it has already computed a pointer to the pipe's inode, and it's looping waiting for that inode to have data. So now I have to regroup and figure out how to deal with that. My most likely approach is to copy the inode data across (so I don't have to go mess with the downstream process to get it to go look at another inode), but i) I want to think about it a bit first, and ii) I have to check that it won't screw anything else up if I move the inode data to another slot. Noel

10 years, 11 months

1
0
0 0

Re: [TUHS] shutdown for pre-v7 unix

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge <cubexyz(a)gmail.com> > I was wondering if there might be a better way to do a shutdown on > early unix. Not really; I don't seem to recall our having one on the MIT V6 machine. (We did add a 'reboot' system call so we could reboot the machine without having to take the elevator up to the machine room [the console was on our floor, and the reboot() call just jumped into the hardware bootstrap], but in the source it doesn't even bother to do an update(). Well, I should't say that: I only have the source for the kernel, which doesn't; I don't at the moment have access to the source for the rest of the system - although I do have some full dump tapes, once I can work out how to read them. Anyway, so maybe the user command for rebooting the system did a sync() first.) I suppose you could set the switch register to 173030 and send a 'kill -1 1', which IIRC kills of all shells except the one on the console, but somehow I doubt you're running multi-user anyway... :-) Noel

10 years, 11 months

1
0
0 0

Unix v1/v2 cp command

by Mark Longridge

>> the cp command seems different from all other versions, I'm not sure I >> understand it so I used the mv command instead which worked as expected. > > I'm intrigued; in what way is it different? It seems that one must first cp a file to another file then do a mv to actually put it into a different directory: e.g. while in /usr/src as ctr0.s cp a.out ctr0.o mv ctr0.o /usr/lib ...rather than trying to just "cp a.out /usr/lib/ctr0.o" Mark

10 years, 11 months

2
2
0 0

Re: [TUHS] the sin of buffering [offshoot of excise process from a pipeline]

by Doug McIlroy

Yes, an evil necessary to get things going. The very definition of original sin. Doug Larry McVoy wrote: >>>> For stdio, of course, one would need fsplice(3), which must flush the >>>> in-process buffers--penance for stdio's original sin of said buffering. >>> Err, why is buffering data in the process a sin? (Or was this just a >>> humourous aside?) >> Process A spawns process B, which reads stdin with buffering. B gets >> all it deserves from stdin and exits. What's left in the buffer, >> intehded for A, is lost. Sinful. > It really depends on what you want. That buffering is a big win for > some use cases. Even on today's processors reading a byte at a time via > read(2) is costly. Like 5000x more costly on the laptop I'm typing on:

10 years, 11 months

4
7
0 0

the sin of buffering [offshoot of excise process from a pipeline]

by Doug McIlroy

> Err, why is buffering data in the process a sin? (Or was this just a humourous aside?) Process A spawns process B, which reads stdin with buffering. B gets all it deserves from stdin and exits. What's left in the buffer, intehded for A, is lost. Sinful.

10 years, 11 months

3
2
0 0

Re: [TUHS] Excise process from a pipe

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy <doug(a)cs.dartmouth.edu> > The spec below isn't hard: just hook two buffer chains together and > twiddle a couple of file desciptors. How amusing! I was about to send a message with almost the exact same description - it even had the exact same syntax for the splice() call! A couple of points from my thoughts which were not covered in your message: In thinking about how to implement it, I was thinking that if there was any buffered data in an output pipe, that the process doing the splice() would wait (inside the splice() system call) on all the buffered data being read by the down-stream process. The main point of this is for the case where the up-stream is the head of the chain (i.e. it's reading from a file), where one more or less has to wait, because one will want to set the down-streams' file descriptor to point to the file - but one can't really do that until all the buffered data was consumed (else it will be lost - one can't exactly put it into the file :-). As a side-benefit, if one adopted that line, one wouldn't have to deal with the case (in the middle of the chain) of a pipe-pipe splice with buffered data in both pipes (where one would have to copy the data across); instead one could just use the exact same code for both cases, and in that case the wait would be until the down-stream pipe can simply be discarded. One thing I couldn't decide is what to do if the upstream is a pipe with buffered data, and the downstream is a file - does one discard the buffered data, write it to the file, abort the system call so the calling process can deal with the buffered data, or what? Perhaps there could be a flag argument to control the behaviour in such cases. Speaking of which, I'm not sure I quite grokked this: > If file descriptor fd0 is associated with a pipe and fd1 is not, then > fd1 is updated to reflect the effect of buffered data for fd0, and the > pipe's other descriptor is replaced with a duplicate of fd1. But what happens to the data? Is it written to the file? (That's the implication, but it's not stated directly.) > The same statement holds when "fd0" is exchanged with "fd1" and "write" > is exchanged with "read". Ditto - what happens to the data? One can't simply stuff it into the input file? I think the 'wait in the system call until it drains' approach is better. Also, it seemed to me that the right thing to do was to bash the entry in the system-wide file table (i.e. not the specific pointers in the u area). That would automatically pick up any children. Finally, there are 'potential' security issues (I say 'potential' because I'm not sure they're really problems). For instance, suppose that an end process (i.e. reading/writing a file) has access to that file (e.g. because it executed a SUID program), but its neighbour process does not. If the end process wants to go away, should the neighbour process be allowed access to the file? A 'simple' implementation would do so (since IIRC file permissions are only checked at open time, not read/write time). I don't pretend that this is a complete list of issues - just what I managed to think up while considering the new call. > For stdio, of course, one would need fsplice(3), which must flush the > in-process buffers--penance for stdio's original sin of said buffering. Err, why is buffering data in the process a sin? (Or was this just a humourous aside?) Noel

10 years, 12 months

1
0
0 0

Re: [TUHS] Excise process from a pipe

by Doug McIlroy

Larry wrote in separate emails > If you really think that this could be done I'd suggest trying to > write the man page for the call. > I already claimed splice(2) back in 1998; the Linux guys did > implement part of it ... I began to write the following spec without knowing that Linux had appropriated the name "splice" for a capability that was in DTSS over 40 years ago under a more accurate name, "copy". The spec below isn't hard: just hook two buffer chains together and twiddle a couple of file desciptors. For stdio, of course, one would need fsplice(3), which must flush the in-process buffers--penance for stdio's original sin of said buffering. Incidentally, the question is not abstract. I have code that takes quadratic time because it grows a pipeline of length proportional to the input, though only a bounded number of the processes are usefully active at any one time; the rest are cats. Splicing out the cats would make it linear. Linear approaches that don't need splice are not nearly as clean. Doug SPLICE(2) SYNOPSIS int splice(int fd0, int fd1); DESCRIPTION Splice connects the source for a reading file descriptor fd0 directly to the destination for a writing file descriptor fd1 and closes both fd0 and fd1. Either the source or the destination must be another process (via a pipe). Data buffered for fd0 at the time of splicing follows such data for fd1. If both source and destination are processes, they become connected by a pipe. If the source (destination) is a process, the file descriptor in that process becomes write-only (read-only). If file descriptor fd0 is associated with a pipe and fd1 is not, then fd1 is updated to reflect the effect of buffered data for fd0, and the pipe's other descriptor is replaced with a duplicate of fd1. The same statement holds when "fd0" is exchanged with "fd1" and "write" is exchanged with "read". Splice's effect on any file descriptor propagates to shared file descriptors in all processes. NOTES One file must be a pipe lest the spliced data stream have no controlling process. It might seem that a socket would suffice, ceding control to a remote system; but that would allow the uncontrolled connection file-socket-socket-file. The provision about a file descriptor becoming either write-only or read-only sidesteps complications due to read-write file descriptors.

10 years, 12 months

1
0
0 0

Re: [TUHS] Hello World compiled in v1/v2

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > crt0.s -> C Run Time (support). It jiggers the stack pointer in some > obscure manner It's the initial startup; it sets up the arguments into the canonical C form, and then calls main(). (It does not do the initial stack frame, a canonical call to CSV from inside main() will do that.) Here are the exact details: On an exec(), once the exec() returns, the arguments are available at the very top of memory: the arguments themselves are at the top, as a sequence of zero-terminated byte strings. Below them is an array of word pointers to the arguments, with a -1 in the last entry. (I.e. if there are N arguments, the array of pointers has N+1 entries, with the last being -1.) Below that is a word containing the size of that array (i.e. N+1). The Stack Pointer register points to that count word; all other registers (including the PC) are cleared. All CRT0.s does is move that argument count word down one location on the stack, adjust the SP to point to it, and put a pointer to the argument pointer table in the now-free word (between the argument count, and the first element of the argument pointer table). Hence the canonical C main() argument list of: int argc; int **argv; If/when main() returns, it takes the return value (passed in r0) and calls exit() with it. (If using the stdio library, that exit() flushes the buffers and closes all open files.) Should _that_ return, it does a 'sys exit'. There are two variant forms: fcrt0.s arranges for the floating point emulation to be loaded, and hooked up; mcrt0.s (much more complicated) arranges for process monitoring to be done. Noel

10 years, 12 months

1
0
0 0

Hello World compiled in v1/v2

by Mark Longridge

Hi folks, Yes I have managed to compile Hello World on v1/v2. the cp command seems different from all other versions, I'm not sure I understand it so I used the mv command instead which worked as expected. I had to "as crt0.s" and put crt0.o in /usr/lib and then it compiled without issue. Is the kernel in /etc? I saw a core file in /etc that looked like it would be about the right size. No unix file in the root directory which surprised me. At least I know what crt0.s does now. I guess a port of unirubik to v1/v2 is in the cards (maybe). Mark

10 years, 12 months

2
1
0 0

Unix v5 and beyond

by Mark Longridge

Hi folks, I'm interested in comparing notes with C programmers who have written programs for Unix v5, v6 and v7. Also I'm interested to know if there's anything similar to the scanf function for unix v5. Stdio and iolib I know well enough to do file IO but v5 predates iolib. Back in 1988 I tried to write a universal rubik's cube program which I called unirubik and after discovering TUHS I tried to backport it to v7 (which was easy) and v6 (which was a bit harder) and now I'm trying to backport it to v5. The v5 version currently doesn't have the any file IO capability as yet. Here are a few links to the various versions: http://www.maxhost.org/other/unirubik.c.v7 http://www.maxhost.org/other/unirubik.c.v6 http://www.maxhost.org/other/unirubik.c.v5 Also I've compiled the file utility from v6 in v5 and it seemed to work fine. Once I got /dev/mt0 working for unix v5 (thanks to Warren's help) I transferred the binary for the paging utility pg into it. This version of pg I believe was from 1BSD. I did some experimenting with math functions which can be seen here: http://www.maxhost.org/other/math1.c This will compile on unix v5. My initial impression of Unix v5 was that it was a primitive and almost unusable version of Unix but now that I understand it a bit better it seems a fairly complete system. I'm a bit foggy on what the memory limits are with v5 and v6. Unix v7 seems to run under simh emulating a PDP-11/70 with 2 megabytes of ram (any more than that and the kernel panics). Also I'd be interested in seeing the source code for Ken Thompson's APL interpreter for Unix v5. I know it does exist as it is referenced in the Unix v5 manual. The earliest version I could find was dated Oct 1976 and I've written some notes on it here: http://apl.maxhost.org/getting-apl-11-1976-to-work.txt Ok, that's about it for now. Is there any chance of going further back to v4, v3, v2 etc? Mark

10 years, 12 months

3
3
0 0

Re: [TUHS] Compiling the unix v5 kernel

by Warren Toomey

here's the e-mail that I sent on to Mark in the hope that it would give him enough information to get his 5th Edition kernel working with a tape device. He has also now joined the list. Welcome aboard, Mark. Warren ----- Forwarded message from Warren Toomey <wkt(a)tuhs.org> ----- On Thu, Jul 10, 2014 at 05:56:04PM -0400, Mark Longridge wrote: > There was no m40.s in v5 so I substituted mch.s for m40.s and that > seemed to create a kernel and it booted but I can't access /dev/mt0. Mark, glad to hear you were able to rebuild the kernel. I've never tried on 5th Edition. Just reading through the 6th Edition docs, it says this: ----- Next you must put in all of the special files in the directory /dev using mknod‐VIII. Print the configuration file c.c created above. This is the major device switch of each device class (block and character). There is one line for each device configured in your system and a null line for place holding for those devices not configured. The block special devices are put in first by executing the fol‐ lowing generic command for each disk or tape drive. (Note that some of these files already exist in the directory /dev. Examine each file with ls‐I with −l flag to see if the file should be removed.) /etc/mknod /dev/NAME b MAJOR MINOR The NAME is selected from the following list: c.c NAME device rf rf0 RS fixed head disk tc tap0 TU56 DECtape rk rk0 RK03 RK05 moving head disk tm mt0 TU10 TU16 magtape rp rp0 RP moving head disk hs hs0 RS03 RS04 fixed head disk hp hp0 RP04 moving head disk The major device number is selected by counting the line number (from zero) of the device’s entry in the block con‐ figuration table. Thus the first entry in the table bdevsw would be major device zero. The minor device is the drive number, unit number or partition as described under each device in section IV. The last digit of the name (all given as 0 in the table above) should reflect the minor device number. For tapes where the unit is dial selectable, a special file may be made for each possible selection. The same goes for the character devices. Here the names are arbitrary except that devices meant to be used for teletype access should be named /dev/ttyX, where X is any character. The files tty8 (console), mem, kmem, null are already correctly configured. The disk and magtape drivers provide a ‘raw’ interface to the device which provides direct transmission between the user’s core and the device and allows reading or writing large records. The raw device counts as a character device, and should have the name of the corresponding standard block special file with ‘r’ prepended. Thus the raw magtape files would be called /dev/rmtX. When all the special files have been created, care should be taken to change the access modes (chmod‐I) on these files to appropriate values. ----- Looking at the c.c generated, it has: int (*bdevsw[])() { &nulldev, &nulldev, &rkstrategy, &rktab, &tmopen, &tmclose, &tmstrategy, &tmtab, /* 1 */ &nulldev, &tcclose, &tcstrategy, &tctab, 0 }; int (*cdevsw[])() { &klopen, &klclose, &klread, &klwrite, &klsgtty, &nulldev, &nulldev, &mmread, &mmwrite, &nodev, &nulldev, &nulldev, &rkread, &rkwrite, &nodev, &tmopen, &tmclose, &tmread, &tmwrite, &nodev, /* 3 */ &dcopen, &dcclose, &dcread, &dcwrite, &dcsgtty, &lpopen, &lpclose, &nodev, &lpwrite, &nodev, 0 }; Following on from the docs, you should be able to make the /dev/mt0 device file by doing: /etc/mknod /dev/tm0 b 1 0 And possibly also: /etc/mknod /dev/rmt0 c 3 0 Cheers, Warren

10 years, 12 months

1
0
0 0

Compiling the unix v5 kernel

by Warren Toomey

All, just received this from a fellow who isn't on the TUHS mail list (yet). I've answered him about using mknod (after reading the 6e docs: we don't have 5e docs). I thought I'd forward the e-mail here as a record of an attempt to rebuild the 5e kernel. Cheers, Warren ----- Forwarded message from Mark ----- I hope you don't mind me asking you about compiling the unix v5 kernel. I haven't been able to find any documentation for it. I tried this: ./mkconf rk tm tc dc lp ctrl-d # as mch.s # mv a.out mch.o # cc -c c.c # as l.s # ld -x a.out mch.o c.o ../lib1 ../lib2 There was no m40.s in v5 so I substituted mch.s for m40.s and that seemed to create a kernel and it booted but I can't access /dev/mt0. Any pointers are appreciated. Thanks for all your work on early unix, I thought it was very interesting. Mark ----- End forwarded message -----

10 years, 12 months

1
0
0 0

Re: [TUHS] Excise process from a pipe

by jnc＠mercury.lcs.mit.edu

PS: I see I have over-generalized the problem. Doug's original message say "a process could excise itself from a pipeline". So presumably the initiation would come from process2 itself, and it would know when it had no internally-buffered data. So now we're back to the issue of 'either we need a system call to merge two pipes into one, or the process has to hang around and turn itself into a cat'. Noel

10 years, 12 months

1
0
0 0

Re: [TUHS] Excise process from a pipe

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> > Making what you are talking about work is gonna be a mess of buffer > management and it's going to be hard to design system calls that would > work and still give you reasonable semantics on the pipe. Consider > calls that want to know if there is data in the pipe Oh, I didn't say it would work well, and cleanly! :-) I mean, taking one element in an existing, operating, chain, and blowing it away, is almost bound to cause problems. My previous note was merely to say that the file descriptor/pipe re-arrangement involved might be easier done with a system call - in fact, now that I think about it, as someone has already sort of pointed out, without a system call to merge the two pipes into one, you have to keep the middle process around, and have it turn into a 'cat'. Thinking out loud for a moment, though, along the lines you suggest.... Here's one problem - suppose process2 has read some data, but not yet processed it and output it towards process3, when you go to do the splice. How would the anything outside the process (be it the OS, or the command interpreter or whatever is initiating the splice) even detect that, much less retrieve the data? Even using a heuristic such as 'wait for process2 to try and read data, at which point we can assume that it no longer has any internally buffered data, and it's OK to do the splice' fails, because process2 may have decided it didn't have a complete semantic unit in hand (e.g. a complete line), and decided to go back and get the rest of the unit before outputting the complete, processed semantic unit (i.e. including data it had previously buffered internally). And suppose the reads _never_ happen to coincide with the semantic units being output; i.e. process2 will _always_ have some buffered data inside it, until the whole chain starts to shut down with EOFs from the first stage? In short, maybe this problem isn't solvable in the general case. In which case I guess we're back to your "Every utility that you put in a pipeline would have to be reworked". Stages would have to have some way to say 'I am not now holding any buffered data', and only when that state was true could they be spliced out. Or there could be some signal defined which means 'go into "not holding any buffered data" state'. At which point my proposed splice() system call might be some use... :-) Noel

10 years, 12 months

2
1
0 0

Re: [TUHS] Excise process from a pipe

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> > Every utility that you put in a pipeline would have to be reworked to > pass file descriptors around Unless the whole operation is supported in the OS directly: if ((pipe1 = process1->stdout) == process2->stdin) && ((pipe2 = process2->stdout) == process3->stdin) { prepend_buffer_contents(pipe1, pipe2); process1->stdout = process2->stdout; kill_pipe(pipe1); } to be invoked from the chain's parent (e.g. shell). (The code would probably want to do something with process2's stdin and stdout, like close them; I wouldn't have the call kill process2 directly, that could be left to the parent, except in the rare cases where it might have some use for the spliced-out process.) Noel

10 years, 12 months

2
1
0 0

Subject:unpipeIt'seasy for a process to insert a new process intoapipelineeither upstream or down unpipe

by Doug McIlroy

It's easy for a process to insert a new process into a pipeline either upstrean or downstream. Was there ever a flavor of Unix in which a process could excise itselfa from a pipeline without breaking the pipeline? Doug

10 years, 12 months

5
7
0 0

Re: [TUHS] soviet computing

by norman＠oclsc.org

Armando P. Stettner: If I've said once, I've said it a million times: DECvax is NOT connected to kremvax. :) ==== Not any more, anyway. Norman Wilson Toronto ON (once upon a time, research!norman)

10 years, 12 months

1
0
0 0

soviet computing

by Tim Newsham

slightly off-topic but probably of interest to mailing list members: Pioneers of Soviet Computing http://www.sigcis.org/files/SIGCISMC2010_001.pdf -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com

10 years, 12 months

6
5
0 0

1st Unix w/ ISO-8859-1 support?

by Dario Niedermann

Keywords: encoding, charset, latin, roman, accented, diacritical Hi! Does anyone know which was the earliest Unix release to support the ISO-8859-1 character set?

11 years

1
0
0 0

Museo dell'Informatica Funzionante - CONTRIBUTE!

by asbesto

Hi there, Sorry for an eventual Offtopic but this is strictly related to our Computer Museum activity... We launched a campaign to get some help for our upcoming initiative, that will be the starting point for a big step forward to a new Museum! So please take time to read it, and please share everywhere to anyone interested! http://igg.me/at/insertcoin love asbesto

11 years

1
0
0 0

Re: [TUHS] 40 years of Unix CACM Article

by Warren Toomey

Knowing Dave and his long history with Unix, I suspect it was simply a typo. Just like vi commands are now hardwired into my fingers, I guess K&R is imprinted on his fingers. Cheers, Warren On 28 June 2014 17:12:14 AEST, Armando Stettner <aps(a)ieee.org> wrote: >K&R usually refers to Brian Kernighan and Dennis Ritchie, writers of >the (I think) first book on C. If there were two people to acknowledge >for getting it right, it would be Ken and Dennis. > > aps > > >Begin forwarded message: > >> From: Warren Toomey <wkt(a)tuhs.org> >> Subject: [TUHS] 40 years of Unix CACM Article >> Date: June 28, 2014 at 12:02:06 AM PDT >> To: tuhs(a)tuhs.org >> >> Just in from an early Unix devotee. >> Warren >> >> From: Dave Horsfall <dave(a)horsfall.org> >> Sent: 28 June 2014 16:14:18 AEST >> To: Auug Talk <talk(a)lists.auug.org.au> >> Subject: [AUUG-Talk]: 40 years of Unix >> >> Next month sees the 40th anniversary of the article "The Unix >Timesharing >> System" published in Communications of the ACM; I was at UNSW at the >time, >> and we bought the first tape for subsequent distribution. >> >> At the time its only competitor was RSTS-11, and to a lesser extent >> RSX-11D and RSX-11M (all DEC systems). It saw CP/M vanish, MS-DOS >come >> and go, NT tried to challenge it, and even Windows hasn't beaten it. >> >> It spawned Linux, which Billy Gates regarded as a serious threat >("any box >> running Linux is not running Windows") and even tried a smear >campaign >> against it. >> >> Unix was a design that "just worked" because K&R simply got it right, > >> right from the start. >> >> It'll never go away. >> >> -- Dave >> >> Applix 1616 mailing list >> Applix-L(a)object-craft.com.au >> https://www.object-craft.com.au/cgi-bin/mailman/listinfo/applix-l >> >> Talk - The AUUG discussion list. >> Talk(a)lists.auug.org.au >> https://lists.auug.org.au/listinfo/talk >> >> -- >> Sent from my Android phone with K-9 Mail. Please excuse my >brevity._______________________________________________ >> TUHS mailing list >> TUHS(a)minnie.tuhs.org >> https://minnie.tuhs.org/mailman/listinfo/tuhs -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

11 years

1
0
0 0

40 years of Unix CACM Article

by Warren Toomey

Just in from an early Unix devotee. Warren -------- Original Message -------- From: Dave Horsfall <dave(a)horsfall.org> Sent: 28 June 2014 16:14:18 AEST To: Auug Talk <talk(a)lists.auug.org.au> Subject: [AUUG-Talk]: 40 years of Unix Next month sees the 40th anniversary of the article "The Unix Timesharing System" published in Communications of the ACM; I was at UNSW at the time, and we bought the first tape for subsequent distribution. At the time its only competitor was RSTS-11, and to a lesser extent RSX-11D and RSX-11M (all DEC systems). It saw CP/M vanish, MS-DOS come and go, NT tried to challenge it, and even Windows hasn't beaten it. It spawned Linux, which Billy Gates regarded as a serious threat ("any box running Linux is not running Windows") and even tried a smear campaign against it. Unix was a design that "just worked" because K&R simply got it right, right from the start. It'll never go away. -- Dave _______________________________________________ Applix 1616 mailing list Applix-L(a)object-craft.com.au https://www.object-craft.com.au/cgi-bin/mailman/listinfo/applix-l _______________________________________________ Talk - The AUUG discussion list. Talk(a)lists.auug.org.au https://lists.auug.org.au/listinfo/talk -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

11 years

1
0
0 0

Re: [TUHS] Happy birthday, core dumped

by Douglas Comer

> Ahh! I wonder if they'll be making images and PDFs available? If you want to check, my contact has been: William Harnack <wharnack(a)computerhistory.org> Doug

11 years

1
0
0 0

Re: [TUHS] Happy birthday, core dumped

by Douglas Comer

> > Have Xinu media to go with it? It's something I've been trying to track down. ;) > > Have you asked Doug? I've copied him I just donated my extra copy of Xinu tapes and floppies to the computer museum (along with first editions of the books). > (Hey Doug, you should be on this list, all the long time unix nerds seem to be > here, lots of fun with memory lane). I'd be happy to join. Doug

11 years

9
9
0 0

Re: [TUHS] Happy birthday, core dumped

by Doug McIlroy

They pitched a PDP-10 for a similar reason--hardware to build a bigger Unix on. When a small pot of end-of-year money appeared, they took a PDP-11 instead--serendipitously, because university folks started proving this elegant system on cheap hardware in many projects in small labs, which they never could have done had the system existed on a PDP-10 mainframe. While upper management did not directly cause Unix to be built, their decisions to abandon Multics and not to buy a PDP-10 were notable causes for its creation and spread. Doug > Date: Wed, 18 Jun 2014 07:43:51 -0700 > From: iking(a)killthewabbit.org > To: tuhs(a)minnie.tuhs.org,Doug McIlroy <doug(a)cs.dartmouth.edu> > Subject: Re: [TUHS] Happy birthday, core dumped > Message-ID: <ef723f8a-52b6-4810-be59-1837c75b1da3.maildroid@localhost> > Content-Type: text/plain; charset="utf-8" > > Interesting - what's your source? It was also my understanding they used the -7 'because it was there' but that they had pitched for a PDP-10, which had TOPS-10. - Ian > > Sent from my android device. > > -----Original Message----- > From: Doug McIlroy <doug(a)cs.dartmouth.edu> > To: tuhs(a)minnie.tuhs.org > Sent: Wed, 18 Jun 2014 4:06 AM > Subject: Re: [TUHS] Happy birthday, core dumped > > > > It's always been a bit of a mystery to me why Thompson and Ritchie decided they needed to write a new executive - UNICS - rather than use DECsys. > > It was the other way around. They had conceived a clean, simple, yet > powerful, operating system and needed a machine to build it on. A > cast-off PDP-7 happened to be at hand. > > Doug

11 years

1
0
0 0

Re: [TUHS] Happy birthday, core dumped

by jnc＠mercury.lcs.mit.edu

> From: "A. P. Garcia" <a.phillip.garcia(a)gmail.com> > that's like asking george martin for his source regarding a beatles > song... Reminds me of the person on Wikipedia who tried to argue with me about the 'History of the Internet' article... :-) > From: John Cowan <cowan(a)mercury.ccil.org> >> scj(a)yaccman.com scripsit: >> a Dec repair person who ran "preventive maintenance" on our disc that >> wiped out the file system! His excuse was that Dec didn't support >> "permanent storage" on the disc at the time... > Next time, mount a scratch monkey. It was probably a fixed-head disk (RS11 or RS04); can't exactly stick a different pack in! :-) Probably the DEC OS's only used it for swapping or something, since they were both relatively small - 512KB. (Speaking of RS11's: the first PDP-11 I used - an 11/20 running RSTS - had a grand total disk storage of _one_ RS11!) And speaking of putting file systems on them: I recently wrote this command for V6 called 'si' which allowed me (among many other interesting things) to watch the contents of the disk buffer(s). It turns out that even with other packs mounted, the buffer is almost always completely full of blocks from the root device; it makes plain the value of having the root on a _really_ fast disk. I don't know if that usage pattern is because /bin is there, or because pipes get created on the root, or what. When I get up the energy I'll move /bin to another drive (yeah, yeah, I know - good way to lose and create a systen that won't boot, so I'll actually make a _copy_ of /bin and mount it _over_ the original /bin - probably a host of interesting errors there, e.g. if a process has the old /bin as its current dir), and see what the cache contents look like then. Noel

11 years

2
1
0 0

Tree of late BSD releases

by Diomidis Spinellis

For reconstructing Unix history on a single repository [1], I'd need to represent the branches, merges, and chronological sequence of the late BSD releases (after 4.3). However, I've found on the internet some conflicting and simplistic information, so I'd welcome your input on how to straighten things up. First, consider this widely reproduced BSD family tree [2]. It has 4.4BSD-Encumbered derive from a line that includes Net/1, which was freely redistributable. Wouldn't it be clearer to create two branches, one with distributions free of AT&T code (4.3 BSD Net/1, 4.3 BSD Net/2, 4.4 BSD Lite1, 4.4 BSD Lite2) and one with full distributions (4.4 BSD, ...)? On which side would Tahoe and Reno stand? Also, the same tree [2] shows 4.4 BSD having as its ancestor 4.3 BSD Net/2, whereas another tree depicted on Wikipedia [3] has shows 4.4 BSD and 4.3 BSD Net/2 having as their ancestor 4.3 BSD Reno. What's the correct genealogy? Finally, I have a conflict with release dates. Wikipedia gives the following dates for Tahoe and Net/1 [4]: 4.3 BSD Tahoe June 1988 4.3 BSD Net/1 June 1989 However, looking at time-stamp of the newest files available under the corresponding directories in the CSRG CD-ROMs [5] I find the opposite order: cd2/net.1/sendmail/src/util.c 1989-01-01 12:15:58 cd2/4.3tahoe/usr/src/sys/tahoevba/vx.c 1989-05-23 13:47:43 What's the actual time sequence, and what's the corresponding genealogy? [1] https://github.com/dspinellis/unix-history-repo [2] http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/share/misc/bsd-family-t… [3] https://en.wikipedia.org/wiki/File:Unix_history-simple.svg [4] https://en.wikipedia.org/wiki/Berkeley_Software_Distribution [5] https://www.mckusick.com/csrg/ Many thanks, Diomidis Spinellis PS Thank you all for the help you've provided so far.

11 years

2
1
0 0

Re: [TUHS] Happy birthday, core dumped

by Norman Wilson

Interesting - what's your source? It was also my understanding they used the -7 'because it was there' but that they had pitched for a PDP-10, which had TOPS-10. ====== I think Doug's source is in the class `personal observation.' He was there at the time; Ken and Dennis's department head, if I've got it right. Remember that Bell Labs had just disengaged itself from the Multics project. The interest in a new OS sprang partly from the desire to have a comfortable multi-user system now that Multics was no longer available. That's why the DEC operating systems of the time, which were (as I understand it) simple single-user monitors, didn't fill the bill. The character of the players matters too: remember that Ken is the guy who one night sat down to write a Fortran compiler because real systems have Fortran, and ended up inventing B instead. I've read that there was indeed a pitch to buy a PDP-10; that there was some complicated plan to lower the effective cost; and that upper management (not Doug) turned it down because `Bell Labs doesn't do business that way.' I think I got that from Dennis's retrospective paper, published in the 1984 all-UNIX issue of the Bell Labs Techical Journal, a must-read (along with the late-1970s all-UNIX issue of BSTJ) for anyone on this list.

11 years

6
6
0 0

Re: [TUHS] Happy birthday, core dumped

by Doug McIlroy

> It's always been a bit of a mystery to me why Thompson and Ritchie decided they needed to write a new executive - UNICS - rather than use DECsys. It was the other way around. They had conceived a clean, simple, yet powerful, operating system and needed a machine to build it on. A cast-off PDP-7 happened to be at hand. Doug

11 years

4
3
0 0

Happy birthday, core dumped

by Norman Wilson

Jay Forrester, who invented core memory, first described it in a lab notebook 65 years ago today. (Thanks to the Living Computer Museum, through whose Twitter feed I learned this tidbit. It's a place--the real museum, not just the Twitter feed--many on this list might enjoy: among their aged-but-working computers are a Xerox Star and a PDP-7.) Norman Wilson Toronto ON

11 years

6
7
0 0

pdp11 available

by Milo Velimirović

Greetings, I have a pdp11/84 and various peripherals available to whomever is willing to take them. I'm in La Crosse, Wisconsin, USA. pdp11/84 RX01 TU80 2 cabs of 2ea RA81 Thanks, Milo -- Milo Velimirović La Crosse, Wisconsin 54601 USA 43 48 48 N 91 13 53 W

11 years

1
0
0 0

4.1BSD Networking

by Cory Smelosky

Hello all, recent subscriber to this list...but some might recognise me. I'm currently fighting (and mostly succeeding) with getting a pure 4.3BSD-Tahoe install rolling in a VAX simulator (all my tape drives are currently nonfunctional or I'd fire up a real II or III). Still in the middle of compiling (I know there are easier ways...but I like the feeling of doing it purely "from scratch"...feels more historically accurate). Anyways, while waiting for the compile I ended up with a working 4.1c installation and I began poking around its source tree (I also did a little bit of poking at the CSRG discs). I stumbled upon the fact 4.1c supports the DMC (which SIMH git now emulates!) and I see it's also still in src/old on some versions of 4.3 (I wonder if it'll still build...). Looking at the source is immensely confusing...does anyone have any knowledge/notes from the time period/documentation that will help me with my little experiment in archaic networking? I might just be tired...but the berknet configuration doesn't make a whole lot of sense to me. (There's also the fact my grasp of C is minimal). -- Cory Smelosky http://gewt.net Personal stuff http://gimme-sympathy.org Projects

11 years

3
3
0 0

Archive of old ;login or EUUG newsletters?

by Warren Toomey

Speaking of old publications, is there an on-line archive of old ;login: or EUUG newsletters? I did one for the AUUG newsletters here: http://minnie.tuhs.org/Archive/Documentation/AUUGN/ but it would be nice to have an archive for the U.S and Europe. Cheers, Warren

11 years

2
1
0 0

Re: [TUHS] UNIX magazines

by Nelson H. F. Beebe

There is a complete bibliography of the journal Computing Systems (1988--1996) here: http://www.math.utah.edu/pub/tex/bib/compsys.bib [change .bib to .html for a version with hyperlinks] Other journals about aspects of Unix include: Bell System Technical journal family (complete 1920--date) http://www.math.utah.edu/pub/tex/bib/bstj1920.bib http://www.math.utah.edu/pub/tex/bib/bstj1930.bib http://www.math.utah.edu/pub/tex/bib/bstj1940.bib http://www.math.utah.edu/pub/tex/bib/bstj1950.bib http://www.math.utah.edu/pub/tex/bib/bstj1960.bib http://www.math.utah.edu/pub/tex/bib/bstj1970.bib http://www.math.utah.edu/pub/tex/bib/bstj1980.bib http://www.math.utah.edu/pub/tex/bib/bstj1990.bib http://www.math.utah.edu/pub/tex/bib/bstj2000.bib http://www.math.utah.edu/pub/tex/bib/bstj2010.bib Journal of C Language Translation (1989--1995) http://www.math.utah.edu/pub/tex/bib/jclt.bib Usenix conference proceedings and ";login" journal (incomplete) http://www.math.utah.edu/pub/tex/bib/usenix1980.bib http://www.math.utah.edu/pub/tex/bib/usenix1990.bib http://www.math.utah.edu/pub/tex/bib/usenix2000.bib http://www.math.utah.edu/pub/tex/bib/usenix2010.bib The X Resource: A Practical Journal of the X Window System (1991--1994) http://www.math.utah.edu/pub/tex/bib/xres.bib There are also bibliographies of books about Unix, Linux, and the GNU Project: http://www.math.utah.edu/pub/tex/bib/gnu.bib http://www.math.utah.edu/pub/tex/bib/linux.bib http://www.math.utah.edu/pub/tex/bib/unix.bib Finally, there is a small bibliography of the AT&/Princeton lcc compiler: http://www.math.utah.edu/pub/tex/bib/lcc.bib There are more than 800 bibliographies in those archives with about 1.01 million entries. Please mirror them to your site(s): mirror instructions, overviews, and space requirements can be found at the top-level sites http://www.math.utah.edu/pub/tex/bib/ http://www.math.utah.edu/pub/bibnet/ The collections are active, and continuously enhanced and extended, with dozens of files being updated or added weekly. Using rsync for mirroring is easy and fast, so nightly or weekly mirrors pose no problem at either end of the connection. There is also a TUHS mirror in Salt Lake City, Utah: http://www.math.utah.edu/pub/mirrors/minnie.tuhs.org/ It too can be mirrored with rsync. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

11 years

2
1
0 0

Re: [TUHS] TUHS Digest, Vol 113, Issue 21

by jgsinowitz＠yahoo.com

This is a very enjoyable thread to follow! Jonah G Sinowitz Consultant 320 8th Street, #19 Lakewood, NJ 08701 732.367.7450

11 years

1
0
0 0

Re: [TUHS] UNIX magazines

by norman＠oclsc.org

Doug McIlroy: > Does anyone know why [Computing Systems] folded? Arnold Skeeve: ISTR that they simply ran out of content; they weren't getting enough submissions to keep it going, and journal production isn't an inexpensive undertaking. ====== That's what I remember too, though there may also have been insufficient interest from the members. The front matter in the last issue suggests that. Computing Systems was published from Winter 1988 to Fall 1996. (More years than I'd have guessed, even looking at the physical journals on my shelf; it was a quarterly.) It would probably not have lasted much longer no matter what, as the USENIX community was likely in the forefront of putting papers online on the World-Wide Web. USENIX now makes all their conference papers available online, free to anyone, except that only those registered for a conference can read them before the conference actually happens. That's not a bad substitute for a journal, I suppose. Norman Wilson Toronto ON

11 years

4
3
0 0

Re: [TUHS] UNIX magazines

by norman＠oclsc.org

'skeeve' is my domain name. Robbins is my surname. Sorry about that; up too late with too many balls in the air (packing, finishing a tax return, listening to our provincial election results). At least I didn't further truncate it to skeev, as Ken might have done.

11 years

2
1
0 0

Re: [TUHS] UNIX magazines

by Brian Walden

UNIX/WORLD started in 1984 and was renamed UnixWorld Magazine: Open Systems Computing in 1991 and then UnixWorld's Open Computing in 1994 and it folded in 1995. SunExpert started in 1989 was renamed to Server/Workstatsion Expert in 1999 and it folded in 2001. I always enjoyed Mike OBrien's offbeat "Ask Mr. Protocol" > From: Dan Cross <crossd(a)gmail.com> > There were several, starting I guess in the 80s mostly. The one I remember > in particular was "Unix Review", but there were a few "journal" type > magazines that also specialized in Unix-y things (e.g., ";login:" from > USENIX; still published, I believe), and several associated with particular > vendors: "SunExpert" was one, if I recall correctly. > > Occasionally, Unix and related things showed up in the "mainstream" > consumer computer press of the time. I can remember in particular an issue > of "PC Magazine" (I think June of 1993) that ran a lengthy couple of > articles proving machines from Sun and SGI, in addition to version of Unix > that ran on PCs (interestingly, Linux was omitted despite really starting > to capture a lot of the imagination in that space; similarly I don't recall > any mention of BSD). > > Some of these old magazines are definitely blasts from the past. > > - Dan C. > > > > On Wed, Jun 11, 2014 at 11:10 PM, Sergey Lapin <slapinid(a)gmail.com> wrote: > > > Hi, all! > > > > I've read recently published link to byte article and got an idea.... > > Was there a magazine related to UNIX systems in 70s-80s? > > I had so much fun reading that Byte issue, even ads (especially ads!) > > It is so fun... > > > > _______________________________________________ > > TUHS mailing list > > TUHS(a)minnie.tuhs.org > > https://minnie.tuhs.org/mailman/listinfo/tuhs > >

11 years

1
0
0 0

Re: [TUHS] UNIX magazines

by Doug McIlroy

> ;login: is alive and well. For a few years Usenix even published a refereed technical journal, "Computing Systems", quite different in tone from ;login: It had some nice content. Does anyone know why it folded? Doug

11 years

2
1
0 0

Re: [TUHS] UNIX magazines

by norman＠oclsc.org

Dan Cross: ... there were a few "journal" type magazines that also specialized in Unix-y things (e.g., ";login:" from USENIX; still published, I believe) ... ====== ;login: is alive and well. So is USENIX. It's no longer the UNIX user's group it started as many decades ago; the focus has broadened to advanced computing and systems research, though the descendants of UNIX are still prominent in those areas. For an old-fashioned programmer/systems hack/systems generalist like me, it's still quite a worthwhile journal and a worthwhile organization. They've even been known to have a talk or two about resurrecting old versions of UNIX. I'm just off to the federation of medium-sized conferences and workshops that has grown out of the former USENIX Annual Technical Conference. I'm looking forward to it. Norman Wilson Toronto ON

11 years

1
0
0 0

UNIX magazines

by Sergey Lapin

Hi, all! I've read recently published link to byte article and got an idea.... Was there a magazine related to UNIX systems in 70s-80s? I had so much fun reading that Byte issue, even ads (especially ads!) It is so fun...

11 years

6
6
0 0

Gnu/Stallman (was Bugs in V6 'dcheck')

by Doug McIlroy

Phil Garcia wrote: I've always wondered about something else, though: Were the original Unix authors annoyed when they learned that some irascible young upstart named Richard Stallman was determined to make a free Unix clone? Was he a gadfly, or just some kook you decided to ignore? The fathers of Unix have been strangely silent on this topic for many years. Maybe nobody's ever asked? Gnu was always taken as a compliment. And of course the Unix clone was pie in the sky until Linus came along. I wonder about the power relationship underlying "GNU/Linux", as rms modestly styles it. There are certain differences in taste between Unix and Gnu, vide emacs and texinfo. (I grit my teeth every time a man page tells me, "The full documentation for ___ is maintained as a Texinfo file.") But all disagreement is swept away before the fact that the old familiar environment is everywhere, from Cray to Apple, with rms a very important contributor. Doug

11 years

25
55
0 0

SunOS 4.1.1 or later?

by Larry McVoy

Does anyone have that running on anything? If so, I'd like a copy of the lint libraries, probably /usr/lib/ll* or something like that. It's not well known but I spent a pile of time creating lint libraries for pure BSD, System V, etc, so you could lint your code against a target and know if you let some non-standard stuff creep in. I suppose I could fire up a Sun3 emulator like this and find them: http://www.abiyo.net/retrocomputing/installingsunos411tosun3emulatedintme08… If someone has a SunOS 4.1.1 box on the net and can give me a login (non-root) that would be appreciated. Thanks, --lm

11 years, 1 month

2
2
0 0

unix history git

by Tim Newsham

have you guys seen this? https://github.com/dspinellis/unix-history-repo (I'm not involved, just came across it by way of twitter) -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com

11 years, 1 month

6
6
0 0

Re: [TUHS] Bugs in V6 'dcheck'

by Nelson H. F. Beebe

I noted just as I sent my previous posting with two references to fuzz-test papers that the abstract of the second mentions two earlier ones. I've just tracked them down, and added them to various bibliographies. Here are short references to them: Fuzz Revisited: A Re-examination of the Reliability of UNIX Utilities and Services ftp://ftp.cs.wisc.edu/pub/techreports/1995/TR1268.pdf An Empirical Study of the Robustness of MacOS Applications Using Random Testing http://dx.doi.org/10.1145/1228291.1228308 ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu - - 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - -------------------------------------------------------------------------------

11 years, 1 month

1
0
0 0

Re: [TUHS] Bugs in V6 'dcheck'

by Doug McIlroy

> Ken and Dennis and the other guys behind > the earliest UNIX code were smart guys and good programmers, > but they were far from perfect; and back in those days we > were all a lot sloppier. The observation that exploits may be able to parlay mundane bugs into security holes was not a commonplace back then--even in the Unix room. So input buffers were often made "bigger than ever will be needed" and left that way on the understanding that crashes are tolerable on outlandish data. In an idle moment one day, Dennis fed a huge line of input to most everything in /bin. To the surprise of nobody, including Dennis, lots of programs crashed. We WERE surprised a few years later, when a journal published this fact as a research result. Does anybody remember who published that deep new insight and/or where? Doug

11 years, 1 month

6
6
0 0

Re: [TUHS] Bugs in V6 'dcheck'

by jnc＠mercury.lcs.mit.edu

> From: norman(a)oclsc.org (Norman Wilson) > SP&E published a paper by Don Knuth discussing all the many bugs found > in TeX, including some statistical analysis. > From: John Cowan <cowan(a)mercury.ccil.org> > "The Errors of TeX" was an excellent article. Thanks for the pointer; it sounds like a great paper, but alas the only copies I could fine online were behind paywalls. > From: Clem Cole <clemc(a)ccc.com> > btw. there is a v6 version of fsck floating around. Yes, we had it at MIT. > I'm wonder if I can find a readable copy. As I've mentioned, I have this goal of putting the MIT Unix (the kernel was basically PWB1, with a host of new applications) sources online. I have recently discovered (in my basement!) two sets of full dump tapes (1/2" magtape) of what I think are the whole filesystem, so if I can find a way to get them read, we'll have the V6 fsck - and much more besides (such as a TCP/IP for V6). So I think you may soon get your wish! Noel

11 years, 1 month

4
3
0 0

Re: [TUHS] Bugs in V6 'dcheck'

by jnc＠mercury.lcs.mit.edu

> From: "Ron Natalie" <ron(a)ronnatalie.com> > The variable in question was a global static, 'ino' (the current inode > number), > Static is a much overloaded word in C, it's just a global variable. Sorry; I was using 'static' in the general CS sense, not C-specific! > in the version 7 version of icheck .. they appear to have fixed it. Actually, they seem to have got all three bugs I saw (including the one I hadn't actually experienced yet, which would cause a segmentation violation). > From: Tim Newsham <tim.newsham(a)gmail.com> > There are bugs to be found .. Here are some more (security related, as > thats my inclination): > ... > http://minnie.tuhs.org/pipermail/unix-jun72/2008-May/000126.html Fascinating mailing list! Thanks for the pointer. Noel

11 years, 1 month

1
0
0 0

Re: [TUHS] Bugs in V6 'dcheck'

by msokolov＠ivan.Harhan.ORG

A. P. Garcia <a.phillip.garcia(a)gmail.com> wrote: > Were the original Unix authors annoyed when they learned that > some irascible young upstart named Richard Stallman was determined to make > a free Unix clone? A deeper, more profound question would be: how did these original Unix authors feel about their employer owning the rights to their creation? Did they feel any guilt at all for having had to sign over all rights in exchange for their paychecks? Did Dennis and/or Ken personally wish their creation were free to the world, public domain, or were they personally in agreement with the licensing policies of their employer? I argue that this question is far more important than how they felt about RMS (if they cared at all). Ronald Natalie <ron(a)ronnatalie.com> wrote: > [RMS] If you read his earlier manifesto rants he hated UNIX = > with a passion. > Holding out the TOPS operating systems as the be-all and end-all of user = > interface. I wish more people would point out this aspect of RMS and GNU. While I wholeheartedly agree with Richard on the general philosophy of free software, i.e., the *ethics* part and the Four Freedoms, when it comes to GNU as a specific OS, in technical terms, I've always disliked everything about it. I love UNIX, and as Ron pointed it out like few people do, GNU was fundamentally born out of hatred for the thing I love. SF

11 years, 1 month

2
1
0 0

Bugs in V6 'dcheck'

by jnc＠mercury.lcs.mit.edu

So it turns out the 'dcheck' distributed with V6 has two (well, three, but the third one was only a potential problem for me) bugs it. The first was a fence-post error on a table clearing operation; it could cause the entry for the last inode of the disk in the constructed table of directory entry counts to start with a non-zero count when a second disk was scanned. However, it was only triggered in very specific circumstances: - A larger disk was listed before a smaller one (either in the command line, or compiled in) - The inode on the larger disk corresponding to the last inode on the smaller one was in use I can understand how they never ran across this one. The other one, however, which was an un-initalized variable, should have bitten them anytime they had more than one disk listed! It caused the constructed table of directory entry counts to be partially or wholly (depending on the size of the two disks) blank in all disks after the first one, causing numerous (bogus) error reports. (It was also amusing to find an un-used procedure in the source; it looks like dcheck was written starting with the code for 'icheck' - which explains the second bug; since the logic in icheck is subtly different, that variable _is_ set properly in icheck.) How this bug never bit them I cannot understand - unless they saw it, and couldn't be bothered to find and fix it! To me, it's completely amazing to find such a serious bug in such a critical piece of widely-distributd code! A lesson for archaeologists... Anyway, a fixed version is here: http://ana-3.lcs.mit.edu/~jnc/tech/unix/ucmd/dcheck.c if anyone cares/needs it. Noel

11 years, 1 month

4
3
0 0

Re: [TUHS] Bugs in V6 'dcheck'

by John Cowan

Larry McVoy scripsit: > I love Rob Pike, he's spot on on a lot of stuff. I'm a big fan of > "if you think you need threads then your processes are too fat". Oh, he's a brilliant fellow. I don't know him personally, but I know people who do, and I don't think I'd love him if I knew him. Humanity has always found it useful to keep its (demi)gods at arm's length at least. -- John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org Barry thirteen gules and argent on a canton azure fifty mullets of five points of the second, six, five, six, five, six, five, six, five, and six. --blazoning the U.S. flag

11 years, 1 month

1
0
0 0

Re: [TUHS] Bugs in V6 'dcheck'

by jnc＠mercury.lcs.mit.edu

> From: jnc(a)mercury.lcs.mit.edu (Noel Chiappa) > the second (the un-initialized variable) should have happened every > time. OK, so I was wrong! The variable in question was a global static, 'ino' (the current inode number), so the answer isn't something simple like 'it was an auto that happened to be cleared for each disk'. But now that I look closely, I think I see a way it might have worked. 'dcheck' is a two-pass per disk thing: it begins each disk by clearing its 'inode link count' table; then the first pass does a pass over all the inodes, and for ones that are directories, increments counts for all the entries; the second pass re-scans all the inodes, and makes sure that the link count in the inode itself matches the computed count in the table. 'ino' was cleared before the _second_ pass, but not the _first_. So it was zero for the first pass of the first disk, but non-zero for the first pass on the second disk. This looks like the kind of bug that should almost always be fatal, right? That's what I thought at first... (and I tried the original version on one of my machines to make sure it did fail). But... The loop in each pass has two index variables, one of which is 'ino', which it compares with the maximum inode number for that disk (per the super-block), and bails if it reaches the max: for(i=0; ino<nfiles; i =+ NIBLK) If the first disk is _larger_ than the second, the first pass will never execute at all for the second desk (producing errors). However, if the _second_ is larger, then the second disk's first pass will in fact examine the starting (nfilesSUBsecond - nfilesSUBfirst) inodes of the second disk to see if they are directories (and if so, count their links). So if the last nfilesSUBfirst inodes of the second disk are empty (which is often the case with large drives - I had modified 'df' to count the free inodes as well as disk blocks, and after doing so I noticed that Unix seems to be quite generous in its default inode allocations), it will in fact work! The fact that 'ino' is wrong all throughout the first pass of the second disk (it counts up from nfilesSUBfirst to nfilesSUBsecond) turns out to be harmless, because the first pass never uses the current inode number, it only looks at the inode numbers in the directories. Note that with two disks of _equal size_, it fails. Only if the second is larger does it work! (And this generalizes out to N disks - as long as each one is enough larger than the one before!) So for the config they were running (rk2, dp0) it probably did in fact work! Noel

11 years, 1 month

2
1
0 0

Bugs in V6 'dcheck'

by norman＠oclsc.org

Noel Chiappa: To me, it's completely amazing to find such a serious bug in such a critical piece of widely-distributd code! A lesson for archaeologists... ====== To me it's not surprising at all. On one hand, current examples of widely-distributed critical code containing serious flaws are legion. What, after all, were the Heartbleed and OS X goto fail; bugs? What is every version of Internet Explorer? On the other hand, Ken and Dennis and the other guys behind the earliest UNIX code were smart guys and good programmers, but they were far from perfect; and back in those days we were all a lot sloppier. So surprising? No. Interesting? Certainly. All bugs are interesting. (To me, anyway. Back in the 1980s, when I was at Bell Labs, SP&E published a paper by Don Knuth discussing all the many bugs found in TeX, including some statistical analysis. I thought it fascinating and revealing and think reading it made me a better programmer. Rob Pike thought it was terribly boring and shouldn't have been published. Decidedly different viewpoints.) Norman Wilson Toronto ON

11 years, 1 month

2
1
0 0

Re: [TUHS] Bugs in V6 'dcheck'

by jnc＠mercury.lcs.mit.edu

> From: Ronald Natalie <ron(a)ronnatalie.com> > If I understand what you are saying, it only occurs when you run dcheck > with mutliple volumes at one time? Right, _both_ bugs have that characteristic. But the first one (the fence-post) only happens in very particular circumstances; the second (the un-initialized variable) should have happened every time. > From: norman(a)oclsc.org (Norman Wilson) > To me it's not surprising at all. > On one hand, current examples of widely-distributed critical code > containing serious flaws are legion. What astonished me was not that there was a bug (which I can easily believe), but that it was one that would have happened _every time they ran it_. 'dcheck' has this list of disks compiled into it. (Oh, BTW, my fixed version now reads a file, /etc/disks; I am running a number of simulated machines, and the compiled-in table was a pain.) So I would have thought they must have at least tried that mode of operation once? And running it that way just once should have shown the bug. Or did they try it, see the bug, and 'dealt' with it by just never running it that way? Noel

11 years, 1 month

1
0
0 0

Re: [TUHS] Unix on an 11/23 (Was: Work I've done with a PDP-11 simulator)

by jnc＠mercury.lcs.mit.edu

> From: asbesto <asbesto(a)freaknet.org> > We have about 40 disks, with RT-11 on them Ah. You should definitely try Unix - a much more pleasant computing/etc environment! Although without a video editor... although I hope to have one available 'soon', from the MIT V6+ system (I think I have found some backup tapes from it). > This PDP-11/34 was used for a medical CAT equipment As, so it probably has the floating point, then. If so, you should be able to use the Shoppa V6 Unix disk as it is, then - that has a Unix on it which will work on an 11/23 (which don't have the switch register that V6 normally requires). But if not, let me know, and I can provide a V6 Unix for it (I already have the tweaked version running on a /23 in the simulator). Noel PS: For those who downloaded the 'fixed' ctime.c (if anyone :-), it turns out there was a bug in my fix - in some cases, one variable wasn't initialized properly. There's a fixed one up there now.

11 years, 1 month

1
0
0 0

Re: [TUHS] Unix on an 11/23 (Was: Work I've done with a PDP-11 simulator)

by jnc＠mercury.lcs.mit.edu

> From: asbesto <asbesto(a)freaknet.org> > Just in these days we restored a PDP-11/23PLUS here at our Museum! :) > ... > CPU is working That is good to hear! You all seem to have been very resourceful in making the power supply for it! > and we're trying to boot from a RL02 unit :) Is your RL02 drive and RLV11 controller all working? Here are some interesting pages: http://www.retrocmp.com/pdp-11/pdp-1144/my-pdp-1144/rl02-disk-trouble http://www.retrocmp.com/pdp-11/pdp-1144/my-pdp-1144/more-on-rl01rl02 from someone in Germany about getting their RL11 and RL02 to work. Also, when you say "boot from an RL02", what are you trying to boot? Do you have an RL02 pack with a working system on it? If so, what kind - a Unix of some sort, or some DEC operating system? > From: SPC <spedraja(a)gmail.com> > I'll keep a reference of this message and try it as soon as possible... Speaking of getting Unix to run on an 11/23 with an RL02... I just realized that the hard part of getting a Unix running, for you, will not be getting V6 to run on a machine without a switch register (which is actually pretty easy - I have worked out a way to do it that involves changing one line in param.h, and adding two lines of code to main.c). The hard part is going getting the bits onto the disk! If all you have is an RL02, you are going to have to load bits into the computer over a serial line. WKT has done this for V7 Unix: http://www.tuhs.org/Archive/PDP-11/Tools/Tapes/Vtserver/ but V7 really wants a machine with split I/D (which the /23 does not have). I guess V7 'sort of' works on a machine without I/D, but I'm not a V7 expert, so I can't say for sure. It would not be hard to do something similar to the VTServer thing for V6, though. If you would like to go this way, let me know, I would be very interested in helping with this. Also, do you only have one working RL02 drive, or more than one? If you only have one, you will not be able to do backups (unless you have something else connected to the machine, e.g. some sort of tape drive, or something). Noel

11 years, 1 month

2
1
0 0

Re: [TUHS] Unix on an 11/23 (Was: Work I've done with a PDP-11 simulator)

by jnc＠mercury.lcs.mit.edu

> From: SPC <spedraja(a)gmail.com> > I'll keep a reference of this message and try it as soon as possible... No rush! Take your time... > the disruptive fact (in terms of time) here is to put up-to-date both > the PDP-11/23-PLUS and RL02. My apologies, I just now noticed that you have an 11/23-PLUS (it is slightly different from a plain 11/23). I am not very familiar with the 11/23-PLUS (I never worked with one), but from documentation I just dug out, it seems that they normally come with the MMU chip, so we don't need to worry about that. However, the FPP is not standard, so that is still an issue for bringing up Unix. In fact, there are two different FPP options for the 11/23-PLUS (and, actually, for the 11/23 as well): one is the KEF-11AA chip which goes on the CPU card (on the 11/23-PLUS, in the middle large DIP holder), and the other is something called the FPF-11 card, which is basically hardware floating point (the KEF-11A is just microcode), for people who are doing serious number crunching. It's a quad-size card which has a cable with a DIP header on the end which plugs into the same DIP holder on the CPU card as the KEF-11A. They look the same to software; one is just faster than the other. Anyway, if you don't have either one, we'll have to produce a new Unix load for you (not a big problem, if it is needed). Noel

11 years, 1 month

2
1
0 0

MERT available anywhere?

by jnc＠mercury.lcs.mit.edu

Does anyone know if the source for an early PDP-11 version of MERT is available anywhere? (For those who aren't familiar with MERT, it was a micro-kernel [as we would name it now] which provided message-passing and [potentially shared] memory segments, intended for real-time applications; it supported several levels of protection, using the 'Supervisor' mode available in the 11/45 and 11/70. One set of supervisor processes provided a Unix environment; the combination was called UNIX/RT - hence my asking about it here.) Thanks! Noel

11 years, 1 month

1
0
0 0

Unix on an 11/23 (Was: Work I've done with a PDP-11 simulator)

by jnc＠mercury.lcs.mit.edu

>> I got one PDP-11/23-PLUS without any kind of disk (by now, I got one >> RL12 board plus one RL02 drive pending of cleaning and arrangement)... >> I guess if could be possible to run V6 in this machine. There's any >> kind of adaptation of this Unix version (or whatever) to run under ? > IIRC the README page for that set of disk images indicates that in fact > they originally came off an 11/23, so they should run fine on yours. So I was idly looking through main.c for the Shoppa Unix (because it printed some unusual messages when it started, and I wanted to see that code), and I noticed it had some fancy code for dealing with the clock, and that tickled a very dim memory that LSI-11's had some unusual clock thing. So I decided I had better check up on that... I got out an LSI-11 manual, and it looked like the 23 should work, even for the 'vanilla' V6 from the Bell distro. But I decided I had better check it to be sure, so I fired up the simulator, mounted a Bell disk, set the cpu type to '23', and booted 'rkunix'. Which promptly halted! After a bit of digging, it turned out that the problem is that the 11/23 doesn't have a switch register! It hit a kernel NXM trying to touch it - and then another trying to read it in the putchar() routine trying to do a panic(), at which point it died a horrible death. So I added a SR (you can create all sorts of bizarre hybrids like that with Ersatz-11, like 11/40's with 11/45 type floating point :-), and then it booted fine. The clock even worked! So you will have to use the Shoppa disk to boot (but see below), or we'll have to spin you a special vanilla V6 Unix that doesn't try to touch the SR - that shouldn't be much work, I only found two place in the code that touch it. I did try the Shoppa 'unix', and it booted fine on an 11/23. Two things to check for, though: first, your 11/23 _has_ to have the MMU chip (that's the large DIP package with one chip on it nearest the edge of the card), so if yours looks like this: http://www.psych.usyd.edu.au/pdp-11/Images/23.jpeg you're OK. Without the MMU chip, most variants of Unix will not run on the 23 (although there's something called MiniUnix, IIRC, which runs on an LSI-11, which would probably run on a /23 without an MMU). Here's the part that might be a problem: To run any of the Unixes on the Shoppa disk, you also have to have the FPP chip too (that's the second large DIP package with two chips on it - the image above does not include that chip, so if yours looks like that, you have a minor problem, and I will have to build you a Unix or something). All of the Unixes on the Shoppa disk have to have the FPP, except one - and that one wants an RX floppy as the root/swap device! The others will all crash (I tried one, to make sure) if you try and boot them on an 11/23 without the FPP. I could try patching the binary on the one that doesn't expect to use the FPP to use the RL as the root, or either i) build you a vanilla V6 for a 23 (above), or ii) figure out how to build systems on the Shoppa disk, and build you a Unix there which i) uses the RL as the root/swap, and ii) does not expect to have the FPP. But let's first find out exactly what you have... Noel

11 years, 1 month

4
3
0 0

Re: [TUHS] Work I've done with a PDP-11 simulator

by jnc＠mercury.lcs.mit.edu

> From: SPC <spedraja(a)gmail.com> > I got one PDP-11/23-PLUS without any kind of disk (by now, I got one > RL12 board plus one RL02 drive pending of cleaning and arrangement)... > I guess if could be possible to run V6 in this machine. There's any > kind of adaptation of this Unix version (or whatever) to run under ? As I mentioned in a previous message on this thread, when I took that root pack image from the Shoppa group, I could get it to boot to Unix right off. All it needs is a single RL02 drive (RL/0) (and the console terminal, of course). I looked at the 'unix' on it, and it's for an 11/40 type machine (which includes 11/23's); IIRC the README page for that set of disk images indicates that in fact they originally came off an 11/23, so they should run fine on yours. That Unix has a couple of other devices built into it (looks like an RX and some sort of A-D), but as long as you don't try and touch them, they will not be an issue. Let me know if you need any help getting it up (once you have a working RL02). Noel

11 years, 1 month

2
1
0 0

Re: [TUHS] Work I've done with a PDP-11 simulator

by jnc＠mercury.lcs.mit.edu

> From: John Cowan <cowan(a)mercury.ccil.org> > Well, provided the compiler is honest, contra [Ken]. A thought on this: The C compiler actually produces assembler, which can be (fairly easily) visually audited; yes, yes, I know about disassembly, but trust me, having done some recently (the RL bootstrap(s)), disassembled code is a lot harder to grok! So, really, to find the Thompson hack, we'd have to edit the binaries of the assembler! For real grins, we could write a program to convert .s format assembler to .mac syntax, run the results through Macro-11, and link it with the other linker... :-) Also, I found on what's going on here: > What was wierd was that in the new one, the routine csv is one word > shorter (and so is csv.o). So now I don't understand what made them the > same sizes!? The new ones should have been one word shorter!? Still > poking into this... The C compiler is linked with the -n flag, which produces pure code. What the linker documentation doesn't say (and I never realized this 'back in the day') is that when this option is used, it rounds up the size of the text segment to the nearest click (0100). So, in c2 (which is what I was looking at), the last instruction is at 015446, _etext is at 015450, but if you look at the executable header, it lists a text size of 015500 - i.e. 030 more bytes. And indeed there are 014 words of '0' in the executable file before the data starts. And if you link c2 _without_ the -n flag, it shows 015450 in the header as the text size. So that's why the two versions of all the C compiler phases were the same size (as files); it rounded up to the same place in both, hiding the one-word difference in text size. Noel

11 years, 1 month

3
2
0 0

short file names...

by scj＠yaccman.com

Erg! Discussion of file name length brought back some chilling memories of very early Unix, when file names were at most 6 characters long. Longer names were accepted but truncated at 6 characters. So you could edit ABCDE.c, store it, read it and edit it again, but the file system knew it as "ABCDE." So when you compiled the program, the compiler produced ABCDE.o, which overwrote the source code!

11 years, 1 month

1
0
0 0

Re: [TUHS] Work I've done with a PDP-11 simulator

by jnc＠mercury.lcs.mit.edu

> To boot up the root pack (I don't think I did this at any point; I've > always mounted it as a subsidiary drive) > ... > The disk has a working RL bootstrap in block 0, it should boot OK. So I recently had to reboot my machine, and I took the opportunity to try this; it worked right off, booted 'unix' OK. (I didn't try any of the other Unixes in the root directory.) I had only that pack mounted on DL0, nothing else. > So, just for grins, because I was curious (after your question), I did > try recompiling the C compiler, to see what I'd get. > What I got were three files (c0, c1 and c2) which were _the exact same > size_ (down to the byte) as the binaries on the V6 Research distro, but > had a number of differences when compared with 'cmp -l'. Odd! > ... > I'll take a gander tomorrow and try and work it out. So, this turned out to be because I had replaced the csv.o in libc.a with a new one, because the standard V6 one doesn't work with long returns (which use R1 as well as R0, and the V6 cret bashed R1). I put the old csv.o back, and re-linked them, and this time c? all turned out identical. So the source in the distro really is the source for the running compiler on it. What was wierd was that in the new one, the routine csv is one word shorter (and so is csv.o). So now I don't understand what made them the same sizes!? The new ones should have been one word shorter!? Still poking into this... I understand most of the differences between the versions of c? with the old and new csv.o; in all the jumps to cret, the indirect word in the instruction was off by two (because cret was one word lower because csv was one word shorter); that, along with different contents in csv.o, created most of the differences. Why one word shorter? Because in csv: tst -(sp) / creates a temporary on top of the stack jmp (r0) had been replaced with: jsr pc,(r0) (saving one instruction, and making it one word smaller). Noel

11 years, 1 month

1
0
0 0

Re: [TUHS] Work I've done with a PDP-11 simulator

by Norman Wilson

The web page mentions files-11 which is ODS-1. Technically (it is all coming back to me now): FILES-11 is a family of file systems that started in RSX-11 (or perhaps before but that's the oldest instance I know). ODS-1 is really FILES-11 ODS-1; ODS is `on-disk [something].' RSX-11 used ODS-1. VMS used ODS-2. I'm not sure of all the differences offhand, but they were substantial enough that we ended up writing two different programs to fetch files to UNIX from RSX and VMS volumes (we had the latter to deal with too). Certainly the directory entries were different between the two: ODS-1 used RADIX-50-encoded file names with at most six characters plus an at-most-three- character `extension' (a term which newbies sometimes improperly import into UNIX as well); I forget the exact filename rules in VMS, but filenames certainly could be longer than six characters. I've found the early-1980s programs I remembered. There were two, getrsx.c and getvms.c; two programs, one for each file-system format. They are surely full of ancient sloppiness that won't compile or won't work right under a modern C compiler, and they make assumptions about byte order. I'll spend some time in the next few days going over them and see if I can quickly get something workable. A footnote as to their origin: in the world where we wrote these programs, we had not only multiple systems, but shared disk drives. The disk drives themselves were dual-ported; the controllers we used could connect to multiple hosts as well. Each system had its own dedicated disk drives, but the UNIX systems could also see the drives belonging to the RSX and VMS systems; hence the file-fetching programs, since this was well before the sort of networking we take for granted these days. On the other hand, we had several UNIX systems which spoke uucp to one another, and that was occasionally used for large file transfers. To speed that up, I taught uucico a new protocol, whereby control information still went over a serial line, but data blocks were transferred over a chunk of raw shared disk (with appropriate locks, of course). It was a simpler world back then, but that made it a lot more fun. Norman Wilson Toronto ON

11 years, 1 month

2
1
0 0

Re: [TUHS] Work I've done with a PDP-11 simulator

by Norman Wilson

This is also an RSX pack (I think), but when I tried to boot it, it said "THIS VOLUME DOES NOT CONTAIN A HARDWARE BOOTABLE SYSTEM", and since I don't know how to mount disks under RSX-11 I left it at that. There exists somewhere a UNIX program that reads an ODS-1 file-system image and produces directory listings and extracts named files. I know it exists because it was written by a friend (and probably hacked around a little by me) almost 35 years ago, when we both worked in a place that had some UNIX and some RSX-11. That means `somewhere' probably includes some place in my old files. I'll see if I can dig it out, upgrade it to work cleanly with modern C (it's just possible I have an ODS-1 file system image lying around somewher too), and post it either somewhere on the web or just to the list. Norman Wilson Toronto ON

11 years, 1 month

3
2
0 0

Re: [TUHS] Work I've done with a PDP-11 simulator

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)bitmover.com> > have you gotten to a point where you can rebuild the world and install > your newly built stuff? Well, I haven't tried to do that (it's not something that I'm that interested in), but it _should_ be possible, since the 'vanilla' V6 distribution does include the source for pretty much everything (including the C compiler, assembler, loader, etc). (This does not include the stuff from the Shoppa disk, like the new C compiler, where I don't have the source. [The PWB distribution, which includes a C compiler from 1977, is probably pretty close. Looking into the PWB stuff is one of my next projects; we have 17 different versions of that stuff, and I'd like to see what the differences among them are, and maybe create a 'canonical' PWB.] Also, per the 'Improvements' page, I have source for the Standard I/O Library, but I'm using the binary library from the Shoppa disk, which may or may not correspond to that source.) Noel

11 years, 1 month

4
5
0 0

An amusing error message

by jnc＠mercury.lcs.mit.edu

Found in: http://minnie.tuhs.org/cgi-bin/utree.pl?file=1BSD/s6/man.c this minor gem: execl("/bin/ssp", "ssp", 0); execl("/usr/bin/ssp", "ssp", 0); printf("Can't find ssp!\n"); execl("/bin/cat", "cat", 0); printf("or cat - gott in himmel!\n"); exit(1); Not as good as "hodie natus" (Google it if you don't know of it - it's a classic), but mildly amusing. Noel

11 years, 1 month

7
11
0 0

Re: [TUHS] Work I've done with a PDP-11 simulator

by jnc＠mercury.lcs.mit.edu

> From: Gregg Levine <gregg.drwho8(a)gmail.com> > By Shoppa disk do you mean, Shoppe disk The root pack (linked to from my page): http://www.tuhs.org/Archive/PDP-11/Distributions/other/Tim_Shoppa_v6/unix_v… It contains lots of V6 goodies - but not, alas, source for most of them. (E.g. I had to disassemble the RL bootstrap(s) from it.) > I've been trying to figure out how to attach them to the E11 one to > bring the whole thing up. The others are junk (see below). To boot up the root pack (I don't think I did this at any point; I've always mounted it as a subsidiary drive) you'd need to say: mount dl0: unix_v6.rl02 /RL02 and then: boot dl0: The disk has a working RL bootstrap in block 0, it should boot OK. Then you get to take your pick of which unix to boot! There are 7 to chose from: 77 -rwxrwxr-x 1 root 38598 Aug 22 1984 oldunix 77 -rwxrwxr-x 1 root 38504 Jul 19 1984 oldunix.25.7 77 -rwxrwxr-x 1 root 38568 Feb 20 1985 unix 74 -rwxrwxr-x 1 4 36956 Mar 9 1983 unix.jones 69 -rwxrwxr-x 1 root 34408 Aug 16 1983 unix.mlab 76 -rwxrwxr-x 1 4 38316 Sep 3 1982 unix.rxrl 68 -rwxrwxr-x 1 root 33958 Jun 6 1983 unix.tmp and I have no idea how they all differ - or what each one expects to use for a root device and swap device. Looking at 'unix', it gives both rootdev and swapdev as '01000' (which is probably the RL, I'm too lazy to grovel around in bdevsw and make sure). The super block reports 19000 as the size of the file system, and sure enough, swplo is reported as 045070 (19000), and nswap as 02710 (1480). So it's probably set up to run and swap on RL/0. > and any of the set of disks that are in the distributions portion of > the site with his name on them? All of the other disks in the V6 folder with his name on it: http://www.tuhs.org/Archive/PDP-11/Distributions/other/Tim_Shoppa_v6 are junk; here's a brief rundown on each one: copy_num1_user.rl02: user0_backup.rl02: user_backup2.rl02: All very similar to the 'unlabeled' disk (below) - lots of random user files for biology stuff, little if anything of any use/interest. There is a file which isn't listed in the README: unlabeled.rl02: It looks like another /user disk, full of random biology stuff; nothing interesting except a copy of a nice-looking Kermit written in C (by someone at Columbia, IIRC). junk: An RL01 pack (the others are all RL02's); it has a boot block with PDP-11 code in it; I mounted it on a simulator and booted it, and it says it's an RSX-11M V3.2 disk. user01.rl02: This is also an RSX pack (I think), but when I tried to boot it, it said "THIS VOLUME DOES NOT CONTAIN A HARDWARE BOOTABLE SYSTEM", and since I don't know how to mount disks under RSX-11 I left it at that. scratch_disk_1123.rl02: This does indeed seem to be something that was used for disk diagnostics: the boot block contains gubble, including (in the first RL11 block) lots of words with all ones, and a lot of 52525's. Noel

11 years, 1 month

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