TUHS

tuhs@tuhs.org

64 participants
6514 discussions

by Johnny Billquist

On 2014-10-07 03:00, norman(a)oclsc.org (Norman Wilson) wrote: > > The 11/70 service manual is all good, but it's definitely not enough. > Ideally, you should have access to the full drawings, the service manual > for the CPU, the service manual for the memory subsystem, I seem to > remember that the FP11 has its own service manual, and I think the > massbus interface also has its own documentation set. > Also, the memory system consists of both the Unibus map, the cache and > memory bus system, and they you have separate documentation for the > memory boxes (either MJ11 or MK11 box). > > It might be worth while to contact the Living Computer Museum. > I forget whether they have an 11/70 running or just an 11/45, > but I do know that they collect all the documentation they can > get for old computers--I saw the room where they store it. > Whenever they need to use it, or there's some other need to > access it, they try to make time to scan it, so the precious > copy can stay in the archive room. LCM have atleast one 11/70 running. Although they are not really doing anything fun on it. I hope to maybe help them with that next time I'm there. I can't remember seeing any 11/45 running, but I'm pretty sure there are some in their storage if nothing else... I'm not going to try dragging a lot of documentation from Sweden to Seattle, though (I'm not even in Sweden myself lots of the time). On the other hand, I know they have plenty of documentation, so I would hope they (and/or CHM) already have most of it. > Since their goal is to have ancient computers actually > running, they are certainly interested in having all the > documents (even if you can't get the wood, as Warren might > remark at this point), including full engineering drawings. > > It's also a neat place to visit if you have some free time in > Seattle. I'm disappointed to have figured out that, although > I'll be in Seattle for a conference in about a month, I won't > be able to visit LCM while they're open unless I skip some > conference sessions ... or unless I can convince them to open > up specially. Anyone else on this list planning to attend > LISA and interested in visiting a museum of old running > computers? I know of the place, and have known Rich Alderson for a long time. It is a fun place, and I could see myself working there, if I just had the right offer. Don't expect that to happen, though... I'll be there for different reasons in about a month from now. But my weekends are free... :-) Johnny

10 years, 7 months

2.9bsd on 11/45 restoration

by Warren Toomey

Also, I had this e-mail sent to me from Jacob who is a long-time TUHS person. Again, he has questions I don't know the answers to. Anybody? Cheers, Warren ----- Forwarded message from Jacob Ritorto ----- Greetings Warren, Â It's been decades since we last corresponded and I'm delighted to see that you're still active in the pdp11 unix community!Â I've found some free time and have been kicking around the idea of repairing the11/45 I scored some years ago (11/45 system number 273 from Stanford University) and installing 2.9bsd on it.Â You helped me out years ago when I had an 11/34 and I managed to do it back then, so I have some hope this time around too, though there are some more serious hurdles now.Â Glad to see that a lot of the license trolling finally appears to be settled and we can have unfettered access to all the good stuff! Â Â Any pointers to who has parts and troubleshooting knowledge would be a big help. Â Softwarewise, I was also thinking I'd like to get my Fuji160 disks working on the machine.Â Has work like this been done already, or would you have pointers as to how to go about it? Â Â Also, has anyone written a miniature httpd for any of the ancient bsds? thanks jake ----- End forwarded message -----

10 years, 7 months

Re: [TUHS] 2.9bsd on 11/45 restoration

by norman＠oclsc.org

