TUHS

tuhs@tuhs.org

17 participants
6470 discussions

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

by John Foust

I wrote: >There was one for the Terak (an 11/03) in May 1979 but I've never found a copy. I take it back... Mark Riordan has a copy and some docs... http://www.60bits.net/msu/mycomp/terak/termedia.htm - John

4 years, 7 months

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

by jnc＠mercury.lcs.mit.edu

> If you want multiple users on an -11/03, Mini-Unix would be an option; > zit doesn't support the -11/03 'out of the box', but looking at it, it > shouldn't be too hard. (Heinz mentioned that it had been done before.) On thinking about it, I might do the -11/03 port of Mini-Unix for the hack value; it looks like it should be a quick project (a couple of hours, much of which would be getting Mini-Unix set up; I'd use a simulator, my QBUS RK11 emulator is broken at the moment). I think it should mostly just be some fairly straight-forward changes to mch.s; I think all the C code would be fine. (Unless there's an 'PS->integ' or something hiding somewhere.) Also a few odds and ends, like a software console switch register (been there, done that). That would make the full power of Mini-Unix available to people with -11/03's; those are still fairly common, and reasonably cheap. (Unlike -11/05's.) It's a considerably more capable system than LSX: e.g. the tty driver is the full V6 one, and supports an arbitrary number of devices. So my question is: had anyone else already done this (I don't want to waste time replicating already-done work)? Also, would anyone have a use for it if I did it? If so, I'll put it up on a Web page when I'm done. (No, I _don't_ use Guthub, and have zero interest in learning how. I'd rather spend my remaining un-comitted neurons improving my ability to read feudal Japanese.) Noel

4 years, 7 months

Re: [TUHS] reviving a bit of WWB

by norman＠oclsc.org

Doug McIlroy: To put it more strongly. this is not a legal C source file. char *s = NULL; But this is. char *s = 0; Clem Cole: 67)The macro NULL is defined in <stddef.h> (and other headers) as a null pointer constant; see 7.19. ==== $ cat null.c char *s = NULL; $ cat zero.c char *s = 0; $ zero.c is a legal C program. null.c is not. Create files exactly as shown and compile them if you don't believe me. Prepend `#include <stddef.h>' (or <stdlib.h> or <stdio.h>) to null.c and it becomes legal, but I think that's Doug's point: you need an include file. Personally I prefer to use NULL instead of 0 when spelling out a null pointer, because I think it's clearer: if ((buf = malloc(SIZE)) == NULL) error("dammit andrew"); though I am willing to omit it when there's no confusion about = vs ==: if (*p) dammit(*p, "andrew"); But that's just a question of style, and Doug's is fine too. The language does not require the compiler to pre-define NULL or to recognize it as a keyword; you have to include an appropriate standard header file. Norman Wilson Toronto ON (not 0N nor NULLN)

4 years, 7 months

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

by jnc＠mercury.lcs.mit.edu

> From: Paul Riley <pdr0663(a)icloud.com> >> the tty driver: >> >> https://minnie.tuhs.org//cgi-bin/utree.pl?file=LSX/sys/tv.c >> >> only supports a single line. > The second serial port would not be to support another user, but to > communicate with peripherals. Ah. Well, AIX will still have an issue (above). Noel

4 years, 7 months

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

by Henry Bent

You're welcome. Other theoretical alternatives are one of the later 2.9BSD patches, though I have had no success getting those to run on anything, and maybe BRL UNIX from the CSRG DVD? I would appreciate hearing from anyone who has tried to get BRL UNIX running. -Henry On Mon, 21 Sep 2020 at 19:36, Paul Riley <pdr0663(a)icloud.com> wrote: > Thanks Henry, that’s an interesting alternative. > > I’m trying to get a photo of the drive label. > > Paul > > Sent from my iPhone > > On 22 Sep 2020, at 7:28 am, Henry Bent <henry.r.bent(a)gmail.com> wrote: > > > On Fri, 18 Sep 2020 at 23:24, Paul Riley <paul(a)rileyriot.com> wrote: > >> >> Team, >> >> I’ve read thru the FAQ and other sources regarding compatibility of >> Research and other flavours on the PDP-11. I have two physical machines, an >> 11/03 and an 11/23+. I’m choosing which version to use on each machine. >> >> Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix with >> more RAM? >> >> From the FAQ, it says V7 would support 11/23 with kernel recompilation, I >> assume includes 11/23+. I see 2.11BSD would also run on a ‘23 (and + I >> guess) with 1MB or more of RAM, so that would be preferred. I suppose 2.11 >> would be preferable. >> >> I also have found another 11/23+ system from a seller here in China. >> There’s the system, and a VT100, and a hard drive I can’t identify. Here’s >> a photo, does anyone know what it is? I may bid for it... >> >> Paul >> >> *Paul Riley* >> > > Ultrix 3.1 should support the 11/23+, which would give you memory support > up to 4MB as well as support for TCP/IP if you have a DEQNA. I don't think > 2.11BSD will run on anything without split I/D which the 23 does not have. > > Without a closer view of the label I doubt that anyone could give you a > definite identification of that hard drive. > > -Henry > >

