TUHS

tuhs@tuhs.org

6515 discussions

Re: [TUHS] pdp11 UNIX memory allocation.

by jnc＠mercury.lcs.mit.edu

> From: Clem Cole <clemc(a)ccc.com> > Depends the processor. For the 11/45 class processors, you had a 17th > address bit, which was the I/D choice. For the 11/40 class you shared > the instructions and data space. To be exact, the 23, 24, 34, 35/40 and 60 all had a single shared space. (I have no idea why DEC didn't put it in the 60 - probably helped kill that otherwise intersting machine, with its UCS, early...). The 44, 45/50/55, 70, 73, 83/84, and 93/94 had split. > From: random832(a)fastmail.us > the calling convention for PDP-11 Unix system calls read their > arguments from directly after the trap instruction (which would mean > that the C wrappers for the system calls would have to write their > arguments there, even if assembly programs could have them hardcoded.) Here's the code for a typical 'wrapper' (this is V6, not sure if V7 changed the trap stuff): _lseek: jsr r5,csv mov 4(r5),r0 mov 6(r5),0f mov 8(r5),0f+2 mov 10.(r5),0f+4 sys indir; 9f bec 1f jmp cerror 1: jmp cret .data 9: sys lseek; 0:..; ..; .. Note the switch to data space for storing the arguments (at the 0: label hidden in the line of data), and the 'indirect' system call. > From: Ronald Natalie <ron(a)ronnatalie.com> > Some access at the kernel level can be done with MFPI and MPFD > instructions. Unless you hacked your hardware, in which case it was possible from user mode too... :-) I remember how freaked out we were when we tried to use MFPI to read instruction space, and it didn't work, whereupon we consulted the 11/45 prints, only to discover that DEC had deliberately made it not work! > From: Ronald Natalie <ron(a)ronnatalie.com> > After the changes to the FS, you'd get missing blocks and a few 0-0 > inodes (or ones where the links count was higher than the links). These > while wasteful were not going to cause problems. It might be worth pointing out that due to the way pipes work, if a system crashed with pipes open, even (especially!) with the disk perfectly sync'd, you'll be left with 0-0 inodes. Although as you point out, those were merely crud, not potential sourdes of file-rot. Noel

10 years, 4 months

Re: [TUHS] pdp11 UNIX memory allocation.

by random832＠fastmail.us

Apparently the message I was replying to was off-list, but it seems like a waste to have typed all this out (including answering my own question) and have it not go to the list. On Tue, Jan 6, 2015, at 17:35, random832(a)fastmail.us wrote: > http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/factor.s > wrchar: > mov r0,ch > mov $1,r0 > sys write; ch; 1 > rts r5 > > Though it looks like the C wrappers use the "indirect" system call which > reads a "fake" trap instruction from the data segment. Looking at the > implementation of that, my question is answered: > > http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/sys/trap.c > if (callp == sysent) { /* indirect */ > a = (int *)fuiword((caddr_t)(a)); > pc++; > i = fuword((caddr_t)a); > a++; > if ((i & ~077) != SYS) > i = 077; /* illegal */ > callp = &sysent[i&077]; > fetch = fuword; > } else { > pc += callp->sy_narg - callp->sy_nrarg; > fetch = fuiword; > } > > http://minnie.tuhs.org/TUHS/Archive/PDP-11/Trees/V7/usr/man/man2/indir.2 > The main purpose of indir is to allow a program to > store arguments in system calls and execute them > out of line in the data segment. > This preserves the purity of the text segment. > > Note also the difference between V2 and V5 libc - clearly support for > split I/D machines was added some time in this interval. > http://minnie.tuhs.org/cgi-bin/utree.pl?file=V2/lib/write.s > http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s4/write.s

10 years, 4 months

Re: [TUHS] termcap vs terminfo

by Mary Ann Horton

