An ARPAnet pioneer, apparently he was born on this day in 1934, and was
famous for sending the first message over the ARPAnet in October 1969 (it
got as far as "LO" before crashing).
-- Dave
> Here's a Gootoob video (11m): it's a mechanical marvel!
A wonderful model, but quite unlike a TTY 37, where sender
and receiver are the same machine.
Doug
> I think RS took it and left it behind someone's car at one as a practical joke.
That behemoth was built to last. It would surely stop a car.
Moving it single-handed would be quite a feat. When Andy Hall
retired his, he was able to push it as far as his back porch,
where it remained for more than a year.
Under the keyboard was remarkable mechanical crossbar
encoder that dripped machine oil. Fortunately the operator's
knees were protected by a drip pan. The oil smell led me
to keep mine in my workshop; its fragrance reminded
me of the first major piece of computing equipment I saw
as a child: Vennevar Bush's mechanical differential
analyzer, a room-size table of shafts, gears and integrators
that was redolent of machine shop.
Doug
Hopkins had a KSR37 that was our standard word processing output for a long time before the daisy wheel printers started showing up.
It even had the "greek box" so when eqn or whatever wanted that, it just sent shift-in/shift-out (control-n, -o). Years later I managed to pick up a surplus ASR37 from Rocky Flats. I had it in my kitchen for years on a modem. It was great fun to have one of the few terminals that nroff would send all those ESC-8/9 things for the vertical positioning without needing an output filter. No greek box, though. It also had a giant NEWLINE key and didn't need to have the nl mode turned on. Amusingly the thing would sit there quiet until the modem was powered up and then DSR ready would bring it to life. When CD came up an giant green PROCEED light illuminated above the keyboard. The paper tape unit was a monster side car. I never got around to programming the "here-is" drum.
I think RS took it and left it behind someone's car at one as a practical joke.
ANTS was written by Gary Grossman and the experience with ANTS and ANTS 2 was the direct inspiration for NCP Unix (which was probably what Mike installed):
http://chiselapp.com/user/pnr/repository/TUHS_wiki/wiki?name=ncpunix
The source for NCP Unix is available on the Unix Tree webpage:
https://minnie.tuhs.org//cgi-bin/utree.pl?file=SRI-NOSC
> Date: Sun, 3 Jun 2018 13:42:00 -0400
> From: "Ron Natalie" <ron(a)ronnatalie.com>
>
> While Mike and I still shared an office in 394, the ENIAC room was where the IMP 29 on the ARPANET was and a PDP-11/40 system that ran a terminal server called ANTS (ArpaNet Terminal Server) complete with little ants silkscreened on the rack tops. When the ARPANET went to long leaders, Mike replaced that software with a UNIX host giving the BRL their real first HOST on the Arpanet. Years later I recycled those racks (discarding the 11/40) to hold BRL Gateways (retaining the ants).
(Yeah, I was asked to not use "RIP", so...)
We lost J. Presper Eckert back in 1995; he was a co-inventor of ENIAC (one
of the world's first "electronic brains").
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Clem Cole:
WE212 modems worked on dz11 for input but just barely and could not use
a WE dialer for output (who's number I now forget). Remember the AT
command dialer stuff was not originally a standard from the telcos.
The modems were independent of the dialer (which used the RS-4xx
standard and I also have some where and I forget the number).
=====
There was certainly some WECo modems-in-a-rack-with-one-dialer setup
that could be driven by DZ11s. I know that because that is what the
UUCP node `research' used in the 1980s, when I was at Bell Labs.
I don't know what the modem hardware was; maybe it was newer than
what Clem describes, or maybe someone (likely Bill Marshall or Joe
Condon) made some special hardware to make it work. But the UNIX
side of things was a VAX-11/750 running Research UNIX with a DZ11;
I'm quite sure of that.
I'm also sure that the modems were genuine WECo and spoke the 212
protocol, max speed 1200bps.
Aside: when I arrived at the Labs, the standard in the Computing
Science Center was that everyone got a Jerq terminal (AT&T 5620,
commercial descendant of the Blit) at work and at home. For the
home end everyone got a modem with attached telephone (that's the
way the official Bell stuff came back then) and a second phone
line paid for by the Labs. There was a pool of modems dedicated
to dialin for people working from home.
A few months later, it was discovered that a Japanese modem
manufacturer (Fujitsu? I forget) had a 9600bps modem that required
a four-wire leased line but had a reasonable cost, and that New
Jersey Bell had a new offering for leased lines at a reasonable
cost too. So the Labs paid for a pair of the modems and a leased
line for each of us, and we all brought the old 212 modems back
in when convenient, and most of the second phone lines were
cancelled. (A few people wanted to keep them, because they were
business lines from which one could make calls to BTL offices etc
without having to submit your home phone bills for reimbursement.)
The modems had LCD status displays. In the early samples we had
for initial testing, I vaguely remember a few spelling errors in
the status messages; in particular SIGNAL QUARITY IS POOR. The
error had been fixed in the big bulk order.
There was one more step in the evolution of RS-232-to-home: several
years later New Jersey Bell began offering a new service called
Co-LAN to those served by certain central offices (including me).
The customer was given a box with input phone jack, output phone
jack, and a DB25 connector. The latter afforded a serial connection
to the CO, multiplexed with the POTS signal (presumably a forerunner
of what is now called DSL). At the CO, the serial line was plugged
into a Datakit switch. So I would turn on my terminal and get a
Datakit prompt, type a network address referring to a system on
our Datakit network at MH, type a network-access password, and
I was connected the same as if I were at work, at 9600 bps.
New Jersey Bell hoped to sell both the service and Datakit to
other corporations; hence the password, so customers could get
only to the networks for which they were authorized. I don't
know whether that happened much. It was sure convenient for
Bell Labs, though.
Norman Wilson
Toronto ON
On 31.05.18 04:00, Pete Turnbull<pete(a)dunnington.plus.com> wrote:
> On 30/05/2018 23:10, Johnny Billquist wrote:
>> On 30.05.18 02:19, Clem cole wrote:
>>> 1). If you grab ^s/^q from the alphabet it means you can send raw 8
>>> bit data because they are valid characters (yes you can use escape
>>> chars but it gets very bad)
>> But this has nothing to do with 8 bit data.
> [...]
>> What you are talking about is simply the problem when you have inband
>> signalling, and is a totally different problem than 8bit data.
> True, but what I believe Clem meant was "binary data". He did write
> "raw data".
Clem originally said:
"And the other issue was besides not enough buffering DZ11s and the TU58
assumes software (^S/^Q) for the flow control (DH11s with the DM11
option has hardware (RTS/CTS) to control the I/O rate. So this of
course made 8bit data diificult too."
And that is what I objected to. If we're talking about just getting data
through a communications channel cleanly, then obviously inband
signalling like XON/XOFF is a problem, but that was not what Clem claimed.
By the way, while I'm on this topic. The TU58 (aka DECtape II - curse
that name) initially did have overrun problems, and that was because the
protocol did not have proper handshaking. There is flow control when the
TU58 sends data to the host, but there is no handshaking, which
amplifies the problem with flow control on that device. The protocol the
TU58 uses is called RSP, for Radial Serial Protocol. DEC realized the
problem, and modified the protocol, which were then called MRSP, or
Modified Radial Serial Protocol, which addressed the specific problem of
handshaking when sending data to the host.
But in addition to the lack of handshaking, the TU58 is normally always
expected to be connected to a DL11, and the DL11 is the truly stupid,
simple device that only have a 1 character buffer. So that interface can
easily drop characters on reception. Flow control or not. And the TU58
is not really to blame. And if you have an updated TU58 which uses MRSP,
you are better off.
>> RTS/CTS signalling is certainly a part of the standard, but it is not
>> meant for flow control. It is for half duplex and the way to signal when
>> you want to change the direction of communication.
>>
>> It is meant for*half duplex* communication. Not flow control.
> Actually, for both, explicitly in the standard. The standard (which I
> have in front of me, RS232C August 1969 reaffirmed June 1981) does
> indeed explain at length how to use it for half duplex turnaround but
> also indicates how to use it for flow control. It states the use on
> one-way channels and full-duplex channels to stop transmission in a
> paragraph before the paragraph discussing half duplex.
Using RTS/CTS for flow control have eventually made it into the
standard, but this only happened around 1990 with RS-232E-E. See
https://groups.google.com/forum/#!original/comp.dcom.modems/iOZRZkTKc-o/Zcd…
for some background story on that.
And that obviously is way after DEC was making any of these serial
interfaces.
Wikipedia have a pretty decent explanation of how these signals were
defined back in the day:
"The RTS and CTS signals were originally defined for use with
half-duplex (one direction at a time) modems such as the Bell 202. These
modems disable their transmitters when not required and must transmit a
synchronization preamble to the receiver when they are re-enabled. The
DTE asserts RTS to indicate a desire to transmit to the DCE, and in
response the DCE asserts CTS to grant permission, once synchronization
with the DCE at the far end is achieved. Such modems are no longer in
common use. There is no corresponding signal that the DTE could use to
temporarily halt incoming data from the DCE. Thus RS-232's use of the
RTS and CTS signals, per the older versions of the standard, is asymmetric."
See Wikipedia itself if you want to get even more signals explained.
If you have a copy of the 1969 standards document, could you share it? I
was trying to locate a copy now, but failed. I know I've read it in the
past, but have no recollection on where I had it then, or where I got it
from.
>> The AT "standard" was never actually a standard. It's only a defacto
>> standard, but is just something Hayes did, as I'm sure you know.
> Except for ITU-T V.250, which admittedly is a Recommendation not a Standard.
This also becomes a question of who you accept as an authority to
establish standards. One could certainly in one sense say that the Hayes
AT commands were a standard. But all of that also happened long after
DEC made these interfaces, and as such are also pretty irrelevant. The
link to the post in news back in 1990 is from the standards
representative from Hayes, by the way. So they were certainly working
with the standards bodies to establish how to do things.
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
On 2018-05-29 04:00, Clem cole<clemc(a)ccc.com> wrote:
>
> And the other issue was besides not enough buffering DZ11s and the TU58 assumes software (^S/^Q) for the flow control (DH11s with the DM11 option has hardware (RTS/CTS) to control the I/O rate. So this of course made 8bit data diificult too. And as Paul points out, with HW flow the priority could have been lower. But the HW folks assumed a so called 3 wire interface because they thought they were saving money.
Uh? Say what? What does XON/XOFF flow control have to do with 8bit data?
And no, DEC was not trying to save money. They were actually sticking to
the standard. Something very few companies managed to do, especially
when it came to the RS-232 standard.
The "hardware flow control" is actually an abuse of the half duplex
signalling.
And it does not necessarily work as you might expect if modems are in
the middle.
You could get by with just three wires on serial ports, but DEC usually
did want people to have more wires connected, in order to detect when a
device was connected or not. But no, they did not abuse the half duplex
control to do hardware flow control. The DZ11 also have partial modem
control. You cannot run them in half-duplex mode, and they do not
support the secondary channel stuff, but they do support more than just
the 3 wires.
> A few years later when people tried to put high speed modems like the Trailblazers on them, let’s say the Unix folks quickly abandoned any hope. Ken O’Humundro at Able Computer has quite a business in his ‘DHDM’ board that was cheaper than the DZ, more ports, full DMA and of course full hardware flow control.
Yes. It's essentially a DH11 with a partial DM11 on just one board,
while the original DH11/DM11 was a fully 9-slot backplane. So it was a
really good alternative. The DH11 is much better than the DZ11, but did
in fact cost more. The Able board gave the DH11 capabilities at a much
lower cost, and taking much less space in the box. And it actually
performed better than the DH11. But it did not support the full
functionality of the DM11. But what was lacking was the half duplex
stuff, which noone really cared about anymore anyway.
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
On Tue, May 29, 2018 at 9:10 PM, Dave Horsfall <dave(a)horsfall.org> wrote:
> On Wed, 30 May 2018, Johnny Billquist wrote:
>
> Uh? Say what? What does XON/XOFF flow control have to do with 8bit data?
>>
>
> Err, how do you send data that happen to be XON/OFF? By futzing around
> with DLE (which I've never seen used)?
Right - you have to escape things and it is a real mess. I have seen some
of the SI/SO/DLE stuff in mechanical systems like ticker tape. I never saw
a real 8-bit interface try to do it and succeed -- its messy and suspect
when data overruns occurs all hell break loose. By the time of 8 bits and
speed of 9.6K protocol's like UUCP, or IP over serial did not even bother.
I suspect in the old 5-bit baudot code times, it was more popular to get a
larger character set, but the speeds were much slower (and the UART not yet
invented by Gordon Bell).
By the time of the PDP-11, hardware flow was the norm in many (most)
interfaces. I never understood why DEC got ^S/^Q happy. You can really
see the issues with it on my PiDP-8, running DOS/8 because the flow is done
by the OS and its much to late to be able to react. So you get screens
full of data before the ^S is proceeded.
Once Gordon creates the UART, Western Digital licensed it and made it into
a chip which most folks used. DEC started to use the WD chipset in PDP-8
serial interfaces - it always struck me as strange that HW flow was not
used more. The KL11/DL11 supported the wires, although the SW had to do
the work. As I said, MacNamara supported it in the DH11, if I recall (I
don't have the prints in any more), he put an AND gate in the interrupt
bit, so the OS does not get an transfer complete interrupt unless the "I'm
ready" signal is available from the other side.
When I lectured data com to folks years ago, I liked to express the ECMA
serial interface in this manner:
There are 6 signal wires and one reference (signal) ground:
1. Data XMT (output)
2. Data RCV (input)
3. I'm Alive (output)
4. He's Alive (input)
5. I'm Ready (output)
6. He's Ready (input)
Everything else is either extra protocol to solve some other problem, or is
for signal quality (*i.e. *shielding, line balancing etc.). The names of
which signals match to which actual pins on the ECMA interface can be a
little different depending on the manufacturer of the 'Data Communicating
Equipment (DCE - *a.k.a.* the modem) and the Data Terminating Equipment
(DTE - *a.k.a.* the host).
BTW: ECMA and the WE did specify both signal names and the connectors to
use and I think the European Telco's did also (but I only ever saw a German
spec and it was in German which I do not read). DCE's are supposed to be
sockets (female and originally DB25)s and DTE's were suppose to plugs
(male). If you actually follow the spec properly, you never have issues.
The problem was the a number terminal manufactures used the wrong sex
connector, as a lot of them never read the specs [the most famous being the
Lear Siegler ADM3 which was socketed like a DCE but pinned as a DTE -
probably was it was cheap and thus became very popular).
Also to confuse things where it got all weird was how the DCE's handled
answering the phone. And it was because of the answering that we got all
the messy stuff like Ring, Data Set/Terminal Ready/Carrier and the like.
The different DCE manufacturers in different countries had different answer
protocols, than the original Bell system. IIRC the original WE103 needed
help from host. Support for Auto-answer was a later feature of the WE212.
The different protocols are all laid in well in another late 60s/early 70s
data com book from an UMass Prof, who's name I now forget (his book is
white with black letters called 'Data Communications' , as opposed to
MacNamaras dark blue DEC Press book 'Principles of Data Communications').
So ... coming back to Unix for this list... AT&T owned Western Electric
(WE) who was the largest US manufacturer of DCE's [see 1949 law suit/the
consent decree et al]. In fact at Bell Labs, a lot people using UNIX did
not have 'hardwired terminals' - they had a modem connection. So, Unix
as a system and tends to have support for DTE/DCE in the manner WE intended
it to be as a result. It's not surprising that see it in the solutions
that are there.
ᐧ
Back in 1980 or 1981, when I first started hacking
on UNIX but still had some TOPS-10 DNA lingering in
my blood, I put in a really simple control-T
implementation. Control-T became a new signal-
generating character in the tty driver; it sent
signal 16. Unlike interrupt and quit, it did not
flush input or output buffers. Unlike any other
signal, SIG_DFL caused the signal to be silently
ignored. (I don't remember why I didn't just teach
/etc/init and login to set that signal to SIG_IGN
by default; maybe I looked and found too many other
programs that monkeyed with every signal, maybe I
just didn't think of it.)
I then wrote a little program meant to be run in the
background from .profile, that dug around in /dev/kmem,
figured out what was likely nearest-to-foreground process
associated with the same terminal, and printed a little
status info for that process.
It didn't take long for the remaining TOPS-10 DNA to
leach away, and besides it is much easier to run some
program in another window now that that is almost always
possible, so I don't miss it. But I like that idea
better than, in effect, hacking a mini-ps into the kernel,
even though the kernel doesn't have to do as much work
to get the data.
I also thought it made more sense to have a general
mechanism that could be used for other things. That
even happened once. The systems I ran were used, among
other things, for developing SMP, the symbolic-manipulation
interpreter worked on by Stephen Wolfram, Geoffrey Fox,
Chris Cole, and a host of graduate and undergraduate students.
(My memory of who deserves credit differs somewhat from
that of at least one person named.) SMP, by its nature,
sometimes had to spend a substantial time sitting and
computing. Someone (probably Wolfram, says my aging
memory) heard about the control-T stuff, asked me how
to use it, and added code to SMP so that during a long
computation control-T would tell you something about
what it was doing and how it was progressing.
Since the signal was, like interrupt and kill, sent
to the whole process group, there was no conflict if
you also had my little control-T monitor running in
the background.
I never tried to send my hacked-up UNIX to anyone else,
so if anyone else did the same sort of control-T hack,
they likely invented it independently.
Norman Wilson
Toronto ON
> From: Clem Cole
> Tops-20 or TENEX (aka Twin-Ex).
ISTR the nickname we used was 'TWENEX'?
BTW, the first 20 at MIT (MIT-XX) had a 'Dos Equis' label prominently stuck to
it... :-)
Noel
> From: Dave Horsfall
> I have a clear recollection that UNSW's driver (or was it Basser?) did
> not use interrupts .. but used the clock interrupt to empty the silos
> every so often. I'd check the source in the Unix Archive, but I don't
> remember which disk image it's in ... Can anyone confirm or deny this?
I found this one:
https://minnie.tuhs.org//cgi-bin/utree.pl?file=AUSAM/sys/dmr/dz.c
which seems to be the one you're rhinking of, or close to it.
It actually does use interrupts, on both sides - sort of. On the input side,
it uses the 'silo alarm', which interrupts when the input buffer has 16
characters in it. This has the same issue as the silo on the DH11 - if there
are less characters than that waiting, the host never gets an interrupt. Which
may be why it does the timer-based input check also?
The output side is entirely interrupt driven; it _does_ reduce the number of
interrupts by checking _every_ output line (on every DZ11 in the machine) to
see if that line's ready for a character when it gets any output interrupt,
which will definitely seriously reduce the number of output interrupts - but
even then, if _one_ line is going flat out, that's still 1000 interrupts per
second.
Noel
Arthur Krewat:
On 5/29/2018 4:11 PM, Dan Cross wrote:
> "I don't always use computers, but when I do, I prefer PDP-10s."
>
> B B B B - Dan C.
Write-in for President in 2020.
===
Only if he's Not Insane.
Norman Wilson
Toronto ON
Long ago, at Caltech, I ran a VAX which had a mix of DZ11s and
Able DH/DMs. The latter were indeed much more pleasant, both
because of their DMA output and their fuller modem control.
For the DZ11s we used a scheme that originated somewhere in
the USG-UNIX world: output was handled through a KMC11.
Output interrupts were disablled on the DZ; a program
running in the KMC fetched output data with DMA, then
spoon-fed it into the DZ, polling the status register
to see when it was OK to send more, then sending an
interrupt to the host when the entire data block had
been sent.
The KMC, for those fortunate enough not to have programmed
it, has a very simple processor sort of on the level of
microcode. It has a few specialized registers and a
simple instruction set which I don't think had all four
of the usual arithmetic ops. I had to debug the KMC
program so I had to learn about it.
When I moved to Bell Labs a few years later, we didn't
need the KMC to drive serial lines--Dennis's stream I/O
code was able to do that smoothly enough, even with DZ11s
on a VAX-11/750 (and without any assembly-language help
either!). But my experience with the KMC was useful
anyway: we used them as protocol-offload processors for
Datakit, and that code needed occasional debugging and
tweaking too. Bill Marshall had looked after that stuff
in the past, but was happy to have someone else who
wasn't scared of it.
Norman Wilson
Toronto ON
> From: Paul Winalski
> DZ11s ... the controller had no buffer
Huh? The DZ11 did have an input buffer. (See the 'terminals and communications
handbook', 1978-79 edition, page 2-238: "As each character is received ...
the data bits are placed ... in a .. 64-word deep first-in/first-out hardware
buffer, called a 'silo'.")
Or did you mean output:
> if you were doing timesharing it could bring the CPU to its knees in
> short order
The thing that killed an OS was the fact that output was programmed I/O, a
character at a time; using interrupt-driven operation, it took an interrupt
per character. So for a 9600 baud line, 9 bits/character (1 start + 7 data + 1
stop - depending on the line configuration), that's about 1000 characters per
second -> 1000 interrupts per second.
The DH11 used DMA for output, and was much easier on the machine.
Noel
Lars Brinkhoff <lars(a)nocrew.org> reports on Mon, 28 May 2018 10:31:56 +0000:
>> But apparently the inspiration came from VMS:
>> http://web.archive.org/web/20170527120123/http://www.unixtop.org:80/about.s…
That link contains the statement
>> The first version of top was completed in the early part of 1984.
However, on TOPS-20, which was developed several years before VMS, but
still from the same corporation, we had the sysdpy utility which
produced a similar display as top does.
>From my source archives, I find in score/4-utilities/sysdpy.mac the
ending comments:
;462 - DON'T DO A RLJFN AFTER A CLOSF IN NEWDPY
;<4.UTILITIES>SYSDPY.MAC.58, 2-Jun-79 14:15:54, EDIT BY DBELL
;461 - START USING STANDARD TOPS-20 EDIT HISTORY CONVENTIONS, AND
; REMOVE OLD EDIT HISTORY.
...
;COPYRIGHT (C) 1976,1977,1978,1979 BY DIGITAL EQUIPMENT \
CORPORATION, MAYNARD, MASS.
I therefore expect that there was 460-entry list of log messages that
predated 2-Jun-1979, and likely went back a few years. Two other
versions of sysdpy.mac in my archives have also dropped log messages
before 461.
Even before TOPS-20, on the CDC 6400 SCOPE operating system, there was
a similar tool (whose name I no longer recall) that gave a
continuously updated display of system-wide process activity. That was
available in at least late 1973.
I suspect that top-like displays were added to most other interactive
operating systems, as soon as screen terminals made updates convenient
without wasting console paper. One of the first questions likely to
be asked by interactive users is "what is my job doing?".
In a TOPS-20 terminal window, you could type Ctl-T to get a one-line
status report for the job that was currently running from your
terminal. For many users, that was preferable to sysdpy, and it was
heavily used.
-------------------------------------------------------------------------------
- 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/ -
-------------------------------------------------------------------------------
> From: Lars Brinkhoff
> I'm surprised it appeared that late. Were there any other versions or
> similar Unix programs before that?
The MIT ~PWB1 system had a thing called 'dpy', I think written at MIT based on
'ps' (and no doubt inspired by ITS' PEEK), which had similar functionality.
Seems like it never escaped, though. Man page and source here:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/man1/dpy.1http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/dpy.c
The top of my hard-copy man page says 'November 1977', but I suspect it dates
back further than that.
Noel
On this day in 1936, notable mathematician Alan Turing submitted his
thesis "On Computable Numbers", thereby laying the foundations for today's
computers.
Sigh; if only he hadn't eaten that apple... And we'll never know whether
it was murder or suicide.
-- Dave
> I still find pic really useful ... > I don't know of any other tool
that lets you do drawings like that
Unix had "ideal", a remarkable language by Chris Van Wyk, based on complex
numbers and capable of some constraint solving. Its code seemed to be
lost but can now be found in one of the online v10 repositories. I've
been meaning to try to resurrect it. If anyone has already done so,
I'd love to hear about it.
I, too, have some pic macros, though no big coherent packages, to do
things like polar coordinates and solving for the intersection of lines
and circles. I have even in extremis made filled triangles with scripts
that massage PostScript by deleting corners of filled rectangles. Then
from triangles you can, with patience, make polygons.
Doug
A worthy question.
---------- Forwarded message ----------
From: Richard Haight <dickhaight(a)gmail.com>
Date: Thu, May 24, 2018 at 2:53 PM
Subject: unix
To: jpl.jpl(a)gmail.com
Recently I was asked if I still had a spare deck of the Unix-25 cards.
Hadn’t thought of them in years. But it made me realize that 2019 will be
the 50th. Is anyone working on something to mark the anniversary?
Hello,
I'm curious about the history of "top". As far as I can see, the first
version was written by William LeFebvre and posted to net.sources in
1984. I'm surprised it appeared that late. Were there any other
versions or similar Unix programs before that?
Best regards,
Lars Brinkhoff
All, I've just received the following e-mail. I am not able to physically
get these documents, but if you are interested in them, feel free to contact
Mel yourself.
Cheers, Warren
----- Forwarded message from meljmel-unix(a)yahoo.com -----
Date: Wed, 23 May 2018 13:30:09 +1000 (AEST)
From: meljmel-unix(a)yahoo.com
To: Warren T <wkt(a)tuhs.org>
Subject: Old Unix manuals, TMs, etc
Hi,
I started working at Bell Labs in 1971 and although
not in the computing science research department, I
was in another department down the hall. As a result
I have many old Unix manuals, TM's and other papers
that I wish to dispose of. I found you when I did a
search to see if there was anyone who might want them.
Appended below is a list of what I have. If you are
interested in any of it or know who else might be, please
let me know. If I can't find anyone to take them I guess
I'll just throw them out.
Mel
meljmel-unix(a)yahoo.com
==========
These are the old Unix Manuals I have:
UNIX PROGRAMMER'S MANUAL
Program Generic PG-1C300 Issue 2
Published by the UNIX Support Group
January, 1976
UNIX PROGRAMMER'S MANUAL
Program Generic PG-1C300 Issue 3
Published by the UNIX Support Group
March, 1977
UNIX User's Manual
Release 3.0
T.A. Dolotta
S. B. Olsson
A.G. Petrucceli
Editors
June 1980
Laboratory 364
Bell Telephone Laboratories, Incorporated
Murray Hill, NJ 07974
The C Programmer's Handbook
AT&T Bell Laboratories
February 1984
M. I. Bolsky
P. G. Matthews
System Training Center
Copyright 1984
Piscataway, New Jersey 08854
Unix System V Quick Reference Guide
Copyright 1985 AT&T Technologies, Inc
307-130
UNIX TIME-SHARING SYSTEM
PROGRAMMER'S MANUAL
Research Version
Ninth Edition, Volume 1
September, 1986
AT&T Bell Laboratories
Murray Hill, New Jersey
The Vi User's Handbook
by Morris I. Bolsky
Systems Training Center
Copyright 1984 AT&T Bell Laboratories Incorporated
Copyright 1985 AT&T Technologies, Inc
Unix Research System Programmer's Manual
Tenth Edition, Volume I
Computing Science Research Center
Murray Hill, New Jersey
1990, American Telephone and Telegraph Company
Bell Laboratories Division
ISBN 0-03-047532-5
A. G. Hume
M. D. McIlroy
October, 1989
Unix Research System Papers
Tenth Edition, Volume II
Computing Science Research Center
AT&T Bell Laboratories
Murray Hill, New Jersey
1990, American Telephone and Telegraph Company
Bell Laboratories Division
ISBN 0-03-047529-5
A. G. Hume
M. D. McIlroy
January, 1990
----------
These are old Unix Technical Memorandum and Papers I have:
The C Reference Manual
January 15, 1974
TM: 74-1273-1
D. M. Ritchie
Programming in LIL: A Tutorial
June 17, 1974
TM: 74-1352-6
LIL Reference Manual
June 19, 1974
TM: 74-1352-8
A Description of the UNIX File System
September 16, 1975
Author J. F. Maranzano
The Portable C Library
May 16, 1975
TM: 75-1274-11
Author: M. E. Lesk
Lex - A Lexical Analyzer Generator
July 21, 1975
TM: 75-1274-15
Author: M. E. Lesk
Introduction to Scheduling and Switching under UNIX
October 20, 1975
TM: 75-8234-7
Author: T. M. Raleigh
Make - A program for Maintaining Computer Programs
December 5, 1975
TM: 75-1274-26
Author: S. I. Feldman
UNIX Programming
Brian w. Kernighan
Denis M. Ritchie
? 1975 ?
Bell Laboratories, Murray Hill, New Jersey 07974
"This paper is an introduction to programming on Unix.
The emphasis is on how to write programs that interface
to the operating system."
The C Language Calling Sequence
September 26, 1977
TMs: 77-1273-15, 77-1274-13
Authors: A.C. Johnson, D.M. Ritchie, M.E. Lesk
Lint, a C Program Checker
September 16, 1977
TM: 77-1273-14
Author: S. C. Johnson
The M4 Macor Processor
April 1, 1977
TM: 77-1273-6
Authors: Brian W. Kernighan, Dennis M. Ritchie
C Reference Manual
Dennis M. Ritchie
May 1, 1977
Murray Hill, New Jersey 07974
C Language Portability
September 22, 1977
Author: B. A. Tague
Variable Length Argument Lists in C
June 12, 1978
Author: Andrew Koenig
An Introduction to the UNIX Shell
July 21, 1978
TM: 78-1274-4
Author: S.R. Bourne
SED - A Non-Interactive Text Editor
August 15, 1978
TM: 78-1270-1
Author: Lee E. McMahon
UNIX Shell Tutorial
July 14, 1981
TM: 81-59322-5
Author: J. R. Mashey
Awk - A pattern Scanning and Processing Language
Programmer's Manual
June 19, 1985
Authors: Alfred V. Aho, Brian W. Kernighan, Peter J. Weinberger
TMs: 11272-850619-06TM, 11276-850619-09TM, 11273-850619-03TM
Yacc: Yet Another Compiler-Compiler
July 31. 1978
TM: 78-1273-4
Author: Stephen C. Johnson
RATFOR - A Preprocessor for a Rational Fortran
October 22, 1976
TM: 76-1273-10
Author Brian W. Kernighan
Miscellaneous undated (but old) papers:
On the Security of UNIX
Dennis M. Ritchie
A New Input-Output Package
D. M. Ritchie
The Unix I/O System
Dennis M. Ritchie
Programming in C - A tutorial
Brian W. Kernighan
? Date ?
==========
----- End forwarded message -----
WHo'll be the first to run our favourite OS with one of these?
http://obsolescence.wixsite.com/obsolescence/pidp-11-technical-details
``From a hardware perspective, the PiDP is just a frontpanel for a
Raspberry PI. In the hardware section below, the technical details of the
front panel are explained. In fact, the front panel could just as easily
be driven by any microcontroller (or FPGA), it only lights the leds and
scans the switch positions.''
-- Dave
