TUHS

tuhs@tuhs.org

28 participants
6556 discussions

by Norman Wilson

Something of a tangent: In my early days with UNIX, one of the systems I helped look after was an 11/45. Normally we booted it from an SMD disk with a third-party RP-compatible contorller, for which we had a boot ROM. Occasionally, however, we wanted to boot it from RK05, usually to run diagnostics, occasionally for some emergency reason (like the root file system being utterly scrambled, or the time we ran that system, with UNIX, on a single RK05 pack, for several days so our secretaries could keep doing their troff work while the people who had broken our air-conditioning system got it fixed--all other systems in our small machine room had to stay shut down). There was no boot ROM for the RK05, but it didn't matter: one just did the following from the front-panel switches: 1. Halt/Enable to Halt 2. System reset (also sends a reset to the UNIBUS) 3. Load address 777404 4. Deposit 5. (watch lights blink for a second or so) 5. Load address 0 6. Halt/Enable to Enable 7. Continue 777404 is the RK11's command register. 5 is a read command. Resetting the system reset the RK11, which cleared all the registers; in particular the word count, bus address, and disk address registers. So when the 5 was deposited (including the bit 01, the GO bit), the RK11 would read from address 0 on the disk to address 0 in physical memory, then increment the word-count register, and keep doing so until the word count was zero after the increment. Or, in higher-level terms, read the first 65536 words of the disk into the first 65536 words of memory. Then starting at address 0 would start executing whatever code was at the beginning of memory (read from the beginning of the disk). Only the first 256 words (512 bytes) of the disk was really needed, of course, but it was harmless, faster, and easier to remember if one just left the word-count at its initial zero, so that is what we did. The boot ROM for the SMD disk had a certain charm as well. It was a quad-high UNIBUS card with a 16x16 array of diodes, representing 16 words of memory. I forget whether one inserted or removed a diode to make a bit one rather than zero. It's too bad people don't get to do this sort of low-level stuff these days; it gives one rather a good feel for what a bootstrap does when one issues the command(s) oneself, or physically programs the boot ROM. Norman Wilson Toronto ON

9 years, 7 months

List(s) of Unix Web Sites?

by Warren Toomey

Hi all, thanks for the wiki suggestions so far. Does anybody have any lists of good Unix websites that I can add in to the wiki at http://wiki.tuhs.org/doku.php?id=publications:websites Also, any suggestions on how to organise the page, as I can see we will end up with hundreds of links! Cheers, Warren

9 years, 7 months

References for Unix Papers/Publications?

by Warren Toomey

Someone off-list today asked about an annotated list of Unix papers which might be good to add to the new wiki. I've just uploaded my own short list of Unix papers, in BibTeX format, on the wiki at: http://wiki.tuhs.org/lib/exe/fetch.php?media=publications:wkt_reflist.bib If you have your own list of references in whatever format, could you upload them into the wiki also? Once you have registered and have write permissions, go to: Media manager -> publications -> Upload. Select your file and upload. The dokuwiki can deal with references in BibTeX format, I just don't know how to do it yet. Once I do, I'll decorate links to papers with a reference. Cheers & thanks, Warren P.S I just uploaded some of the BSTJ papers into http://www.tuhs.org/Archive/Documentation/Papers/BSTJ/

9 years, 7 months

A Wiki for Unix

by Warren Toomey

I decided that, given that we have a few years until the 50th anniversary, that I would set up a wiki for Unix in a similar vein to the Multicians one. So I've made a start at http://wiki.tuhs.org (if/when the A record propagates). I'd love to get some other people to help out, but I'll keep adding stuff and we will see how it goes. Any good anecdotes about Unix are most welcome! If you want to get edit status, register and then e-mail me so I can manually mark you as having edit status. Cheers, Warren

9 years, 7 months

Subject: Re: CTSS user interface

by Doug McIlroy

> > Louis wrote a disk loaded program called RUNCOM that read command > > lines from a file, > Hence, presumably, the .foorc files of Unix and the rc shell. Yes, rc files were named for runcom, but did not adhere to runcom's curious limit of 6 commands. Doug

9 years, 7 months

v8 / v9 / v10

by Tim Newsham

It's been a while since I checked.. have v8, v9 and v10 made it out into the public yet? -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com

9 years, 7 months

Re: [TUHS] CTSS user interface?=

by Greg 'groggy' Lehey

