TUHS

tuhs@tuhs.org

13 participants
6482 discussions

Re: [TUHS] First Unix that could run on a PDP-11 with QBUS

by jnc＠mercury.lcs.mit.edu

> From: Dave Horsfall <dave(a)horsfall.org> > I recall that there were other differences as well, but only minor. In > my paper in AUUGN titled "Unix on the LSI-11/23" it will reveal all > about porting V6 to the thing. I did a google for that, but couldn't find it. Is it available anywhere online? (I'd love to read it.) I seem to recall vaguely that AUUGN stuff were online, but if so, I'm not sure why the search didn't turn it up. > I vaguely remember that the LTC had to be disabled during the boot > process, for example, with an external switch. I think you might be right, which means the simulated 11/23 I tested on wasn't quite right - but keep reading! I remember being worried about this when I started doing the V6 11/23 version a couple of months back, because I remembered the 11/03's didn't have a programmable clock, just a switch. So I was reading through the 11/23 documentation (I had used 11/23s, but on this point my memory had faded), trying to see if they too did not have a programmable clock. As best I can currently make out, the answer is 'yes/no, depending on the exact model'! E.g. the 11/23-PLUS _does_ seem to have a programmable clock (see pg. 610 of the 1982 edition of "microcomputers and memories"), but the base 11/23 _apparently_ does not. Anyway, the simulated 11/23 (on Ersatz11) does have the LTC (I just checked, and 'lks' contains '0177546', so it thinks it has one :-). But this will be easy to code around; if no link clock is found (in main.c), I'd probably set 'lks' to point somewhere harmless (054, say - I'm using 050/052 to hold the pointer to the CSW, and the software CSW if there isn't a hardware one). That way I can limit the changes to be in main.c, I won't have to futz with clock.c too. Noel PS: On at least the 11/40 (and maybe the /45 too), the line clock was an option! It was a single-height card, IIRC.

10 years, 9 months

Re: [TUHS] First Unix that could run on a PDP-11 with QBUS

by jnc＠mercury.lcs.mit.edu

> From: Mark Longridge <cubexyz(a)gmail.com> > I was digging around trying to figure out which Unixes would run on a > PDP-11 with QBUS. It seems that the very early stuff like v5 was > strictly UNIBUS and that the first version of Unix that supported QBUS > was v7m (please correct me if this is wrong). That may or may not be true; let me explain. The 11/23 is almost indistinguishable, in programming terms, from an 11/40. There is only one very minor difference (which UNIX would care about) that I know of - the 11/23 does not have a hardware switch register. Yes, UNIBUS devices can't be plugged into a QBUS, and vice versa, _but_ i) there a programming-compatible QBUS versions of many UNIBUS devices, and ii) there were UNIBUS-QBUS converters which actually allowed a QBUS processor to have UNIBUS peripherals. So I don't know which version of Unix was the first run on an 11/23 - but it could have been almost any. It is quite possible to run V6 on an 11/23, provided you make a very small number of very minor changes, to avoid use of the CSWR. I have done this, and run V6 on a simulated 11/23 (I have a short note explaining what one needs to do, if anyone is interested.) Admittedly, this is not the same as running it on a real 11/23, but I see no resons the latter would not be doable. I had started in on the work needed to get V6 running on a real 11/23, which was the (likely) need to load Unix into the machine over a serial line. WKT has done this for V7: http://www.tuhs.org/Archive/PDP-11/Tools/Tapes/Vtserver/ but it needs a little tweaking for V6; I was about to start in on that. > I have hopes to eventually run a Unix on real hardware As do a lot of us... :-) > It seems like DEC just didn't make a desktop that could run Bell Labs > Unix, e.g. we can't just grab a DEC Pro-350 and stick Unix v7 on it. I'm not sure about that; I'd have to check into the Pro-350. If it has memory mapping, it should not be hard. Also, even if it doesn't have memory mapping, there was a Mini-Unix done for PDP-11's without memory mapping; I can dig up some URLs if you're interested. The feeling is, I gather, very similar. > it would be nice to eventually run a Unix with all the source code at > hand on a real machine. Having done that 'back in the day', I can assure you that it doesn't feel that different from the simulated experience (except that the latter are noticeably faster :-). In fact, even if/when I do have a real 11, I'll probably still mostly use the simulator, for a variety of reasons; e.g. the ability to edit source with a nice modern editor, etc, etc is just too nice to pass up! :-) Noel

