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