TUHS

tuhs@tuhs.org

10 participants
6481 discussions

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

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

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

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

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