10 years, 9 months

First Unix that could run on a PDP-11 with QBUS

by Mark Longridge

Hi folks, I was digging around trying to figure out which Unixes would run on a PDP-11 with QBUS. It seems that the very early stuff like v5 was strictly UNIBUS and that the first version of Unix that supported QBUS was v7m (please correct me if this is wrong). I was thinking that the MicroPDP-11's were all QBUS and that it would be easier to run a Unix on a MicroPDP because they are the most compact. So I figured I would try to obtain a Unix v7m distribution tape image. I see the Jean Huens files on tuhs but I'm not sure what to do with them. I have hopes to eventually run a Unix on real hardware but for now I'm going to stick with simh. It seems like DEC just didn't make a desktop that could run Bell Labs Unix, e.g. we can't just grab a DEC Pro-350 and stick Unix v7 on it. Naturally I'll still have fun checking out Unix v5 on the emulator but it would be nice to eventually run a Unix with all the source code at hand on a real machine. Mark

10 years, 9 months

Re: [TUHS] First Unix that could run on a PDP-11 with QBUS

by norman＠oclsc.org

Many Q-bus devices were indeed programmed exactly as if on a UNIBUS. This isn't surprising: Digital wanted their own operating systems to port easily as well. That won't help make UNIX run on a Pro-350 or Pro-380, though. Those systems had standard single-chip PDP-11 CPUs (F11, like that in the 11/23, for the 350; J11, like that in the 11/73, for the 380), but they didn't have a Q-bus; they used the CTI (`computing terminal interconnect'), a bus used only for the Pro-series systems. DEC's operating systems wouldn't run on the Pro either without special hacks. I think the P/OS, the standard OS shipped with those systems, was a hacked-up RSX-11M. I don't know whether there was ever an RT-11 for the Pro. There were UNIX ports but they weren't just copies of stock V7. I vaguely remember, from my days at Caltech > 30 years ago, helping someone get a locally-hacked-up V7 running on an 11/24, the same as an 11/23 except is has a UNIBUS instead of a Q-bus. I don't think they chose the 11/24 over the 11/23 to make it easier to get UNIX running; probably it had something to do with specific peripherals they wanted to use. It was a long time ago and I didn't keep notebooks back then, so the details may be unrecoverable. Norman Wilson Toronto ON

10 years, 9 months

Re: [TUHS] Excise process from a pipe

by jnc＠mercury.lcs.mit.edu

>> the downstream process is in the middle of a read call (waiting for >> more data to be put in the pipe), and it has already computed a pointer >> to the pipe's inode, and it's looping waiting for that inode to have >> data. > I think it would be necessary to make non-trivial adjustments to the > pipe and file reading/writing code to make this work; either i) some > sort of flag bit to say 'you've been spliced, take appropriate action' > which the pipe code would have to check on being woken up, and then > back out to let the main file reading/writing code take another crack > at it > ... > I'm not sure I want to do the work to make this actually work - it's > not clear if anyone is really that interested? And it's not something > that I'm interested in having for my own use. So I decided that it was silly to put all that work into this, and not get it to work. I did 'cut a corner', by not handling the case where it's the first or last process which is bailing (which requires a file-pipe splice, not a pipe-pipe; the former is more complex); i.e. I was just doing a 'working proof of concept', not a full implementation. I used the 'flag bit on the inode' approach; the pipe-pipe case could be dealt with entirely inside pipe.c/readp(). Here's the added code in readp() (at the loop start): if ((ip->i_flag & ISPLICE) != 0) { closei(ip, 0); ip = rp->f_inode; } It worked first time! In more detail, I had written a 'splicetest' program that simply passed input to its output, looking for a line with a single keyword ("stop"); at that point, it did a splice() call and exited. When I did "cat input | splicetest | cat > output", with appropriate test data in "input", all of the test data (less the "stop" line) appeared in the output file! For the first time (AFAIK) a process succesfully departed a pipeline, which continued to operate! So it is do-able. (If anyone has any interest in the code, let me know.) Noel

10 years, 9 months

Hazards of open source.

by Doug McIlroy

10 years, 9 months

shutdown for pre-v7 unix

by Mark Longridge