I got this a couple of days ago and thought I had sent it on, but apparently not. Here goes. Greg On Saturday, 26 December 2015 at 11:12:59 -0500, Tom Van Vleck wrote: > Short answer to your question is "depends on what you mean by shell." > Answer for Unix heads is http://multicians.org/shell.html where Louis Pouzin says he made up the name > for Multics. We never called the CTSS command processor a shell. > > When I used CTSS in 1963, command processing was in (wired) code in A-core. > A simple program tokenized input lines, looked up the token in A-core tables, and either ran an > A-core routine or loaded a command file, passing the rest of the arguments as a string array. > To add a command, you had to recompile CTSS. Look at the module COMC in the source. > > This command language is documented in the "candy stripe" CTSS manual. > http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide.pdf > > About 1964 or 65, COMC was changed to not list the disk loaded commands; if the table > lookup failed, COMC looked for a disk file in a system directory, and ran it if it was found. > System maintainers could add a command by copying a file into the directory. > Command files were in core image format, already loaded and linked. Conventional practice > was to make them small and to expand the core image for things like I/O buffers at execution start. > > Some disk-loaded commands were listed in COMC and flagged as "privileged" so that they could > call special supervisor entries to get the supervisor to do things forbidden to regular programs. > the LOGIN command was an example: it could read the password file, forbidden to regular users, > and could patch the A-core table of logged in users. > > Louis wrote a disk loaded program called RUNCOM that read command lines from a file, substituted > arguments into the command, and requested the supervisor to run them, and then return control > to RUNCOM. This is a shell-like function. > > Noel Morris and I wrote an author-maintained unprivileged B-core CTSS program in 1965 called > . SAVED that was also shell-like. It read lines from the terminal, tokenized them, expanded > abbreviations and iterations, and ran sequences of commands, and then resumed itself. It had other > features such as inter-user text messages. It allowed power CTSS users to extend the > system-provided command set with their own set of SAVED files, all treated uniformly. > > Noel and I also added a facility to CTSS that allowed the system to run batch jobs. The user > submitted a RUNCOM file to a queue for later processing, much like Unix CRON. > > Revised command processing, RUNCOM, and . SAVED are documented in the second edition CTSS manual. > http://bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide_Dec69.pdf > > Multics had a program known as the shell, which went through a long series of evolutions. > Users could replace their command shell. A program called the listener read command lines > and fed them to the shell, which tokenized the command lines and found and called individual commands. > The argument-substituting run-from-a-file mode of operation of RUNCOM was done by the exec_com command. > All of these Multics features and design were familiar to Ken and Dennis when they worked on Multics. > > You say you have been looking at the CTSS source. You know you can run a simulated > 7094 running a simulated CTSS, right? http://www.cozx.com/~dpitts/ibm7090.html > > regards, tom -- Sent from my desktop computer. Finger grog(a)FreeBSD.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua

9 years, 7 months

Happy birthday, Jon von Neumann!

by Dave Horsfall

Jon von Neumann was born in 1903; without him, we probably wouldn't have had computers at all (but we could've had a Wintel version, I suppose, wherein everything is controlled by BB). -- Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."

9 years, 7 months

Unix Sixth Edition Boot Loader Analyses

by Will Senn

All, I just finished some compact analyses on the boot loaders that are presented in "Setting up Unix - Sixth Edition" by Thompson and Ritchie. They are in followup to the more detailed analysis of the Tape Bootstrap Loader that I mentioned previously and the entry is posted here: http://decuser.blogspot.com/2015/12/pdp-11-bootstrap-loaders-some-analysis.… What was most interesting about the analyses and programs was how related they were. At the end of the day, once I understood how the first one worked, the other two were pretty simple and required only minor tweaks in the coding to achieve their results. I am moving on now that I have a pretty good idea of how these bits of code work and will be starting to program in Macro-11 for a few weeks to get a handle on things before I return to the deep dive into the source code of v6 that I temporarily put on hold so I could actually make sense of the Assembly bits. I really appreciate everyone's help, tips, suggestions and even critiques. Thanks, Will

9 years, 7 months

Unix on a game boy

by Larry McVoy

I must be the only guy here who browses reddit (or I missed someone else posting this). This dude ported 5th edition to a game boy. I'll admit my non coolness by saying I don't know what a game boy is but I'm guessing it's some video game thingy. http://www.kernelthread.com/publications/gbaunix/

9 years, 7 months

Unix on a game boy

by Norman Wilson

The real question: has anyone connected an RK05 to a Game Boy? Norman Wilson Toronto ON (Know what both of those are, have ever used only one)

9 years, 7 months

Happy birthday, Jon von Neumann!

by Norman Wilson

Dave Horsfall: Jon von Neumann was born in 1903; without him, we probably wouldn't have had computers at all (but we could've had a Wintel version, I suppose, wherein everything is controlled by BB). ==== On this day in Australia, but not yet in North America or Europe. Or, as Warren would probably prefer, it was 2015 in England, but still only 1903 in Australia. Such was the great difference in time twixt these two great nations. Australia, Australia, we love you from the heart, the liver, the kidneys, and the giblets, and every other part! Norman Wilson Toronto ON

