Somewhat late to the discussion, but GeckOS may be another curious
contender. You can find more information in http://6502.orghttp://www.6502.org/users/andre/index.html
j
--
Scientific Computing Service
Centro Nacional de BiotecnologÃa, CSIC.
c/Darwin, 3. 28049 Madrid
+34 91 585 45 05
+34 659 978 577
I'm also forwarding this message that arrived in my mailbox. Is this
**THE** Ken Thompson?
Joachim
-------- Forwarded Message --------
Subject: Re: [TUHS] The UNIX Command Language (1976)
Date: Sun, 29 Nov 2020 21:47:16 -0800
From: Ken Thompson <kenbob(a)gmail.com>
To: Joachim <j(a)tllds.com>
yes. the unix manual was published before that,
but i dont think it was released that early. it had
a manual page on the shell.
this paper might be the first paper ever released
outside bell labs.
On Sun, Nov 29, 2020 at 7:18 PM Joachim via TUHS <tuhs(a)minnie.tuhs.org
<mailto:tuhs@minnie.tuhs.org>> wrote:
Apologies if this has already been linked here.
"The UNIX Command Languageis the first-ever paper published on the
Unix shell. It was written by Ken Thompson in 1976."
https://github.com/susam/tucl
Joachim
> From: Steve Nickolas
> there's no easy way to do preemptive multitasking without extra
> hardware.
Perhaps you're using some idiosyncratic definition of "preemptive" and
"multitasking", but to me that statement's not accurate.
Let's take the "multitasking" part first: that just means 'two or more
computations can run at the same time, sharing the machine' - and that's not
hard to do, without special hardware, provided there's some way (in the
organization of the software) to save the state of one when the other is
running. Many simple systems do this; e.g. the MOS system that I used on
LSI-11's, BITD.
"Preemptive" is a bit trickier, because things have to be organized so that
one 'task' can be temporarily stopped arbitrarily (i.e. without it explicitly
giving up the processor, which is what e.g.MOS did) to let another run. There
does need to be some asynchronous way of inciting the second 'task' to run,
but interrupts (either clock, or device) do that, and pretty much every
machine has those. MINI-UNIX, for example, has premptive multitasking.
The thing that takes special hardware is _protecting_ one task from a bug in
another - a bug which could trash the first tasks's (or the system's!)
memory. One has to have memory management of some kind to do that.
> From: Dave Horsfall
> I would start with something like Mini-Unix
MINI-UNIX would be a good place to start if one wanted to bring up a system on
a machine without memory management; there's nothing in the kernel which is
PDP-11 dependent that I can think of (unlike V6, which had a fairly heavy
dependency on the PDP-11 memory management hardware - although one could of
course rip that all out, as MINI-UNIX did).
However, one's still looking at a fair amount of work, both to get rid of any
traces of PDP-11isms (e.g. stack growth direction), and translate the
assembler part (startup, and access to non-C operations). Something like FUZIX
might be an easier option.
Noel
I'm trying to find out why compress(1) uses .Z as filename extension.
My theory is that it was inspired by pack(1), which uses the .z extension.
However, I haven't been able to find any info on why pack(1) uses that
extension. Does anyone here know?
Some searching led me to [1] which is a man page for pack from AUSAM.
It's written by Steve Zucker in 1975, so perhaps the extension is z for
Zucker?
Was Zucker's pack(1) the first, though? This message [2] talks about a
Bell version.
Does anyone here have any information about this?
Cheers,
Hans
1. https://minnie.tuhs.org/cgi-bin/utree.pl?file=AUSAM/doc/man/man1/pack.1
2. https://tech-insider.org/unix/research/1984/0319.html
I was making coffee into the cup I've had for decades that talks about
his networking books. I realized I might have something that would
help his wife a bit. I had her email but long since lost it. Anyone
have it?
--lm
Back in mid-January, I posted a note saying:
> TL; DR. I'm trying to find the best possible home for some dead trees. ...
A lot (far too much, IMNSHO!) has happened since then. In any case, I thought folks here might appreciate an update. In brief, Iain Maoileoin offered to pay for shipping a largely unknown amount of technical (mostly computer-related) books to his repurposed missile sile (!) near Inverness, Scotland.
Early this Fall, I packed up 16 cardboard boxes (designated 0-F, of course :-) and the shippers hauled them off. Dunno when they'll arrive, let alone in what condition, but trying to save them from recycling seemed worth the effort. FYI, the total weight was a bit over a ton.
Meanwhile, my spouse and I gave away and/or packed up the rest of our things and drove ourselves and five cats up to Seattle, WA, USA. Somewhere in a shipping container, there is still a cubic foot or so of historical Unix papers from Jim Joyce; when it surfaces, I'll post again about rehoming it.
-r
Well, it's a very rainy day and since COVID is keeping me home I just
fed my 516-TSS notebooks into the scanner. It's about 17MB of stuff.
Not sure what to do with it since I don't have a place to serve it and
since they're scanned images they're too big to post. Here's the list
of documents; email me if you're wanting something in a hurry while the
archive stuff is figured out. Note that the smell of mildew wasn't
preserved in the scanning process.
516-1-516-DOCUMENTATION.pdf
516-3-DDP-516-PRICE-LIST.pdf
516-4-Disk-Layout.pdf
516-5-System-Table-Formats.pdf
516-6-Segment-Format.pdf
516-8-Disk-Hole-Format.pdf
516-7-DMA-Mnemonics.pdf
516-9-Addresses.pdf
516-10-11-12-Ring-Formats.pdf
516-12-Specifications-For-The-Node-Modem-Interface.pdf
516-13-Trac-Character-Strings.pdf
516-14-GMAP-Assembler-for-the-Multi-Programmed-516.pdf
516-15-A-Suggested-Graphic-Display-with-Keyboard-for-Graphic-Terminals.pdf
516-16-516-Assembler-And-Post-Processor-For-Unsegmented-Programs.pdf
516-18-Format-For-Ring-Interrupt.pdf
516-19-Thread-Save-Blocks.pdf
516-20-Card-Reader-Bootstrap-and-Programs.pdf
516-21-Octal-Package.pdf
516-22-A-Repeater-For-The-Node-Modem.pdf
516-23-CLEAR-CORE-CARD.pdf
516-24-SOROBAN-CARD-READER-TEST-PROGRAM.pdf
516-25-IO-Table.pdf
516-26-Disk-DMA-Queue.pdf
516-27-GE-Disc-Files-For-516-Programming.pdf
516-27-Thread-Table.pdf
516-28-IO-Ring_Device-Codes.pdf
516-29-Five-Bit-Character-Codes.pdf
516-30-Text-Editor.pdf
516-31-Relocatable-Segment-Octal-Package.pdf
516-32-ASCII-Character-Mnemonics.pdf
516-34-Display-List-For-Glance.pdf
516-35-Internal-Megacycle-Clock.pdf
516-36-Node-Modem-Interface-For-Computer-Terminals.pdf
516-38-P8SYS.pdf
516-39-Resource-Monitor-Meters.pdf
516-40-SNAP-Time-Sharing-Calculator.pdf
516-41-516-Segment-Assembler.pdf
516-42-Memory-Service-Unit-Format.pdf
516-43-GEBKUP-and-FLOAD.pdf
516-44-FSNAP-Floating-Point-Time-Sharing-Calculator.pdf
516-45-516-316-Assembler-and-Binder.pdf
516-46-CALC-A-Desk-Calculator-Program.pdf
516-47-Remote-Data-Plotting.pdf
516-48-CODING-FOR-GLANCE-G-Graphics.pdf
516-49-516-Segment-Assembler.pdf
516-50-Use-Of-The-516-Segment-Assemblers-Macros-In-Application-Programs.pdf
516-51-FSNAP-Designers-Guide.pdf
516-51-FSNAP-Users-Guide.pdf
516-52-DESK-A-Desk-Calculator.pdf
516-53-FSEOF-Flag-End-Of-File.pdf
516-54-Context-Editing.pdf
516-55-One-Card-Core-Save-Program.pdf
516-56-PRIME-An-Integer-Factoring-Program.pdf
516-57-Format-For-The-516-Node-T-I-U-Spider-Interface.pdf
516-59-Calling-Procedures-For-Math-Routines.pdf
516-59-INITIALIZATION-OF-THE-516-TSS-SYSTEM.pdf
516-60-SORT-SUBR-FOR-SEGMENTED-PROGRAMS.pdf
516-61-516-TSS-SYSTEM-BOLTED-IN-CORE-SUBROUTINES.pdf
516-63-Display-Controller-Glance-G.pdf
516-65-SOME-DIGITAL-FILTER-APPLICATION-PROGRAMS.pdf
516-66-TSS-516-GE-Communication.pdf
516-67-Node-Format-For-PDP-11.pdf
516-68-DFILE-N-A-Program-for-TSS-516.pdf
516-69-GLANCE-G-COMMUNICATION-FORMAT-TSS-516-TO-SCOPE.pdf
516-70-Routines-to-Perform-Character-String-IO-in-a-FSNAP-Program.pdf
516-71-FSNAP-Debugging-Aids.pdf
516-72-Node-Test.pdf
516-73-Node-IO-Software.pdf
516-75-Display-Text-Editor-DTE.pdf
516-76-LOCAL-DATA-PLOTTING.pdf
516-77-GLANCE-PLOTTING-ROUTINES-GPLOT-GLANCE-CHRGEN.pdf
516-77-V2-GLANCE-PLOTTING-ROUTINES-GPLOT-GLANCE-CHRGEN.pdf
516-78-DUMP.pdf
516-79-New-File-Features-in-FSNAP.pdf
516-81-OPTION-CHANGING-IN-GPLOT.pdf
516-86-MODIFICATIONS-TO-201-DATAPHONE-SOFTWARE.pdf
DDP-516-PROGRAMMERS-REFERENCE-CARD.pdf
DDP-516-Instruction-Set-Summary.pdf
Index.pdf
README
> From: "Theodore Y. Ts'o"
> was there anything that had similar functionality which pre-dated Bill
> Joy and termcap in late 70's?
Is your question purely in Unix, or more general?
If the latter, there's the terminal-independent support of video terminals in
ITS; that dates to the mid-1970's (i.e. circa V5 or so). User programs output
device-independent display control codes (I have this memory that they were
called P-Codes, but that could be my memory failing), and the OS translated
them to the appropriate screen-control characters.
One additional hack was that the number of terminal types supported in the OS
was limited; there was however a protocol called SUPDUP which sent (basically)
those device-independent codes over a remote login (originally over NCP) frm
the server machine to the client. The User SUPDUP client supported a lot more
terminal types; so people with odd-ball terminals used to log in, SUPDUP
_back_ to their machine, and away they went.
Noel
Hello All,
I know I have asked this before, but I am curious about any new replies or
insight. How did package management start? Were sites keeping track of
packages installed in a flat file that you could grep (as god intended)
somewhere, or were upgrades and additions simply done without significant
announcement? At what point did someone decide, 'Hey, we need to have a
central way to track additional software"?
I know of DEC's setld and SGI's inst in the latter half of the '80s. What
was the mechanism before that?
-Henry
> On Mon, Nov 23, 2020 at 12:28 PM Erik E. Fair <fair-tuhs(a)netbsd.org> wrote:
> The Honeywell DDP-516 was the computer (running specialized software
> written by Bolt, Bernanek & Newman (BBN)) which was the initial model of
> the ARPANET Interface Message Processors (IMP).
The IMPs had a lot of custom interface hardware; sui generis serial
interlocked host interfaces (so-called 1822), and also the high-speed modem
interfaces. I think there was also a watchdog time, IIRC (this is all from
memory, but the ARPANET papers from JCC cover it all).
Noel