Hi folks, I've been typing sync;sync at the shell prompt then hitting ctrl-e to get out of simh to shutdown v5 and v6 unix. So far this has worked fairly well but I was wondering if there might be a better way to do a shutdown on early unix. There's a piece of code for Unix v7 that I came across for doing a shutdown: http://www.maxhost.org/other/shutdown.c I doesn't work on pre-v7 unix, but maybe it could be modified to work? Mark

10 years, 9 months

Re: [TUHS] Excise process from a pipe

by jnc＠mercury.lcs.mit.edu

> the downstream process is in the middle of a read call (waiting for > more data to be put in the pipe), and it has already computed a pointer > to the pipe's inode, and it's looping waiting for that inode to have > data. > So now I have to regroup and figure out how to deal with that. My most > likely approach is to copy the inode data across So I've had a good look at the pipe code, and it turns out that the simple hack won't work, for two reasons. First, the pipe on the _other_ side of the middle process is _also_ probably in the middle of a write call, and so you can't snarf its inode out from underneath it. (This whole problem reminds me of 'musical chairs' - I just want the music to stop so everything will go quiet so I can move things around! :-) Second, if the process that wants to close down and do a splice is either the start or end process, its neighbour is going to go from having a pipe to having a plain file - and the pipe code knows the inode for a pipe has two users, etc. So I think it would be necessary to make non-trivial adjustments to the pipe and file reading/writing code to make this work; either i) some sort of flag bit to say 'you've been spliced, take appropriate action' which the pipe code would have to check on being woken up, and then back out to let the main file reading/writing code take another crack at it, or ii) perhaps some sort of non-local goto to forcefully back out the call to readp()/writep(), back to the start of the read/write sequence. (Simply terminating the read/write call will not work, I think, because that will often, AFAICT, return with 0 bytes transferred, which will look like an EOF, etc; so the I/O will have to be restarted.) I'm not sure I want to do the work to make this actually work - it's not clear if anyone is really that interested? And it's not something that I'm interested in having for my own use. Anyway, none of this is in any way a problem with the fundamental service model - it's purely kernel implementation issues. Noel

10 years, 9 months

Program compiled on unix v6 works on unix v5

by Mark Longridge

Ok, this is cheating a bit but I was wondering if I could possibly compile my unix v6 version of unirubik which has working file IO and run it under unix v5. At first I couldn't figure out how to send a binary from unix v6 to unix v5 but I did some experimenting and found: tp m1r unirubik which would output unirubik to mag tape #1 and tp m1x unirubik which would input unirubik from mag tape #1. I don't know what cc does exactly but I thought "well if it compiles to PDP-11 machine code and it's statically linked it could work". And it actually does work! I still want to try to get unirubik to compile under Unix v5 cc but it's interesting that a program that uses iolib functions can work under unix v5. Mark

10 years, 9 months

Re: [TUHS] shutdown for pre-v7 unix

by jnc＠mercury.lcs.mit.edu

> From: Norman Wilson <norman(a)oclsc.org> > I believe that when sync(2) returned, all unflushed I/O had been queued > to the device driver, but not necessarily finished Yes. I have just looked at update() (the internal version of 'sync') again, and it does three things: writes out super-blocks, any modified inodes, and (finally) any cached disk blocks (in that order). In all three cases, the code calls (either directly or indirectly) bwrite(), the exact operation of which (wait for completion, or merely schedule the operation) on any given buffer depends on the flag bits on that buffer. At least one of the cases (the third), it sets the 'ASYNC' bit on the buffer, i.e. it doesn't wait for the I/O to complete, merely schedules it. For the first two, though, it looks like it probably waits. > so the second sync was just a time-filling no-op. If all the disks were > in view, it probably sufficed just to watch them until all the lights > ... had stopped blinking. Yes. If the system is single-user, and you say 'sync', if you wait a bit for the I/O to complete, any later syncs won't actually do anything. I don't know of any programmatic way to make sure that all the disk I/O has completed (although obviously one could be written); even the 'unmount' call doesn't check to make sure all the I/O is completed (it just calls update()). Watching the lights was as good as anything. > I usually typed sync three or four times myself. I usually just type it once, wait a moment, and then halt the machine. I've never experienced disk corruption from so doing. With modern ginormous disk caches, you might have to wait more than a moment, but we're talking older machines here... Noel

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