9 years, 7 months

v6 RK05 bootloader question

by Will Senn

All, I'm trying to understand the RK bootloader code that is found in "Setting up Unix - Sixth Edition". My question is related to RKBA, RK's bus address buffer. Is the bus address the same as memory address? If so, the code makes sense, if not, I appreciate y'alls help. Here's what I have so far: RK05 01 012700 MOV 177414,R0 ; Move RKDB into R0 02 177414 ; RKDB Address 03 005040 CLR -(R0) ; Decrement R0 and clear the contents of RKDA 04 005040 CLR -(R0) ; Decrement R0 and clear the contents of RKBA 05 010040 MOV R0,-(R0) ; Move the contents of R0(RKBA) into decremented R0(RKWC) 06 012740 MOV 5,-(R0) ; Decrement R0 and move 5 into RKCS 07 000005 ; Read and go 08 105710 WAIT: TSTB (R0) ; Test the lower byte of RKCS 09 002376 BGE WAIT ; When bit 7 becomes 1, the read is done 10 005007 CLR PC ; Set PC 000000, the start of the bytes read RKDB - RK data buffer register This register is a general data register and it only used by the code above to initialize R0 so that subsequent RK addresses can be found by simply decrementing R0. RKDA - RK disk address register This register determines the starting disk address of the read operation and is cleared by the code. RKBA - RK current bus address register This register contains the bus address to or from which data will be transferred. Is this the same as memory address? RKWC - RK word count register Two's complement of the number of words to be transferred. RKCS - RK control status register This is the register that controls the device and provides the device status to the program Lines 1-2 The execution of the boot loader code moves the address of RKDB into R0 to initialize the register so that it can be used to obtain the other RK buffer addresses as they are needed. Line 3 The RKDA buffer is cleared, setting the disk address to 0. Line 4 The RKBA buffer is cleared, setting the bus address to 0. Line 5 The value in R0 is transferred into the RKWC buffer. RKBA or 177410, the value in R0, is a convenient number to use for the read operation because it is big enough to cause the program to read in a block of data. The number is in two's complement and represents -370. This tells the disk controller that 370 words (540 bytes) will be transferred. Lines 6-7 The value 5 is placed into RKCS, this value represents a read operation and go. Lines 8-9 The lower byte of RKCS is tested and when it is greater than or equal to zero (not negative), it loops, waiting until the value is negative, that is until bit 7 becomes 1, which indicates Control Ready (RDY) and done. Line 10 PC is set to 00000 and execution of the bytes read from the disk begins at location 00000.

9 years, 7 months

(no subject)

by Doug McIlroy

9 years, 7 months

(no subject)

by Doug McIlroy

9 years, 7 months

Re: [TUHS] Etymology of shell

by jnc＠mercury.lcs.mit.edu

> From: John Cowan > Rather than starting another process, the Multics shell mapped the > executable program the user requested into its own space .. then jumped > into it. The equivalent of exit() simply jumped back to the shell code. This is from memory, so apply the proverbial grain, but ISTR that the original concept for the Multics shell was just like that for Unix - i.e. each command would be a separte child process. This was given up when Multics processes turned out to be so computationally expensive, and they went to commands being subroutines that were dynamically linked in (very easy with Multics, where dynamic linking was a fundamental system capability) and called from the shell. Noel

9 years, 7 months

Etymology of shell

by Warren Toomey

So what is the etymology of "shell", then? I see that Multics has a shell. Was the CTSS user interface also called a shell? Cheers, Warren -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

9 years, 7 months

Etymology of "shell"?

by Warren Toomey

So what is the etymology of the word "shell"? I see that Multics has a shell. What the user interface in CTSS also called a shell? Cheers, Warren

9 years, 7 months

Mirror of Mike Mahoney's oral history of Unix

by Warren Toomey

All, Doug McIlroy sent me an e-mail about the late Mike Mahoney's project to create an oral history of Unix. His documents are at http://www.princeton.edu/~hos/Mahoney/unixhistory I've taken the liberty to mirror them into the Unix Archive and they are now also at http://minnie.tuhs.org/Archive/Documentation/OralHistory/ Cheers, Warren

9 years, 7 months

Re: [TUHS] etymology of cron

by norman＠oclsc.org