Quoting Dan Cross <crossd(a)gmail.com>: > On Tue, Jan 6, 2015 at 12:33 PM, Johnny Billquist <bqt(a)update.uu.se> wrote: > >> On 2015-01-06 17:56, Dan Cross wrote: >>> >>> I believe that Mary Ann is referring to repeatedly looking up >>> (presumably different) elements in the entry. Assuming that e.g. `vi` >>> looks up O(n) elements, where $n$ is the number of elements, doing a >>> linear scan for each, you'd end up with quadratic behavior. >>> >> >> Assuming that you'd look up all the elements of the termcap entry at >> startup, and did each one from scratch, yes. > > > Yes. Isn't that exactly what Mary Ann said was happening? :-) Yes > But that would beg the question, why is vi doing a repeated scan of the >> terminal entry at startup, if not to find all the capabilities and store >> this somewhere? And if doing a look for all of them, why not scan the >> string from start to finish and store the information as it is found? At >> which point we move from quadratic to linear time. >> > > I don't think she said it did things intelligently, just that that's how it > did things. :-) > > But now we're getting into the innards of vi, which I never looked at > anyway, and I guess is less relevant in this thread anyway. vi does indeed look up all the various capabilities it will need, once, when it starts up. It uses the documented interface, which is tgetent followed by tgetstr/tgetnum/tgetflag for each capability. tgetent did a linear search. >> The short of it (from what I got out of it) is that the move from termcap >> to terminfo was mostly motivated by attribute name changing away from fixed >> 2 character names. >> >> A secondary motivation would be performance, but I don't really buy that >> one. Since we only moved to terminfo on systems with plenty of memory, >> performance of termcap could easily be on par anyway. >> > > I tend to agree with you and I'll go one further: it seems that frequently > we tend to identify a problem and then go to 11 with the "solution." I can > buy that termcap performance was an issue; I don't know that going directly > to hashed terminfo files was the optimal solution. A dbm file of termcap > data and a hash table in whatever library parsed termcap would go a long > way towards fixing the performance issues. Did termcap have to be > discarded just to add longer names? I kind of tend to doubt it, but I > wasn't there and don't know what the design criteria were, so my > very-much-after-the-fact second guessing is just that. It's been 30+ years, so the memory is a little fuzzy. But as I recall, I did measure the performance and that's how I discovered that the quadratic algorithm was causing a big performance hit on the hardware available at the time (I think I was on a VAX 11/750, this would have been about 1982.) I was making several improvements at the same time. The biggest one was rewriting curses to improve the screen update optimization, so it would use insert/delete line/character on terminals supporting it. Cleaning up the mess termcap had become (the format had become horrible to update, and I was spending a lot of time making updates with all the new terminals coming out) and improving startup time (curses also had to read in a lot of attributes) were part of an overall cleanup. IIRC, there may also have been some restrictions on parameters to string capabilities that needed to be generalized. Hashing could have been done differently, using DBM or some other method. In fact, I'd used DBM to hash /etc/aliases in delivermail years earlier (I have an amusing story about the worlds slowest email I'll tell some other time) but at the time, it seemed best to break with termcap and go with a cleaner format.

10 years, 4 months

Re: [TUHS] termcap vs terminfo (was: I swear! I rtfm'ed)

by Johnny Billquist

On 2015-01-01 17:11, Mary Ann Horton<mah(a)mhorton.net> wrote: > > The move was from termcap to terminfo. Termlib was the library for termcap. Doh! Thanks for the correction. Finger fart. > There were two problems with termcap. One was that the two-character > name space was running out of room, and the codes were becoming less and > less mnemonic. Ah. Yes, that could definitely be a problem. > But the big motivator was performance. Reading in a termcap entry from > /etc/termcap was terribly slow. First you had to scan all the way > through the (ever-growing) termcap file to find the correct entry. Once > you had it, every tgetstr (etc) had to scan from the beginning of the > entry, so starting up a program like vi involved quadratic performance > (time grew as the square of the length of the termcap entry.) The VAX > 11/780 was a 1 MIPS processor (about the same as a 1 MHz Pentium) and > was shared among dozens of timesharing users, and some of the other > machines of the day (750 and 730 Vaxen, PDP-11, etc.) were even slower. > It took forever to start up vi or more or any of the termcap-based > programs people were using a lot. Hum. That seems like it would be more of an implementation issue. Why wouldn't you just cache all the entries for the terminal once and for all? terminfo never came to 16-bit systems anyway, so we're talking about systems with plenty of memory. Caching the terminal information would not be a big memory cost. Thanks for the insight. 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, 4 months

COHERENT sources released under 3-clause BSD license.

by Dan Cross

Bob Swartz, founder of Mark Williams Co, has allowed the sources for COHERENT to be published under a three-clause BSD license. Steve Ness is hosting them. They are available here: http://nesssoftware.com/home/mwc/source.php For reference, for folks who don't know what COHERENT is, it started as a clone of 7th Edition, but grew more modern features over time. Dennis Ritchie's recollections of his interaction with it: https://groups.google.com/forum/#!msg/alt.folklore.computers/_ZaYeY46eb4/5B… And of course the requisite Wikipedia link: http://en.wikipedia.org/wiki/Coherent_(operating_system) - Dan C. PS: I hold a soft spot for COHERENT in my heart. I became interested in Unix in high school, but this was before Linux was really a thing and access to other systems was still hard to come by. I spotted an ad for COHERENT in the back of one of the PC-oriented publications at the time, "Computer Shopper" or some such, and realized that it was *almost* within my reach financially and that I could install it on the computer I already owned. Over the next month or so, I scraped up enough money to buy a copy, did so, and put it on my PC. It was quirky compared to actual Unix distributions, but it was enough to give one a flavor for things. The manual, in particular, did not follow the traditional Unix format, but rather was an alphabetical "lexicon" of commands, system calls and functions and was (I've always thought) particularly well done. Links to the COHERENT lexicon and various other documents: http://www.nesssoftware.com/home/mwc/. I graduated onto other systems rather quickly, but COHERENT served as my introduction to Unix and Unix-like systems. PPS: Bob Swartz is the father of the late Aaron Swartz.

10 years, 4 months

Re: [TUHS] termcap vs terminfo

by Johnny Billquist

On 2015-01-06 17:32, Mary Ann Horton<mah(a)mhorton.net> wrote: > > On 01/06/2015 04:22 AM,arnold(a)skeeve.com wrote: >>> >>Peter Jeremy scripsit: >>>> >>>But you pay for the size of $TERMCAP in every process you run. >> >John Cowan<cowan(a)mercury.ccil.org> wrote: >>> >>A single termcap line doesn't cost that much, less than a KB in most cases. >> >In 1981 terms, this has more weight. On a non-split I/D PDP-11 you only >> >have 32KB to start with. (The discussion a few weeks ago about cutting >> >yacc down to size comes to mind...) >> > >> >On a Vax with 2 Meg of memory, 512 bytes is a whole page, and it might >> >even be paged out, and BSD on the vax didn't have copy-on-write. >> > >> >ISTR that the /etc/termcap file had a comment saying something like >> >"you should move the entries needed at your site to the top of this file." >> >Or am I imagining it?:-) >> > >> >In short - today, sure, no problem - back then, carrying around a large >> >environment made more of a difference. >> > >> >Thanks, >> > >> >Arnold > Even with TERMCAP in the environment, there's still that quadratic > algorithm every time vi starts up. I must be stupid or something. What quadratic algorithm? vi gets the "correct" terminal database entry directly from the environment. Admittedly, getting any variable out of the environment means a linear search of the environment, but that's about it. What am I missing? And once you have that, any operation still means either searching through the terminal definition for the right function, which in itself is also linear, unless you hash that up in your program. But I fail to see where the quadratic behavior comes in. 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, 4 months

Re: [TUHS] COHERENT sources released under 3-clause BSD license.

by Doug McIlroy

A very nice addition to the archives. Thank you. I well remember our disbelief that Mark Williams wrote all its own code, unlike other vendors who had professed the same. As Dennis described, we had fun putting together black-box tests that recognized undocumented quirks (or bugs) in our code. We were duly impressed when the results came back negative. Doug

10 years, 4 months

Happy New Year and an amusing story from the past

by Ronald Natalie

A prosperous New Years to all us old UNIX farts. Years ago the USENIX conference was in Atlanta. It was a stark contrast between us and the Southern Baptists who were in town for their conference as well (punctuated at some goofball Baptist standing up in the middle of one of the restaurants to sing God Bless America or some such). Anyhow, right before the conference someone (I think it was Dennis) made some comment about nobody ever having asked him for a cast of his genitals. A couple of friends decided we needed to issue genital casting kits to certain of the UNIX notables. I went out to an art supply store and bought plaster, paper cups, popsicle sticks to mix with, etc… Gould computers let me use one of their booth machines and a printer to print out the instructions. I purloined some bags from the hotel. It was pointed out that you need vaseline in order for the plaster to not stick to the skin. Great, I head into the hotel gift shop and grab ten tiny jars of vaseline. As I plop these on the counter at the cashier, she looks at me for a minute and then announces… I guess y’all aren’t with the baptists. People took it pretty tongue in cheek when they were presented. All except Redman who flew off the handle.

10 years, 4 months

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, 4 months

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, 5 months

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, 5 months

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, 5 months

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, 5 months

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, 5 months

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, 5 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

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, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS