TUHS

tuhs@tuhs.org

21 participants
6412 discussions

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by jnc＠mercury.lcs.mit.edu

> I think before I try debugging it directly, I'll try one of the other > Mini-Unix repositories; the one I've been using (from Bob Eager's site) > may have some bit-rot. Well, foo, the one from TUHS has the same symptom: random re-starts. Looks like I'm going to have to actually debug this. I guess the first step is to work out how the re-start is happening; I suspect it's not a trap (I'll check, but I think Mini-Unix catches them all). My best guess is a jump to 0 (somehow); if so, that should be easy to catch. Then the next thing is to try and work out where/how/why that is happening. Following a suggestion of Warner Losh, I think there's a good idea on how to make progress, which is to mount the Mini-unix pack under V6 (running on a simulator); that's rock-solid - and the V6 tool-chain can be used to build Mini-Unix binaries. And here I thought it was going to be easy to convert Mini-unix to run on an -11/03. Well, it still might - if I can get Mini-Unix to run reliably! Noel

4 years, 3 months

Bell Labs January 1968 Organizational Directory

by Diomidis Spinellis

David C. Brock posted on Twitter links to the Bell Labs January 1968 Organizational Directory scans. The Research, Communications Sciences Division is available at https://drive.google.com/file/d/171jywFyIDyyWUMX4jYl3Czblqe5VGX2q/view In it the Computing Science Research Center appears on tab 13, page 15 (PDF page 6). Most of the names are very familiar to members of this list; some are even posting here. Diomidis - https://www.spinellis.gr

4 years, 3 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by jnc＠mercury.lcs.mit.edu

> It is definite, though, that Q22 memory won't work with an LSI-11/2 > (M7270) ... I'll try an LSI-11 (M7264) tomorrow, make sure it's the > same; it and the LSI-11/2 are similar enough that it should, but it'd be > good to confirm it. Yes, it too won't work with Q22 memory (tried it, no go - ODT won't even start). > Then back to trying to work out why Mini-Unix is so fragile for me. I tried some changes in the simulator set-up, to see if that would fix my issue; no luck. It's quite problematic: if I boot Mini-Unix on a clean copy of the RK pack, cd to /usr/sys/dev, cp kl.c to nkl.c, and 'cc -c nlk.c', Mini-Unix reliably restarts (trashing the disk in the process). (If I omit the 'cp', I can 'cc -c kl.c' 3 times, and Mini-Unix restarts on the third.) Something's seriously wrong. I think before I try debugging it directly, I'll try one of the other Mini-Unix repositories; the one I've been using (from Bob Eager's site) may have some bit-rot. > From: Paul Riley <paul(a)rileyriot.com> > I'm checking with Peter Schranz about whether or not his RLV12/RL02 > boards can run on the '03. Dave Bridgham and I discussed whether the QSIC would work with an -11/03, and that analysis should apply equally to the RLV12. Our conclusion was that it should; here's our reasoning: The device registers on the board should work fine on either Q18 or Q22. That's because when going to the I/O page, the CPU asserts a special bus line, BBS7 (that says 'this cycle is to the I/O page'). The device doesn't look at the higher address lines when that's on, just BDAL00-12; so if the LSI-11 is messing with some of BDAL181-21, it shouldn't matter. For DMA cycles from the device to memory, since the CPU requires Q18 memory to work, the device too should be able to read/write to Q18 memory. At least, that's our theory. I guess all this PDP-11 hardware detail isn't really on-topic for this list; I should move it to Classic Computers, or something. Sorry all; it's intermingled with early Unix stuff, and it was easier to keep it all in one place. Noel

4 years, 3 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by jnc＠mercury.lcs.mit.edu

> From: Paul Riley > Can you clarify something for me regarding memory? I understand the > bottom area of memory in a Unix system is for the Kernel and it's stuff, > and that the top 8kB is set aside for device I/O Well, technically, the top 8KB of _address space_, not of memory - it's mostly used for device registers, etc. Here: http://gunkies.org/wiki/Unix_V6_kernel_memory_layout is a bit more detail on how the memory is laid out. > The LSI-11 board has 4kW of RAM on it, and I have already a 16KW > board. If I want to further expand the RAM, and say I buy another 16kW > board, that makes an arithmetic sum of 32kW for the boards, making 36kW > total. Can the 4kW of on-board RAM be disabled, and only the 32kW on > the boards be used? Yeah, if you look at LSI-11 documentation, there are jumpers that allow configuration of the on-board memory. Depending on the etch revision; for my F revision, jumper W11 (at the top, towards the handle edge, in the middle of that edge; just below the W1/W2 jumper pair) should be out to disable the on-board memory. Or you could configure the two 32KB boards to be at 020000 and 0120000; there will be 72KB of memory total on the QBUS, but the LSI-11 CPU (no memory management) will only be able to 'see' the bottom 56KB. > Is it ok for the installed RA mto overlap the 8kW at the high memory > area? Yeah, what the CPU sees as the I/O page (at 0160000-0177776 in its address space) is actually at 0760000-0777776 on the QBUS (on a Q18 QBUS); the CPU automagically translates the 0160000-0177776 addresses up. On a PDP-11 with memory management, the MMU has to be set up to do that. E.g. in V6, in: https://minnie.tuhs.org//cgi-bin/utree.pl?file=V6/usr/sys/conf/m40.s there is the following code: / initialize io segment mov $IO,(r0)+ mov $77406,(r1)+ / rw 4k to set the I/O page in kernel address space to point to the I/O page on the bus. Noel

4 years, 3 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by jnc＠mercury.lcs.mit.edu

> From: Pete Turnbull > The SRUNL signal that was mentioned isn't likely to cause a problem That was just a guess on my part as to the exact cause. It is definite, though, that Q22 memory won't work with an LSI-11/2 (M7270); I just tried it. I didn't touch any of the other boards; just swapped the LSI-11/2 for a KDF11-A (M8186), everything worked fine; put the LSI-11/2 back, dead again. I'll try an LSI-11 (M7264) tomorrow, make sure it's the same; it and the LSI-11/2 are similar enough that it should, but it'd be good to confirm it. Then back to trying to work out why Mini-Unix is so fragile for me. Has anyone else ever worked with Mini-Unix, and if so, any tips? Noel

4 years, 3 months

SH script formatting

by David Barto

In a brief discussion with a coworker today the question of formatting shell scripts came up. I believed that in the past the preferred format (if there ever were any such thing) was if [ test ] then statements else statements fi I can find nothing specific to back this up. More appropriate for COFF maybe would be a discussion of what format is better if [ test ]; then statements else statements fi or the above. No intention to start any kind of flame war about which is better, just want to see if there is any historical option for one over the other. David

4 years, 3 months

SH script formatting

by Norman Wilson

if test; then stuff and if test then stuff are functionally equivalent. I wouldn't say one or the other `is preferred.' I use the former because I think it's a little more readable because more compact. But it's really a matter of style, like whether you write if (test) { (multi-statement block) or if (test) { (multi-statement block) I have a stronger opinion about those who use overly- cryptic constructions like test && { shell commands } because it means exactly the same thing as if test; then shell commands but is more obscure to read. But again it's a question of style, not of dogma. As an aside, I think one excuse that is sometimes used for that sort of construct is when it's test || { commands } because Bourne's original shell had no not operator. For a long time after shell functions appeared, I would add this function to any of my shell scripts that needed it: not() { if "$@"; then return 1 else return 0 } so I could say if not test; then commands fi Modern Bourne-shell descendants have a built-in ! operator: if ! test; then commands fi I'm not keen on most of what has been stuffed into bash and ksh and the like, but ! is a real improvement. I believe POSIX mandates it, and I think they're right. Norman Wilson Toronto ON

4 years, 3 months

Unix History with Brian Kernighan

by Angus Robinson

https://www.youtube.com/watch?v=O9upVbGSBFo Kind Regards, Angus Robinson

4 years, 3 months

Re: [TUHS] Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by jnc＠mercury.lcs.mit.edu

> From: Paul Riley > I also have a DEC 256KB board, but I doubt I could use it on the > '03. Yes, DEC 256KB boards are what's called Q22, and those don't seem to work with LSI-11's; not even CPU ODT works. I just tried a 256KB MSV11-L with an LSI-11, and it definitely doesn't work; the MSV11-P is definitely a Q22 board, and so probably also won't work. What the Q22 means is that early in the lifetime of the QBUS, it only had 18 address line - so-called Q18. (Technially the LII-11 used only 16 address lines, so it's actually Q16.) DEC latter snarfed some of the 'unused' pins, and made them QDAL18-21. So boards that use those pins for QDAL18-21 are 'Q22' boards. My theory on what the problem is is that the LSI-11 uses some of those pins for other things - I think the 'run' light, IIRC. So that confuses Q22 memory. If one tries to use one with an LSI-11, the machine is totally dead - not even ODT. It doesn't do any harm, though; unplug the Q22 memory, and plug in a Q18 card like an MSV11-D, and it'll be fine. If you need memory for the LSI-11, MSV11-D boards are pretty common on eBait, for not much. They tend to be flaky, though; sometimes they come back to life if you leave them sit for a bit after you plug them in. > I believe the [memory] board is non-DEC. Well, if it's Q22 it won't work either. Both that and the DEC board should work in the /23, though. (If you have the part number on the memory chips, a little arithmetic should give you the board size. 256K and up are generallly Q22; if you have a manual for that card it might say.) I'm still working with Mini-Unix; it's very fragile. When I got it running, the first thing I tried to do was changle the line editing characters (since my normal ones are burned into ROM). Alas, in stock V6, DEL is hard-wired to be 'interrupt process', so I can't just 'stty [mumble]', I have to rebuild the kernel to change that. Not a problem, necessarily - but I edited tty.h and said 'cc -c tty.c', and it crashed and re-started - and roached the disk. So I'm still trying to make progress. I might have mis-configured the simulator, I'll see. Noel

4 years, 3 months

Re: [TUHS] reviving a bit of WWB

by Doug McIlroy

> Turing save us from 1-complement machines! Users of Whirlwind II were warned about the quirks of -0. We were not warned, though, about integer divide with remainder 0. The result of dividing 6 by 3, for example, was binary 1.111111... - a valid answer when carried to infinity. Unfortunately, the "fractional" part was dropped. Most people used Whirlwind for floating-point computation, and blithely dismissed printed answers like 1.999999 as "roundoff errors". Doug

4 years, 3 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