John Cowan: Wikipedia is by nature a *summary of the published literature*. If you want to get some folklore, like what "cron" stands for, into Wikipedia, then publish a folklore article in a journal, book, or similar reputable publication. Random uncontrolled mailing lists simply do not count. ====== That sounds fair enough on the surface. But if you follow the references cited to support the cron acronyms, you find that random unsupported assertions in conference papers do count. That's not a lot better. I'd like to see a published, citable reference for the true origin of `cron'. Even better, better published material for a lot of the charming minutiae of the early days of UNIX. (Anyone feel up to interviewing Doug and Ken and Brian and whoever else is left, and writing it up for publication in ;login:?) But I'd be satisfied if we could somehow stamp out the use of spurious references to support spurious claims. If I had the time and energy I'd look into how to challenge the cron acronyms on those grounds. Any volunteers? Norman Wilson Toronto ON

9 years, 7 months

Re: [TUHS] Does anybody recall how the TU10 bootstrap code actually operates?

by jnc＠mercury.lcs.mit.edu

> From: Will Senn > 000777 HALT That's actually "BR ."; the difference is important, since the CPU (IIRC) doesn't honour DMA requests when it is halted, and DMA needs to be working for the controller to read that first block (a secondary tape bootstrap) into memory. > This seems like gobbledegook to me. :-) > It moves the MTCMA (Magtape Current Memory Address) into R0, then it > moves the MTCMA into the MTBRC (Magtape Byte Record Count) "The address of the MTCMA into", etc. Looking quickly at the programming spec for the TM11 controllers, it wants a negative of the byte count to transfer in this register; the address of the MTCMA just happens to also be a large enough negative number to be usable as the (negative) size of the transfer request. (The first record is probably shorter than that, but that doesn't matter.) Note that this code could probably also have been written: MOV #172524, R0 MOV R0,@R0 and been equally functional. > then it moves 60003 into the MTC (Magtape control register), which > causes a read operation with 800BPI 9 Channel density. I'm too lazy to look at the programming spec for the details, but that sounds right. > Am I misinterpreting the byte codes or is this some idiosyncratic way to > get the Magnetic tape to rewind or something (the TM11 has a control > function to rewind, so it seems unlikely that this is the case No, it's just the shortest possible program to read the first block off the tape. It depends on i) the operator having manually set the tape to the right point (the start of the tape), so that it's the first block that gets read, and ii) the fact that the reset performed by hitting the 'Start' key on the CPU clears the TM11 registers, including the Current Memory Address register, so the block that's read is read into memory location zero. Hence the direction to 'once the tape has stopped moving, re-start the CPU at 0'. Noel

9 years, 7 months

(no subject)

by scj＠yaccman.com

Actually, I could easily see Usenix doing this kind of thing on a regular basis. Add my vote as another ex president...

9 years, 7 months

(no subject)

by scj＠yaccman.com

Actually, I could easily see Usenix doing this kind of thing on a regular basis. Add my vote as another ex president...

9 years, 7 months

Re: [TUHS] Does anybody recall how the TU10 bootstrap code actually operates?

by jnc＠mercury.lcs.mit.edu

> Thank you for responding so carefully. The devil is in the details... > I have been reading the PDP-11/40 handbook, much too much :) I'm not sure that's possible! :-) Yes, yes, I know, the architecture is deader than a doornail for serious use, but I liken it to sailing vessels: nobody uses them for serious cargo haul any more, but they are still much beloved (and for good reasons, IMO). The PDP-11 is an incredibly elegant architecture, perhaps the best ever (IMO), which remains one of the very best examples ever of how to get 30 pounds into the proverbial ten-pount sack - like early UNIX (more below). > this is really elegant code. The guys who thought this up were amazing. Nah, it's just a clever hack (small-scale). What is really, almost un-approachably, brilliant about early UNIX is the amount of functionality they got into such a small machine. It's hard to really appreciate, now, the impact UNIX had when it first appeared on the scene: just as it's impossible for people who didn't themselves actually experience the pre-Internet world to _really_ appreciate what it was like (even turning off all one's computers for a day only approximates it). I think only people who lived with prior 'small computer OS's' could really grasp what a giant leap it was, compared to what came before. I remember first being shown it in circa 1975 or so, and just being utterly blown away: the ability to trivially add arbitrary commands, I/O redirection, invisibly mountable sections of the directory tree - the list just goes on and on. Heck, it was better than all but a few 'big machine' OS's! > Thanks again for your help. Eh, de nada. Noel

9 years, 8 months

Re: [TUHS] etymology of cron

by Norman Wilson

John Cowan: Well, of course there are conferences and there are conferences. The only conference I've ever had a paper published at, Balisage, is as peer-reviewed as any journal. (And it is gold open access and doesn't charge for pages -- the storage costs are absorbed as conference overhead.) ==== Have you actually looked up the cited reference? The trouble is not that it's a conference paper. The trouble is that that the `authority' being cited is just a random assertion, not backed up. It's as if I mentioned your name in a paper about something else, remarked in passing and without any citation of my own that you have a wooden leg, and Wikipedia accepted that as proof of your prosthesis. Norman Wilson Toronto ON (Four limbs and eight eyes, thank you very much)

9 years, 8 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