I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Seventh Edition:
http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
Hi All:
I looking for the source code to the Maitre'd load balancer. It is
used to run jobs on lightly used machines. It was developed by Brian
Berhard at Berkeley's Computer Systems Support Group. I have the
technical report for it (dated 17-dec-1985). But haven't run across the
tarball.
thanks
-ron
The use of %% to designate a literal % in printf is not
a recent convention. It was defined in K&R, first edition.
Doug
Ralph Cordery wrote:
Though that may seem odd to our modern C-standardised eyes, it's
understandable in that if it isn't a valid %f, etc., format specifier
then it's a literal percent sign.
According to K&R the behavior of % followed by something
unexpected is undefined. So the behavior of Ralph's example
is officially an accident. (It's uncharacteristic of Dennis
to have defined printf so that there was no guaranteed way
to get a literal % into a format.)
Doug
------------------------------------------------
Ralph Corderoy wrote:
$ printf '%s\n' \
.PS 'print sprintf("%.17g %.0f% % %%", 3.14, 42, 99)' .PE |
> pic >/dev/null
3.1400000000000001 42% % %%
Though that may seem odd to our modern C-standardised eyes, it's
understandable in that if it isn't a valid %f, etc., format specifier
then it's a literal percent sign.
The linux kernel never implemented support for a few features of obsolete
terminals. I find myself wanting to use Raspberry Pi-style linux machines
with old hardware, so this became quite frustrating.
So, I've put together a patch to the n_tty line discipline that adds some
things needed for using a Teletype model 33 or similar natively:
- XCASE, escaping uppercase (and a few special characters) for input and
display,
- CRDLY, delay to allow time for the carriage-return function;
- NLDLY, delay to allow time for the newline function.
With XCASE and ICANON, the terminal outputs a backslash before uppercase
characters; and accepts a backslash escape to set input to uppercase. The
usual way to use this is `stty lcase`, which also down-cases all input by
default. The special character escapes are:
\^ to ~
\! to |
\( to {
\) to }
\' to `
With CRDLY there are three options, CR0 through CR2; and with NLDLY there
are options NL0 (no delay) and NL1 (one delay). This patch uses fill
characters for delay, not timing, so these flags only take effect when
OFILL is also set.
Note: this doesn't change `agetty`, which I don't think implements
uppercase login detection right now. I have a Teletype running with
auto-login; and then `stty 110 icanon lcase ofill cr1 nl1`.
Code changes and some brief build instructions are here:
https://github.com/hughpyle/ASR33/tree/master/rpi/kernel
Compare with the raspberrypi tree, here,
https://github.com/raspberrypi/linux/compare/rpi-4.19.y...hughpyle:teletype
Not yet submitted upstream - the changes are in quite a high-traffic code
path, and also I just don't know how :) Feedback is very welcome!
-Hugh
All, I got a new printer with a better duplex scanner. I've just scanned
all the Unix Review magazines that I've got (1984-85 period) and uploaded
them to www.archive.org:
https://archive.org/search.php?query=title%3A%28Unix%20Review%29%20AND%20me…
Merry festive-season-of-your-choice,
Warren
P.S I have a bunch of Unix/World magazines, just waiting for a stronger
guillotine to arrive.
Computer History Museum curator Dag Spicer passed along a question from former CHM curator Alex Bochannek that I thought someone on this list might be able to answer. The paper "The M4 Macro Processor” by Kernighan and Ritchie says:
> The M4 macro processor is an extension of a macro processor called M3 which was written by D. M. Ritchie for the AP-3 minicomputer; M3 was in turn based on a macro processor implemented for [B. W. Kernighan and P. J. Plauger, Software Tools, Addison-Wesley, Inc., 1976].
Alex and Dag would like to learn more about this AP-3 minicomputer — can anyone help?
I sense a hint of confusion in some of the messages
here. To lay that to rest if necessary (and maybe
others are interested in the history anyway):
As I understand it, the Blit was the original terminal,
hardware done by Bart Locanthi (et al?), software by
Rob Pike (et al?). It used an MC68000 CPU. Western
Electric made a small production run of these terminals
for use within AT&T. I don't think it was sold to the
general public.
By the time I arrived at Bell Labs in late 1984, the
Standard Terminal of 1127 was the AT&T 5620, locally
called the Jerq. This was a makeover with hardware
redesigned by a product group to use a Bellmac 32 CPU,
and software heavily reworked by a product group.
This is the terminal that was manufactured for general
sale.
I'm not sure, but I think the Blit's ROM was very basic,
just enough to be some sort of simple glass-tty or
perhaps smartass-terminal* plus an escape sequence to
let you load in new code. The Jerq had a fancier ROM,
which was a somewhat-flaky ANSI-ish terminal by default,
but an escape sequence put it into graphics-window-manager
mode, more or less like what had run a few years earlier
on the Blit.
By then the code used in Research had evolved considerably,
in particular allowing the tty driver to be exported to
the terminal (those familiar with 9term should know what
I mean). In 1127 we used a different escape sequence to
download a standalone program into the terminal and
replace the ROM window manager entirely, so we could run
our newer and (to my taste anyway) appreciably better code.
The downloaded code lived in RAM; you had to reload it
whenever the terminal was power-cycled or lost its connection
or whatnot. (It took a minute or so at 9600bps, rather
longer at 1200. This is not the only reason we jumped at
the chance to upgrade our home-computing scheme to use
9600bps over leased lines, but it was an important one.)
The V8 tape was made in late 1984 (I know that for sure
because I helped make it). It is unlikely to have anything
for the MC68000 Blit, only stuff for the Mac-32 Jerq.
Likewise for the not-really-a-release snapshots from the
9/e and 10/e eras. The 5620 ROM code is very unlikely to
be there anywhere, but the replacement stuff we used should
be somewhere.
Norman Wilson
Toronto ON
> If 5620s were called Jerqs, it was an accident. All the software with that
> name would be for the original, Locanthi-built and -designed 68K machines.
>
> The sequence is thus Jerq, Blit, DMD-5620
Maybe the “Jerq” name had a revival. If the processor switch came with some upheaval it is not hard to see how that revival could have happened.
The Dan Cross tar archive with the source code has two top level directories, one named “blit" with the 68K based source and another one named “jerq" with the Bellmac based source. The tar archive seems to have been made in the summer of 1985, or at least those dates are on the top level directories.
I am of course not disputing that the original name was Jerq. There are many clues in the source supporting that, among which this funny comment in mcc.c:
int jflag, mflag=1; /* Used for jerq. Rob Pike (read comment as you will) */