The 11/70 service manual is all good, but it's definitely not enough. Ideally, you should have access to the full drawings, the service manual for the CPU, the service manual for the memory subsystem, I seem to remember that the FP11 has its own service manual, and I think the massbus interface also has its own documentation set. Also, the memory system consists of both the Unibus map, the cache and memory bus system, and they you have separate documentation for the memory boxes (either MJ11 or MK11 box). It might be worth while to contact the Living Computer Museum. I forget whether they have an 11/70 running or just an 11/45, but I do know that they collect all the documentation they can get for old computers--I saw the room where they store it. Whenever they need to use it, or there's some other need to access it, they try to make time to scan it, so the precious copy can stay in the archive room. Since their goal is to have ancient computers actually running, they are certainly interested in having all the documents (even if you can't get the wood, as Warren might remark at this point), including full engineering drawings. It's also a neat place to visit if you have some free time in Seattle. I'm disappointed to have figured out that, although I'll be in Seattle for a conference in about a month, I won't be able to visit LCM while they're open unless I skip some conference sessions ... or unless I can convince them to open up specially. Anyone else on this list planning to attend LISA and interested in visiting a museum of old running computers? Norman Wilson Toronto ON

10 years, 7 months

Re: [TUHS] 2.9bsd on 11/45 restoration

by Johnny Billquist

On 2014-10-05 03:00, Dave Horsfall<dave(a)horsfall.org> wrote: > > On Sat, 4 Oct 2014, Noel Chiappa wrote: > >> >Anyone seriously working on bringing old hardware back to life needs to >> >get in touch with the Classic Computer Talk list: > Is John Dodson on this list? He has an 11/70 in his house. No idea. I occasionally scan cctalk, but most of the time don't bother. Too much noise and irrelevant or ignorant posts. However, unfortunately I don't have any better suggestions where to go if you are trying to restore old hardware and don't have enough knowledge. And yes, I keep lots of different PDP-8, PDP-11 and VAXen running, including 11/70 systems. Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt(a)softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol

10 years, 7 months

Re: [TUHS] 2.9bsd on 11/45 restoration

by random832＠fastmail.us

On Sun, Oct 5, 2014, at 13:47, Jacob Ritorto wrote: > awesome, man, thanks. If I fork tinyhttpd on github, mind if I use 'em? > I'll attribute to you of course If ok, any license preference? I > usually > use MIT.. tinyhttpd itself is not mine and appears to be under the GPL.

10 years, 7 months

Re: [TUHS] 2.9bsd on 11/45 restoration

by random832＠fastmail.us

On Sat, Oct 4, 2014, at 12:37, Jacob Ritorto wrote: > nice. may i see your difffs? > > On Sat, Oct 4, 2014 at 4:06 AM, <random832(a)fastmail.us> wrote: > > > > Seeing this question, I figured "it can't be that hard", and managed to > > get tinyhttpd http://tinyhttpd.sourceforge.net/ to compile on 2.11BSD. > > Mostly just required K&R-ification, though I also had to fix some bugs > > in the way it uses buffers to get it to work at all. Normal GET requests > > work; The whole CGI thing I disabled because I couldn't get it to work > > reliably even on modern linux. > > > > Not actually tested, though - I couldn't get simh to emulate a network > > device. Sure. Security note: the httpd itself doesn't appear to do anything about e.g. ".." in pathnames, and I didn't do anything about that.

10 years, 7 months

RL02 drives available

by jnc＠mercury.lcs.mit.edu

Some guy on eBay has a flock of RL02 drives available (in New York, USA) for a pretty reasonable price: http://www.ebay.com/itm/261288230510 I just bought a flock of them, and they are in very good condition. They were only recently withdrawn from service (at the FAA, so they were professionally maintained up until they went), and were properly prepared for moving (heads immobilized, _and_ the motor was locked down - very rare to see that last step, as is involves finding the right machine screws - or having saved them). They are late-production ones, too (looked, but couldn't find a date) - they have the anti-RFI/EMI 'finger' strips (the kind that make a pressure-loaded contact with the incoming connector shell), which I personally had never seen on any RL0x drives. Alas, they have no packs or terminators available, nor cables or slides (any more :-). But other than that, recommended. Noel

10 years, 7 months

Re: [TUHS] 2.9bsd on 11/45 restoration

by jnc＠mercury.lcs.mit.edu

> From: Warren Toomey <wkt(a)tuhs.org> >> have been kicking around the idea of repairing the11/45 I scored some >> years ago (11/45 system number 273 from Stanford University) >> .. >> Any pointers to who has parts and troubleshooting knowledge would be a >> big help. Anyone seriously working on bringing old hardware back to life needs to get in touch with the Classic Computer Talk list: http://www.classiccmp.org/mailman/listinfo/cctalk A wealth of experience and knowledge on every conceivable topic involved in old hardware is available there, and people are very helpful. Noel

10 years, 7 months

Re: [TUHS] Unisoft V7 68k sources (reviving a Codata machine)

by Steve Simon

> The machine is a Codata 300 Wow. I went to Leeds Poly (as it was then) in the mid 1980s. There where two Codatas in the electronics dept., one in its original plastic case and one 19inch rackmount - built as a IEEE 488 controller; I assume what you have is one of those. The former machine was loaded with Whitesmiths cross compilers and I learnt z80 assembly language on it ☺ It ran V7 indeed, and was a friend of the Interdata/Perkin Elmer 3210, the main electronics teaching machine. If it is this machine then it should have the V7 source from the 3210 (Xelos as it was called) and the source for the drivers for the codata (which we gained by "accident"). I may be able to remember some other snippets - contat me off-list with specific questions. I can give you the names of the lecturers who would know most about it but I guess they are now retired (though they may still be Headingly somwhere). (fondly remembers Leeds). -Steve

10 years, 7 months

made up errno contest, at an early USENIX

by Aharon Robbins

Hi All. This is really gonna stretch the memories. (I may have even asked about it on this list before.) At one of the earlier USENIX conferences that I attended, maybe in Atlanta, there was a contest to make up humorous new errno values. The one that won, which I remember to this day was: EMISTERED: A host is a host from coast to coast, and no-one can talk to host that's close, unless the host that isn't close is busy, hung, or dead. I have quoted this is the gawk doc for many years. I'm wondering if there is a way to find out who was the author of this gem? I'd like to give him/her credit. Thanks, Arnold

10 years, 7 months

Unisoft V7 68k sources (reviving a Codata machine)

by Warren Toomey

I just received a new TUHS subscription request along with an interesting query. Can anybody help Michael with his problem? Cheers, Warren ----- Forwarded message from "Engel, Michael" ----- Dear Warren, Could you please subscribe me to the TUHS mailing list? I haven't worked with old Unix systems for quite some time, but I was appointed as a Senior Lecturer at Leeds Beckett University (UK) two months ago and - to my big surprise - I found an old Unix machine collecting dust in a corner.. The machine is a Codata 300, a Multibus-based system using a licensed clone of the original Sun 100U CPU board and a number of additional Multibus controllers. The machine seems to be complete, including two 8" SMD disks and a Cipher 9-track tape drive, we also seem to have a set of replacement boards and the CPU board manual (including schematics and code snippets explaining how to access the onboard devices - some Codata documentation can also be found on bitkeeper). We haven't tried to power up the machine yet (and, built around 1983, it certainly needs a close examination of the power supply and capacitors). From information on the net, this machine runs a Unisoft port of 7th Edition Unix - similar to the Sun 1 machines and probably a Whitesmiths C compiler (there's a Whitesmiths license badge attached to the case). Definitely a very interesting and probably quite rare machine and we would like to revive it (and, if things go well, create a FPGA reimplementation of the system in the context of a student design project). Now, I would love to know more details about the implementation of 7th Edition Unix on the 68000 and the use of the custom MMU built out of fast SRAM and TTL logic. I do not think that source code to any of the various 68k 7th Edition ports produced by Unisoft is available somewhere - do you know of a possible source? Alternatively, do you think it would be worthwhile asking Unisoft for the source code or do you know if anyone has tried this already? According to the Unisoft history web page (http://www.unisoft.com/history.html) they still seem to know that they were porting Unix 30 years ago... The only remotely related source code I could find in my archives is the A/UX 0.7 source (SVR2, if I'm not mistaken), which probably already required a 68020 with 68851 MMU. Best regards, Michael Engel ----- End forwarded message -----

10 years, 8 months

Re: [TUHS] made up errno contest, at an early USENIX

by norman＠oclsc.org

arnold(a)skeeve.com: Can you grep for EMRED? (Doesn't match ENO). ==== Why not grep for E[A-Z][A-Z]*? Norman Wilson Toronto ON

10 years, 8 months

Re: [TUHS] TMG and B

by jnc＠mercury.lcs.mit.edu

> From: arnold(a)skeeve.com > it was clear at the time that UNIX and what was happening was extremely > special .. Those of you who were there really were part of a "golden > age". I once observed to Jerry Saltzer that when I started at the MIT CS labs, I had been bummed because I had missed what I considered their 'Golden Age' - the work on CTSS and Multics. When I showed up there, I did a deal where they let me use a PDP-11/40 to explore some OS ideas I had, if I woule write diagnostics on it for a ring interface they were working on - part of a project on networking that included work on something called internetworking. I had no idea what I was getting into! And of course the networking work soon sucked me in completely. In that message to Jerry, I said something to the effect of 'clearly I've lived through a second golden age, and only now am I understanding that'. Noel

10 years, 8 months

Re: [TUHS] TMG and B

by Doug McIlroy

TMG was in v2-v6, sometimes in man1 and sometimes in man6. I have an apparently complete source listing. The year is uncertain. (Back then date headings from pr didn't mention the year!) The accompanying manual, though, is dated 1972. There is also, besides the TMGL definition of TMGL, a TMGL definition of pig Latin as a simple test case. None of this is useful, though, without a PDP-11 binary for tmg-- the usual chicken-and-egg problem with a full-blown compiler written in its own language. Doug > >Speaking of TMG, is there an implementation for FreeBSD/Mac/Linux? Or do > > I have to find a CDC/PDP-7 emulator first? :-) > > > >-- Dave > > TMG is mentioned in the v3 manual: > > /sys/tmg/tmgl.o -- the compiler-compiler > > There's no files for it for v5 but it is in v6 and it seems to > disappear after that. > On TUHS V6/usr/source/tmg/tmgl.t would seem to be a source file. > > I did manage to get something running for pdp-7 on simh and got to the > GA prompt. > Didn't get it to do much beyond printing "CAB DECSYS7 COPY 15 JUNE 1966" > > Mark

10 years, 8 months

Re: [TUHS] TMG and B

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy <doug(a)cs.dartmouth.edu> > None of this is useful, though, without a PDP-11 binary for tmg There seems to be be binary for TMG on the V6 distribution. Noel

10 years, 8 months

Fwd: [tz] Time, Clock, and Calendar Programming In C, by Eric S. Raymond

by random832＠fastmail.us

Eric S. Raymond has written an article about the history of the time.h functions at http://www.catb.org/esr/time-programming/ >From his blog post announcing it (http://esr.ibiblio.org/?p=6311) > The C/UNIX library support for time and calendar programming is a nasty mess of historical contingency. I have grown tired of having to re-learn its quirks every time I’ve had to deal with it, so I’m doing something about that. > > Announcing Time, Clock, and Calendar Programming In C, a document which attempts to chart the historical clutter (so you can ignore it once you know why it’s there) and explain the mysteries. > > What I’ve released is an 0.9 beta version. My hope is that it will rapidly attract some thoroughgoing reviews so I can release a 1.0 in a week or so. More than that, I would welcome a subject matter expert as a collaborator. When I saw it I thought it might be generally interesting to people who subscribe to this list.

10 years, 8 months

Re: [TUHS] TMG and B

by jnc＠mercury.lcs.mit.edu

> From: Doug McIlroy <doug(a)cs.dartmouth.edu> > Sorry for straying from direct Unix history Au contraire. This was a fascinating account, and very valuable to have it noted down for history. Please stray like that anytime you feel like it! :-) Noel

10 years, 8 months

TMG and B

by Doug McIlroy

scj wrote: > There was a compiler/compiler in use at the Labs, imported I think by Doug > McIlroy, called TMG. Sorry for straying from direct Unix history, but this remark spurred a lot of memories. TMG (from "transmogrify", defined in Webster as "to change or alter, often with grotesque or humorous effect") was imported from Bob McClure, erstwhile Bell Labs person, then at Texas Instruments. And an interesting import job it was. McClure had written TMG for the CDC 1604 in machine language. He sent me green coding sheets hand-transliterated into 7090 code. Interesting debugging: one knew that the logic of the code was sound, but the opcodes might not always be right. Sometimes, for example, the wrong one of the two accumulator-load instructions, CLA and CAL, was used. Clem Pease converted TMG to the GE 635 for Multics by the artifice of defining 7090 opcodes as 635 macros--sometimes many instructions long to slavishly emulate the 7090's peculiar accumulator (which mixed 38-bit sign-magnitude with 37-bit twos-complement and 36-bit ones-complement arithmetic). It's amusing to speculate about the progressive inflation of TMG had McClure sent me a similar translation for the 7090. TMG had a higher-level language written in TMG, which evolved during the Multics project into something considerably more elaborate than McClure's original, including features like syntax functions, e.g. seplist(a,b) denoted a sequence of a's separated by b's, for arbitary syntactic categories a and b. Syntax functions took TMG beyond the domain of context-free languages. Multics was to be written in PL/I, a compiler for which was commissioned from Digitek. They had brilliant Fortran technology, but flubbed PL/I. When it appeared that the Digitek compiler was hopeless, Bob Morris proposed that we write a quick and dirty one in TMG. Despite being slow (an interpreter running on an emulated 7090) and providing only three diagnostics, this compiler carried the project for a couple of years. When Unix came along, we were again faced with how to bootstrap TMG across machines. This time I wrote a bare-bones interpreter in PDP7 assembler, then by stages grew the language back to the Multics state. Ken, in a compliment I still treasure, once called this the most amazing program on the original Unix machine. I believe TMG was involved in the initial evolution of B, but the real tour-de-force in B was the ability of an interpreted version to exploit software paging and transcend the limited memory of the PDP-11. The following scenario was to be repeated several times in the early days of Unix. When the native version of B ran out of steam, the interpreted version would be used to introduce some new optimization that would squeeze the native version back to fit. (Bigger input, smaller output!) Subsequently we saw the same thing happen with C and the kernel. When the kernel grew too big, a new optimization would be introduced in C to squeeze it. (And to squeeze the compiler, too. The compiler, though, never enjoyed B's advantage of being able temporarily to run in a bigger arena.) Doug

10 years, 8 months

yacc for Unix v5

by Mark Longridge

I've been looking into the history of yacc (yet another compiler compiler). The earliest reference I can find is the man page for yacc from v3 which indicates that yacc was written in B language. The files actn.b and /crp/scj/bigyacc are mentioned. No luck so far in locating those files. There is a man page for v4 which is very brief. There is a yacc executable for v5 but so far I haven't found any v5 era code that works with it. My attempts to compile bc.y from v6 using yacc from v5 were not successful. Also the source code for yacc in v5 is missing. On a happier note I was able to use yacc and cc to regenerate the bc calculator in v6. It needed a fair amount of swap space to compile otherwise an "Intermediate file error" will occur. It seemed to require at least 300 blocks of hard drive space. It's a bit mysterious what the Unix v5 yacc was used on. It predated bc and expr. There's no v5 era *.y files available to look at. Mark

10 years, 8 months

where is ecvt?

by Mark Longridge

I've been comparing Unix v5 libc to modern linux and various other Unix versions and I found something odd. I made a list of functions which occur in Unix v5 libc.a and modern linux glibc.a and while there is no problem using the ecvt function in modern linux it doesn't seem to appear: ar t /usr/lib/libc.a | grep ecvt ...doesn't find ecvt. But if you do: grep ecvt /usr/lib/libc.a then Binary file /usr/lib/libc.a matches So it seems it is in there somewhere. While searching for ecvt.c I found it as part of openbsd. I assume in modern Linux ecvt must be part of a larger function but I couldn't find it in the glibc source. Of course in Unix v5 things were completely straightforward as TUHS has the file V5/usr/source/s3/ecvt.s I just want to find all the functions that are still in modern glibc.a which also existed in Unix v5 libc.a

10 years, 8 months

Re: [TUHS] Teletype

by John Foust

At 01:04 PM 8/15/2014, Brian Zick wrote: >Would it still be possible today for someone like me to go out, and find an old teletype terminal (an old ASR or DECwriter or something), set up a phone line and modem and get a roll of paper, and then actually use it to connect to other computers? Yes, lots of people do it. There is a "Greenkeys" mailing list http://mailman.qth.net/mailman/listinfo/greenkeys populated by mostly ham radio RTTY types, but it's also a great archive of posts about hook-ups and repairs. Yes, there are current-loop adapters and RS-232 to USB adapters that can be used to connect to contemporary machines. There are also streaming audio web sites that send RTTY-style signals if you'd like to emulate your old radio over the Internet but still use your RTTY audio decoding hardware. There's also a fellow http://aetherltd.com/ who connects even older teletype hardware to cell-phone texting. The Teletype Model 33 was very popular among early computer users because it was relatively low-priced compared to heavier-duty teletypes. The old RTTY folks tend to look down their nose at it because it wasn't as robust as other models. They routinely huff and puff at recent auction prices for the Model 33, though, as old computer collectors routinely pay $1,000 for them, while it's tough to give away the better-built (and heavier!) teletypes. Last summer I picked up a Western Union-branded Teletype Model 28 KSR (circa mid-1950s) in near-pristine condition for $50. Almost twenty years ago I found a Model 33 in a university dumpster. - John

10 years, 8 months

Re: [TUHS] another Web site on computer history

by John Foust

At 07:46 PM 9/8/2014, you wrote: >Traffic this evening on the pcc compiler list <pcc.lists.ludd.ltu.se> >alerted me to the existence of the Software Preservation Group, a >branch of the Computer History Museum, with a Web site at > > http://www.softwarepreservation.org/ Also at http://www.computerhistory.org/groups/spg/ . It's run by Al Kossow: http://www.computerhistory.org/staff/Al,Kossow/ He worked at Apple for a long time. His early years were at UW-Milwaukee. He also frequents the Classic Computer Collector mailing list, a place where you might acquire and learn to repair the old iron. - John

10 years, 8 months

UUCP Maps

by Lyndon Nerenberg

The recent UUCP network conversation has me wondering ... is anyone collecting/curating the UUCP maps that represented the way we communicated (outside the ARPANET) from the time of Chesson's paper until the death of comp.mail.maps? Brian Reid's postscript maps were a work of genius; the hand-drawn ASCII maps that predated those are even more wonderful bits of Internet history, let alone art. --lyndon

10 years, 8 months

Re: [TUHS] Etymology of bc

by Doug McIlroy

> Speaking of using a pipe to an existing command, I originally mis-read the > code to think there was only _one_ process involved, and that it was buffering > its output into the pipe before doing the exec() itself - something like this: > > pipe(p); > write_stuff(p[1]); > close(0); > dup(p[0]); > close(p[0]); > close(p[1]); > execl("/bin/other", "other", arg, 0); > > Which is kind of a hack, but... it does avoid using a second process, although > the amount of data that can be passed is limited. (IIRC, a pipe will hold at > most 8 blocks, at least on V6.) Did this hack ever get used in anything? I didn't notice anybody commenting on the fact that this hack doesn't work for the purpose--an interactive desk calculator. Running bc then dc serially defeats interactivity. The scheme of filling a pipe completely before emptying it is used in Rob Pike's plan9 editor, sam, to pipe text through some transforming process. Because the transformer (think sort) may not produce any output until it has read all its input, sam can't read the result back until it has finished stuffing the pipe. Of course sam has to create two pipes, not just one, and it happens that the initial writer and ultimate reader are the same. But the basic idea is the same. Doug

10 years, 8 months

Etymology of dsw(1)

by Dave Horsfall

Speaking of things etymological, I've heard two versions of that for dsw(1). Delete from Switch Register (delete file whose i-num is in CSR) Delete Sh*t Work (same, but expressed a bit more robustly) -- Dave

10 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