4 years, 7 months

Fwd: Choice of Unix for 11/03 and 11/23+ Systems

by Paul Riley

Team, I’ve read thru the FAQ and other sources regarding compatibility of Research and other flavours on the PDP-11. I have two physical machines, an 11/03 and an 11/23+. I’m choosing which version to use on each machine. Is LSX the only option on the 11/03, or could I run V6 or Mini-Unix with more RAM? >From the FAQ, it says V7 would support 11/23 with kernel recompilation, I assume includes 11/23+. I see 2.11BSD would also run on a ‘23 (and + I guess) with 1MB or more of RAM, so that would be preferred. I suppose 2.11 would be preferable. I also have found another 11/23+ system from a seller here in China. There’s the system, and a VT100, and a hard drive I can’t identify. Here’s a photo, does anyone know what it is? I may bid for it... Paul *Paul Riley*

4 years, 7 months

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

by jnc＠mercury.lcs.mit.edu

> From: Paul Riley > Using LSX on the 11/03... Will LSX handle cards with multiple serial > ports? Ah, I just read this carefully; LSX only supports a single user at a time, so there's no use to multiple serial lines? (But see below.) (I thought Heinz' reply message to this referred to Mini-Unix, which does suppport multiple users, but on reading it again I see it does not.) If you want multiple users on an -11/03, Mini-Unix would be an option; it doesn't support the -11/03 'out of the box', but looking at it, it shouldn't be too hard. (Heinz mentioned that it had been done before.) Change all cases of 'mov xx, PS' in mch.s: https://minnie.tuhs.org//cgi-bin/utree.pl?file=Mini-Unix/usr/sys/mxsys/mch.s to 'MTPS xx' (PS access needs a special instructtion in the /03); that might be all you need to do. (Installing a KEV11-A, so you can avoid using the instruction emulation package for EIS instructions would be nice, but apparently isn't required.) If Mini-Unix supports multiple users, it ought to be possible to do the same with LSX. (I'm not sure what the rationale was for making LSX single-user: perhaps the RX was too slow; perhaps there was no need in their use case; etc.) But it would probably be more work than going the Mini-Unix route; e.g. to start with, init only supports a single user: https://minnie.tuhs.org//cgi-bin/utree.pl?file=LSX/src/init.c and the tty driver: https://minnie.tuhs.org//cgi-bin/utree.pl?file=LSX/sys/tv.c only supports a single line. One could cross-port the needed 'stuff' from Mini-Unix, but it'd probably be easier to do the Mini-Unix -11/03 conversion. Noel

4 years, 7 months

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

by jnc＠mercury.lcs.mit.edu

> From: Heinz Lycklama > The DLV-11 supported only one serial port in 1975. Other DEC interface > devices may have been added to the Qbus after the mid 1970's. The DLV11-J: http://gunkies.org/wiki/DLV11-J_asynchronous_serial_line_interface is basically 4 DLV11's rolled into a single dual-width card; that's definitely an option for Mini-Unix (which apparently supports up to 4 simultaneous users). They are program compatible with the DHV11, so the driver should 'just work'. The boards are readily available on eBait; 'glitchworks' (of this parish) sells replacement cables (quite good, I have several). Another option for serial lines on QBUS machines are DZ11 and DH11 versions for QBUS. (The DZ11 is interrupt-per-character on output; the DH11 is DMA on output.) There are two generations of each: the DZV11 (quad-width) and DZQ11 (dual-width), and DHV11 (quad) and DHQ11 (dual). I think they are pretty much program compatible with their UNIBUS brethren, and should be easy to get running. The boards are easy to find on eBait, the breakout panels are somewhat rarer (although there sre some DH ohes up at the moment). Noel

4 years, 7 months

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

by jnc＠mercury.lcs.mit.edu

> They are program compatible with the DHV11 Argh; typo. 'DLV11'. Noel

4 years, 7 months

Re: [TUHS] reviving a bit of WWB

by norman＠oclsc.org

Brantley Coile: The fact that a pointer of zero generates a hardware trap is not defined in the language, whereas a 0 is is defined to be a null pointer. ===== The language doesn't require that dereferencing a null pointer cause a trap, either. There's no way to guarantee that behaviour in all environments unless every pointer dereference must include instructions to check for the null-pointer value, because C can run in environments in which any pointer value might be a valid address. On modern machines it's conventional for the null-pointer value in C, what you get when you assign 0 to a pointer, to be all-zeroes; and for operating systems to arrange that that address is unmapped. But that wasn't always so (on the PDP-7 there was no memory map; on the PDP-11 once memory-mapping was added, address space was too dear to throw away an eighth of it just to block null-pointer dereferencing), and it may still not be (consider a C program on an embedded system running without a memory map). It's good that modern systems usually whap you in the head if you deference a null pointer, but it's not required, and those who rely on it are as foolish as those who used to rely on the accident that the byte at address 0 on early VAX UNIX was a zero. Norman Wilson p&p6 and f(

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