From sms at moe.2bsd.com Tue Aug 1 01:58:00 2000 From: sms at moe.2bsd.com (Steven M. Schultz) Date: Mon, 31 Jul 2000 08:58:00 -0700 (PDT) Subject: [pups] Overlays? Message-ID: <200007311558.IAA01672@moe.2bsd.com> HI! > From: Jorgen Pehrson > I've just installed 2.11BSD on one of my PDPs, from a TK50 tape I just > re-discovered in the trunk of my car. And now I'm in the process of Wow - those TK50s are quite robust to survive being stored in the truck of a car. I've had audio tapes that did not survive ;) > applying patches. When I installed patch 412 and started to rebuild the > kernel, ld complains with a "ld: too big for type 431". > Does this means that I have to rearrange stuff between the BASE and the > various OV entries? Indeed it does mean exactly that. > How can I find out which overlay is too big? I've tried to do a: > 138% root--> size unix.o Yep - that is the correct method. > text data bss dec hex > 52352 6928 37622 96902 17a86 total text: 115520 > overlays: 7680,7232,7808,7744,4864,8576,4736,6848,7680 > > How big is too big? And also if none of the overlays above are too big, I > guess it must be the BASE that is too big? I thought I wrote this up at one time but I may have only thought about it ;) > Is there some sort of documentation anywhere that describe this voodoo > stuff and black magic a bit? Is it in one an Appendix to the "Setup&Installation" document? In the case above it is OV6 (overlays are numbered from 1) that is too big. The rules are: 1) BASE can be 56kb (57344) max 2) OVerlays can be 8kb (8192) max 3) There can be no 0 length overlays (except for the very last one). > Any suggestions on what .o file I should move to what overlay? Look at the Makefile - you should see a line that starts "OV6=". Do a "size" on the .o files listed for OV6. Pick one that will fix elsewhere - I'd suggest OV5 since it is only 4864 bytes and has lots of room. You could also move a .o file to the BASE since it has adequate room also. Steven Schultz sms at moe.2bsd.com Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id JAA20356 for pups-liszt; Tue, 1 Aug 2000 09:31:49 +1000 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From sms at moe.2bsd.com Tue Aug 1 03:12:43 2000 From: sms at moe.2bsd.com (Steven M. Schultz) Date: Mon, 31 Jul 2000 10:12:43 -0700 (PDT) Subject: [pups] makesimtape.c Message-ID: <200007311712.KAA02116@moe.2bsd.com> Hi! > From: "Ryan Blair" > > While reading back through the mailing list messages, trying to find out why > my tape images never seem to work, I came across a program that I cannot > seem to find. It was mentioned lately as "makesimtape.c" but I cannot find > it anywhere in the archives. Anybody have a lead on this? Yep - I have a lead (not too surprising since I wrote the program :)) I think the program's present in the PUPS archive in the top of the 2.11 tree area but it may have been relocated or whatever over time. Here's the program - it should compile on just about anything that has the 'mtio' ioctl functions. It is very similar to 'maketape' (intentional since makesimtape.c started out as a copy of maketape.c). Steven Schultz moe.2bsd.com -------------------------- /* * @(#)makesimtape.c 2.1 (2.11BSD) 1998/12/31 * Hacked 'maketape.c' to write a file in a format suitable for * use with Bob Supnik's PDP-11 simulator (V2.3) emulated tape * driver. * * NOTE: a PDP-11 has to flip the shorts within the long when writing out * the record size. Seems a PDP-11 is neither a little-endian * machine nor a big-endian one. */ #include #include #include #include #include #include #include #define MAXB 30 char buf[MAXB * 512]; char name[50]; long recsz, flipped, trl(); int blksz; int mt, fd, cnt; struct iovec iovec[3]; struct iovec tmark[2]; void usage(); main(argc, argv) int argc; char *argv[]; { int i, j = 0, k = 0; long zero = 0; register char *outfile = NULL, *infile = NULL; FILE *mf; struct stat st; while ((i = getopt(argc, argv, "i:o:")) != EOF) { switch (i) { case 'o': outfile = optarg; break; case 'i': infile = optarg; break; default: usage(); /* NOTREACHED */ } } if (!outfile || !infile) usage(); /* NOTREACHED */ /* * Stat the outfile and make sure it either 1) Does not exist, or * 2) Exists but is a regular file. */ if (stat(outfile, &st) != -1 && !(S_ISREG(st.st_mode))) errx(1, "outfile must either not exist or be a regular file"); /* NOTREACHED */ mt = open(outfile, O_WRONLY|O_CREAT|O_TRUNC, 0600); if (mt < 0) err(1, "Can not create %s", outfile); /* NOTREACHED */ mf = fopen(infile, "r"); if (!mf) err(1, "Can not open %s", infile); /* NOTREACHED*/ tmark[0].iov_len = sizeof (long); tmark[0].iov_base = (char *)&zero; while (1) { if ((i = fscanf(mf, "%s %d", name, &blksz))== EOF) exit(0); if (i != 2) { fprintf(stderr,"Help! Scanf didn't read 2 things (%d)\n", i); exit(1); } if (blksz <= 0 || blksz > MAXB) { fprintf(stderr, "Block size %u is invalid\n", blksz); exit(1); } recsz = blksz * 512; /* convert to bytes */ iovec[0].iov_len = sizeof (recsz); #ifdef pdp11 iovec[0].iov_base = (char *)&flipped; #else iovec[0].iov_base = (char *)&recsz; #endif iovec[1].iov_len = (int)recsz; iovec[1].iov_base = buf; iovec[2].iov_len = iovec[0].iov_len; iovec[2].iov_base = iovec[0].iov_base; if (strcmp(name, "*") == 0) { if (writev(mt, tmark, 1) < 0) warn(1, "writev of pseudo tapemark failed"); k++; continue; } fd = open(name, 0); if (fd < 0) err(1, "Can't open %s for reading", name); /* NOTREACHED */ printf("%s: block %d, file %d\n", name, j, k); /* * we pad the last record with nulls * (instead of the bell std. of padding with trash). * this allows you to access text files on the * tape without garbage at the end of the file. * (note that there is no record length associated * with tape files) */ while ((cnt=read(fd, buf, (int)recsz)) == (int)recsz) { j++; #ifdef pdp11 flipped = trl(recsz); #endif if (writev(mt, iovec, 3) < 0) err(1, "writev #1"); /* NOTREACHED */ } if (cnt > 0) { j++; bzero(buf + cnt, (int)recsz - cnt); #ifdef pdp11 flipped = trl(recsz); #endif if (writev(mt, iovec, 3) < 0) err(1, "writev #2"); /* NOTREACHED */ } close(fd); } /* * Write two tape marks to simulate EOT */ writev(mt, tmark, 1); writev(mt, tmark, 1); } long trl(l) long l; { union { long l; short s[2]; } foo; register short x; foo.l = l; x = foo.s[0]; foo.s[0] = foo.s[1]; foo.s[1] = x; return(foo.l); } void usage() { fprintf(stderr, "usage: makesimtape -o outfilefile -i inputfile\n"); exit(1); } From greg at ciswired.com Mon Aug 14 07:22:13 2000 From: greg at ciswired.com (Gregory R. Travis) Date: Sun, 13 Aug 2000 16:22:13 -0500 (EST) Subject: [pups] Needed 2.11BSD 9-track boot tapes Message-ID: What I have: 11/83, QBUS, 2MB, DH11, running RT-11 5.04 plus TSX - Kermit is installed on the machine 2x CDC 384MB SMD disks attached to Emulex Controller emulating MSCP 1 DigiData 800/1600 BPI 9-track drive attached to TM-11 emulating controller What I need: Way to get 2.11BSD onto one of the CDC drives (preferably not to one with RT-11). How I can do that: 1. Kermit transfer of 2.11BSD images to RT-11 q1. Is there a way to then transfer from RT-11 to one of the CDC disks? q2. Is there a way to then transfer from RT-11 to tape images on the DigiData? 2. A kind soul sends me a set of 9-track 2.11BSD tapes with boot images. 3. Other? Any takers? Thanks! greg Gregory Travis Cornerstone Information Systems ATS greg at ciswired.com 812 330 4361 ext. 18 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id LAA56396 for pups-liszt; Mon, 14 Aug 2000 11:34:57 +1000 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From sms at moe.2bsd.com Mon Aug 14 11:30:40 2000 From: sms at moe.2bsd.com (Steven M. Schultz) Date: Sun, 13 Aug 2000 18:30:40 -0700 (PDT) Subject: [pups] Needed 2.11BSD 9-track boot tapes Message-ID: <200008140130.SAA18988@moe.2bsd.com> > From: "Gregory R. Travis" > What I have: > > 11/83, QBUS, 2MB, DH11, running RT-11 5.04 plus TSX > - Kermit is installed on the machine > 2x CDC 384MB SMD disks attached to Emulex Controller emulating MSCP > 1 DigiData 800/1600 BPI 9-track drive attached to TM-11 emulating > controller It wouldn't happen to be an Emulex UC07 or UC08 would it? If so there are a couple possibilities that open up. > How I can do that: > 1. Kermit transfer of 2.11BSD images to RT-11 Slow but sure - the sum total of data to move is close to 80mb > q1. Is there a way to then transfer from RT-11 to one > of the CDC disks? I don't think RT-11 understands the 2.11BSD filesystem so I don't think this approach can be made to work. > q2. Is there a way to then transfer from RT-11 to tape > images on the DigiData? This can be made to work but it depends on having a program that can transfer the the files "bytes as bytes" (no record format interpretation, etc) _and_ handle multiple blocking factors on the first tape. If you have the PDP-11 volume of the archives you should see in the PDP-11/Distributions/ucb/2.11BSD directory two files called 'maketape.c' and 'maketape.data'. It's a small program and if a counterpart to that could be created for RT-11 you'd be all set to go. The layout of the first tape normally is: mtboot+mtboot+boot (512 byte blocking factor) disklabel (1024 byte blocking factor) mkfs (1024 byte blocking factor) restor (1024 byte blocking factor) icheck (1024 byte blocking factor) root.dump (10240 byte blocking factor) file6.tar (10240 byte blocking factor) file7.tar (10240 byte blocking factor) The 2nd tape contains file8.tar blocked at 10240 bytes. The "boot" tape really only need to have the first few files, up to and including 'root.dump'. Those are enough to boot the tape, run the standalone utilties to label the disk, create the filesystem and restor the root filesystem. The tar archives can be (with suitable interpolation of the installation instructions) be placed on individual tapes. This may be necessary because file7.tar may or may not fit any longer on the first tape. Why three blocking factors? Well, partly historical and partly hardware reasons. The first "file" contains the 'bootblock' and that needs to be 512 bytes since that's all the hardware will read. The standalone i/o system uses 1024 byte blocks so the next few files use 1k records. After the standalone utilities are done and the system is loaded 'tar' can use its default 20 sector (10kb) record size. > 2. A kind soul sends me a set of 9-track 2.11BSD tapes with > boot images. My tape drive may or may not work - it's been ages since it was last powered up and I fear the rubber parts may have disintegrated (or the capacitors dried out, etc). > 3. Other? If you could find a TK70+TQK70 drive+controller that would be awesome. They're pretty cheap (less than $100 I believe - I didn't pay much for mine). Or even a TK50 drive (almost free) attached to a TQK70 would be fine. The TQK70 is a vastly better controller than the TQK50 because the former has a buffer cache that makes a huge difference is how often the tape stops moving. If the Emulex controller you have is SCSI based (UC07 or 08) then someone could stage and make available a 2.11BSD Zip disk image with all the stuff needed to boot and run the installation proceedure (I've a Zip disk attached to my UC08 - works great). Alternatively a 2.11 formatted CDROM could be created and a CDrom drive (that knew about 512 byte blocks instead of 2048 byte blocks) could be used. Good Luck! Steven Schultz sms at moe.2bsd.com Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id OAA57080 for pups-liszt; Mon, 14 Aug 2000 14:12:09 +1000 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From greg at ciswired.com Mon Aug 14 13:25:30 2000 From: greg at ciswired.com (Gregory R. Travis) Date: Sun, 13 Aug 2000 22:25:30 -0500 (EST) Subject: [pups] Needed 2.11BSD 9-track boot tapes In-Reply-To: <200008140130.SAA18988@moe.2bsd.com> Message-ID: On Sun, 13 Aug 2000, Steven M. Schultz wrote: > > From: "Gregory R. Travis" > > What I have: > > > > 11/83, QBUS, 2MB, DH11, running RT-11 5.04 plus TSX > > - Kermit is installed on the machine > > 2x CDC 384MB SMD disks attached to Emulex Controller emulating MSCP > > 1 DigiData 800/1600 BPI 9-track drive attached to TM-11 emulating > > controller > > It wouldn't happen to be an Emulex UC07 or UC08 would it? If so > there are a couple possibilities that open up. No, it's a DigiData board. Single QBUS board. Two 40-pin connectors. > > > How I can do that: > > 1. Kermit transfer of 2.11BSD images to RT-11 > > Slow but sure - the sum total of data to move is close to 80mb I've already been waiting a few weeks :-) > This can be made to work but it depends on having a program that can > transfer the the files "bytes as bytes" (no record format > interpretation, etc) _and_ handle multiple blocking factors on the > first tape. > > If you have the PDP-11 volume of the archives you should see in the > PDP-11/Distributions/ucb/2.11BSD directory two files called 'maketape.c' > and 'maketape.data'. It's a small program and if a counterpart to > that could be created for RT-11 you'd be all set to go. Yeah, it's the RT-11 part that I don't know. It's a little hard to believe that in 20+ years no-one has come up with an RT-11 program to build UNIX distribution tapes! :-) (again) > > 2. A kind soul sends me a set of 9-track 2.11BSD tapes with > > boot images. > > My tape drive may or may not work - it's been ages since it was > last powered up and I fear the rubber parts may have disintegrated > (or the capacitors dried out, etc). The Windex and electrical tape are on me. Did I mention that I would happiliy provide 9-track boot service in the future? That is. once I can get a system running! > If the Emulex controller you have is SCSI based (UC07 or 08) then > someone could stage and make available a 2.11BSD Zip disk image > with all the stuff needed to boot and run the installation proceedure > (I've a Zip disk attached to my UC08 - works great). > Alternatively a 2.11 formatted CDROM could be created and a CDrom > drive (that knew about 512 byte blocks instead of 2048 byte blocks) > could be used. Not SCSI, SMD/MSCP/Pertec formatted unfortunately greg Gregory Travis Cornerstone Information Systems ATS greg at ciswired.com 812 330 4361 ext. 18 From agrier at poofygoof.com Mon Aug 21 06:30:09 2000 From: agrier at poofygoof.com (Aaron J. Grier) Date: Sun, 20 Aug 2000 13:30:09 -0700 Subject: [pups] mystery LSI-11 heath H11 board Message-ID: <20000820133009.G12503@goldberry.poofy.goof.com> an electrician came in to my place of employment last week and installed some new lighting in the "engineering junkyard" which was previously a very dark place. The new light prompted me to do some exploring, and in doing so, I spotted a heath H11! unfortunately, it looks like the case has been stripped, as only one half-height board remains in the cardcage. The handle is labeled "Heath Serial I/O." I threw it on a flatbed scanner and the pictures are here: http://www.poofygoof.com/~agrier/lsi11f.jpg http://www.poofygoof.com/~agrier/lsi11b.jpg Is this one of heathkit's almost-like-DEC-but-not-quite boards? -- Aaron J. Grier | "Not your ordinary poofy goof." | agrier at poofygoof.com From allisonp at world.std.com Mon Aug 21 23:53:19 2000 From: allisonp at world.std.com (allisonp at world.std.com) Date: Mon, 21 Aug 2000 09:53:19 -0400 (EDT) Subject: [pups] mystery LSI-11 heath H11 board In-Reply-To: <20000820133009.G12503@goldberry.poofy.goof.com> Message-ID: Yep it's a replacement for the DEC DLV-11E and programatically the same. It's not nearly as rugged however but worth ahving for any PDP11. Allison On Sun, 20 Aug 2000, Aaron J. Grier wrote: > an electrician came in to my place of employment last week and installed > some new lighting in the "engineering junkyard" which was previously a > very dark place. The new light prompted me to do some exploring, and in > doing so, I spotted a heath H11! > > unfortunately, it looks like the case has been stripped, as only one > half-height board remains in the cardcage. The handle is labeled "Heath > Serial I/O." I threw it on a flatbed scanner and the pictures are here: > > http://www.poofygoof.com/~agrier/lsi11f.jpg > http://www.poofygoof.com/~agrier/lsi11b.jpg > > Is this one of heathkit's almost-like-DEC-but-not-quite boards? > > -- > Aaron J. Grier | "Not your ordinary poofy goof." | agrier at poofygoof.com > From grog at lemis.com Wed Aug 30 12:24:28 2000 From: grog at lemis.com (Greg Lehey) Date: Wed, 30 Aug 2000 11:54:28 +0930 Subject: [pups] Identifying old computers (was: [no subject]) In-Reply-To: <4120008518183739203@yeayea.com>; from spoof@yeayea.com on Fri, Aug 18, 2000 at 01:37:39PM -0500 References: <4120008518183739203@yeayea.com> Message-ID: <20000830115428.D32302@wantadilla.lemis.com> On Friday, 18 August 2000 at 13:37:39 -0500, Spoof wrote: > Hello! Sorry, this languished in my inbox for a while because it didn't have a recognizable subject. I don't recognize the machines, either, but maybe somebody on the PUPS list does. Greg > If you are receiving this email, it is because I found your name during a > websearch about 'classic computing'. At any rate, I have obtained two > computers and I'd like to find out what they are. if you could help me > identfy them i would greatly appreciate it. I was told by the source of > these computers (who seemed very convinvced) that they were PDP-4 > computers. Every site I've seen that covers the pdp-4 says that there were > only about 50 of them ever sold. However, Digital's own site does mention > that some were sold for nuclear applications, and the computers I got were > indeed from a nuclear lab. > > The thing is, there doesnt seem to be any mention of "Digital" or the PDP > name anywhere. > > I'll describe the computers: > > One looks newer, it says "Tracor Northern TN-1610" on the faceplate. It > has 18 ligts across the face and 18 switches directly below, in a bank > labeled "Switch Register". There is another bank of 6 ligts labeled "RUN, > CPU BUS, VIRT, PWR, BUS, USER" > There is a small bank of 3 switches labeled ADDR/DATA, PHYS/VIRT, and INTR. > There is a last bank of 6 switches labelled LOAD ADDR, EXAM, CONT, > ENAB/HALT, START, LOAD DATA. There is also a power switch. > On the bottom of the faceplate is a logo raised in plastic which I didn't > understand until I looked inside the case and found a circuit board which > said "California Data Procesors" (the logo said "CDP" in a funky '60s > style), I've never heard of CDP- perhaps I heard "PDP4" when he actually > said "CDP-4"? > > The second computer looks older. (1960's vs. 1970s). > It's faceplate says "ND812" and "Nuclear Data Inc". There is a rotating > switch labelled "Select Register" with the following positions: Status, S, > R, K, J, Address, PC, External. > There is a keyswitch with three postions: Power off, Power on, Control off. > There is a bank of 12 lights, labelled "Selected Register", the lights are > labelled 0-11 and an extra (13th) light labeled "Overflow". > > There is another bank of 12 lights, labeled "memory Register", again > labeled 0-11. Next to it is a pair of lights labeled "Memory Field" 0 or 1. > next to that is another pair of lights labeled "Run" and "Interrupt. > > Under the lights is a bank of 12 switches labeled "Switch Register". > > There are two switches simply labeled 0 and 1. > > There are two switches labeled Start and Stop > > Another two switches labeled Load AR and Load MR > > Another two labeled Next Word and Cont > > And another two labeled Step and Instr > > > The older computer seems put together in a complicated sort of way (stacked > PCB's wired together) whereas the newer one is more modular (I.E. large > cards that are simply slide in and out of sockets.) > > Both seem to have core memory but it's arranged in such a way that I can't > actually see it with out breaking some paper seals which I dont want to do > unless necessary. The parts of the boards that I can see have intricate > patterns that seem to indicate core memory (plus the guy told me that they > both used core mem). > > I have a (kind of lousy) digital camera and i can take pictures of the > faceplates if you think this might help in your identification. > > As I said, both were in use in a lab. The older one has a set of two tape > drives (they look to be regular audio cassette size) and the newer one has > one tape drive. However I was supplied with piles of punched tape programs > (i guess there was a tape reader with these computers at some point?) i was > given a lot of documentation but most of it has "NDI" written on it and it > is about taking nuclear data measurements. > Both are in large rackmount cases (which I don't have) and were mounted > with other equipment. > > > I'm interested to know what these computers are, how much they cost when > new, and what their capabilities are. Supposedly they were replaced by a > single $4000 MCI interface card in a PC. > > If you have no idea but you think you know someone who might, please do not > hesitate to suggest that person to me. > > Thank you for taking the time to read this email. > > -Kev > > > _____________________________________________ > Free email with personality! Over 200 domains! > http://www.MyOwnEmail.com > -- Finger grog at lemis.com for PGP public key See complete headers for address and phone numbers From sms at moe.2bsd.com Tue Aug 1 01:58:00 2000 From: sms at moe.2bsd.com (Steven M. Schultz) Date: Mon, 31 Jul 2000 08:58:00 -0700 (PDT) Subject: [pups] Overlays? Message-ID: <200007311558.IAA01672@moe.2bsd.com> HI! > From: Jorgen Pehrson > I've just installed 2.11BSD on one of my PDPs, from a TK50 tape I just > re-discovered in the trunk of my car. And now I'm in the process of Wow - those TK50s are quite robust to survive being stored in the truck of a car. I've had audio tapes that did not survive ;) > applying patches. When I installed patch 412 and started to rebuild the > kernel, ld complains with a "ld: too big for type 431". > Does this means that I have to rearrange stuff between the BASE and the > various OV entries? Indeed it does mean exactly that. > How can I find out which overlay is too big? I've tried to do a: > 138% root--> size unix.o Yep - that is the correct method. > text data bss dec hex > 52352 6928 37622 96902 17a86 total text: 115520 > overlays: 7680,7232,7808,7744,4864,8576,4736,6848,7680 > > How big is too big? And also if none of the overlays above are too big, I > guess it must be the BASE that is too big? I thought I wrote this up at one time but I may have only thought about it ;) > Is there some sort of documentation anywhere that describe this voodoo > stuff and black magic a bit? Is it in one an Appendix to the "Setup&Installation" document? In the case above it is OV6 (overlays are numbered from 1) that is too big. The rules are: 1) BASE can be 56kb (57344) max 2) OVerlays can be 8kb (8192) max 3) There can be no 0 length overlays (except for the very last one). > Any suggestions on what .o file I should move to what overlay? Look at the Makefile - you should see a line that starts "OV6=". Do a "size" on the .o files listed for OV6. Pick one that will fix elsewhere - I'd suggest OV5 since it is only 4864 bytes and has lots of room. You could also move a .o file to the BASE since it has adequate room also. Steven Schultz sms at moe.2bsd.com Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id JAA20356 for pups-liszt; Tue, 1 Aug 2000 09:31:49 +1000 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From sms at moe.2bsd.com Tue Aug 1 03:12:43 2000 From: sms at moe.2bsd.com (Steven M. Schultz) Date: Mon, 31 Jul 2000 10:12:43 -0700 (PDT) Subject: [pups] makesimtape.c Message-ID: <200007311712.KAA02116@moe.2bsd.com> Hi! > From: "Ryan Blair" > > While reading back through the mailing list messages, trying to find out why > my tape images never seem to work, I came across a program that I cannot > seem to find. It was mentioned lately as "makesimtape.c" but I cannot find > it anywhere in the archives. Anybody have a lead on this? Yep - I have a lead (not too surprising since I wrote the program :)) I think the program's present in the PUPS archive in the top of the 2.11 tree area but it may have been relocated or whatever over time. Here's the program - it should compile on just about anything that has the 'mtio' ioctl functions. It is very similar to 'maketape' (intentional since makesimtape.c started out as a copy of maketape.c). Steven Schultz moe.2bsd.com -------------------------- /* * @(#)makesimtape.c 2.1 (2.11BSD) 1998/12/31 * Hacked 'maketape.c' to write a file in a format suitable for * use with Bob Supnik's PDP-11 simulator (V2.3) emulated tape * driver. * * NOTE: a PDP-11 has to flip the shorts within the long when writing out * the record size. Seems a PDP-11 is neither a little-endian * machine nor a big-endian one. */ #include #include #include #include #include #include #include #define MAXB 30 char buf[MAXB * 512]; char name[50]; long recsz, flipped, trl(); int blksz; int mt, fd, cnt; struct iovec iovec[3]; struct iovec tmark[2]; void usage(); main(argc, argv) int argc; char *argv[]; { int i, j = 0, k = 0; long zero = 0; register char *outfile = NULL, *infile = NULL; FILE *mf; struct stat st; while ((i = getopt(argc, argv, "i:o:")) != EOF) { switch (i) { case 'o': outfile = optarg; break; case 'i': infile = optarg; break; default: usage(); /* NOTREACHED */ } } if (!outfile || !infile) usage(); /* NOTREACHED */ /* * Stat the outfile and make sure it either 1) Does not exist, or * 2) Exists but is a regular file. */ if (stat(outfile, &st) != -1 && !(S_ISREG(st.st_mode))) errx(1, "outfile must either not exist or be a regular file"); /* NOTREACHED */ mt = open(outfile, O_WRONLY|O_CREAT|O_TRUNC, 0600); if (mt < 0) err(1, "Can not create %s", outfile); /* NOTREACHED */ mf = fopen(infile, "r"); if (!mf) err(1, "Can not open %s", infile); /* NOTREACHED*/ tmark[0].iov_len = sizeof (long); tmark[0].iov_base = (char *)&zero; while (1) { if ((i = fscanf(mf, "%s %d", name, &blksz))== EOF) exit(0); if (i != 2) { fprintf(stderr,"Help! Scanf didn't read 2 things (%d)\n", i); exit(1); } if (blksz <= 0 || blksz > MAXB) { fprintf(stderr, "Block size %u is invalid\n", blksz); exit(1); } recsz = blksz * 512; /* convert to bytes */ iovec[0].iov_len = sizeof (recsz); #ifdef pdp11 iovec[0].iov_base = (char *)&flipped; #else iovec[0].iov_base = (char *)&recsz; #endif iovec[1].iov_len = (int)recsz; iovec[1].iov_base = buf; iovec[2].iov_len = iovec[0].iov_len; iovec[2].iov_base = iovec[0].iov_base; if (strcmp(name, "*") == 0) { if (writev(mt, tmark, 1) < 0) warn(1, "writev of pseudo tapemark failed"); k++; continue; } fd = open(name, 0); if (fd < 0) err(1, "Can't open %s for reading", name); /* NOTREACHED */ printf("%s: block %d, file %d\n", name, j, k); /* * we pad the last record with nulls * (instead of the bell std. of padding with trash). * this allows you to access text files on the * tape without garbage at the end of the file. * (note that there is no record length associated * with tape files) */ while ((cnt=read(fd, buf, (int)recsz)) == (int)recsz) { j++; #ifdef pdp11 flipped = trl(recsz); #endif if (writev(mt, iovec, 3) < 0) err(1, "writev #1"); /* NOTREACHED */ } if (cnt > 0) { j++; bzero(buf + cnt, (int)recsz - cnt); #ifdef pdp11 flipped = trl(recsz); #endif if (writev(mt, iovec, 3) < 0) err(1, "writev #2"); /* NOTREACHED */ } close(fd); } /* * Write two tape marks to simulate EOT */ writev(mt, tmark, 1); writev(mt, tmark, 1); } long trl(l) long l; { union { long l; short s[2]; } foo; register short x; foo.l = l; x = foo.s[0]; foo.s[0] = foo.s[1]; foo.s[1] = x; return(foo.l); } void usage() { fprintf(stderr, "usage: makesimtape -o outfilefile -i inputfile\n"); exit(1); } From greg at ciswired.com Mon Aug 14 07:22:13 2000 From: greg at ciswired.com (Gregory R. Travis) Date: Sun, 13 Aug 2000 16:22:13 -0500 (EST) Subject: [pups] Needed 2.11BSD 9-track boot tapes Message-ID: What I have: 11/83, QBUS, 2MB, DH11, running RT-11 5.04 plus TSX - Kermit is installed on the machine 2x CDC 384MB SMD disks attached to Emulex Controller emulating MSCP 1 DigiData 800/1600 BPI 9-track drive attached to TM-11 emulating controller What I need: Way to get 2.11BSD onto one of the CDC drives (preferably not to one with RT-11). How I can do that: 1. Kermit transfer of 2.11BSD images to RT-11 q1. Is there a way to then transfer from RT-11 to one of the CDC disks? q2. Is there a way to then transfer from RT-11 to tape images on the DigiData? 2. A kind soul sends me a set of 9-track 2.11BSD tapes with boot images. 3. Other? Any takers? Thanks! greg Gregory Travis Cornerstone Information Systems ATS greg at ciswired.com 812 330 4361 ext. 18 Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id LAA56396 for pups-liszt; Mon, 14 Aug 2000 11:34:57 +1000 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From sms at moe.2bsd.com Mon Aug 14 11:30:40 2000 From: sms at moe.2bsd.com (Steven M. Schultz) Date: Sun, 13 Aug 2000 18:30:40 -0700 (PDT) Subject: [pups] Needed 2.11BSD 9-track boot tapes Message-ID: <200008140130.SAA18988@moe.2bsd.com> > From: "Gregory R. Travis" > What I have: > > 11/83, QBUS, 2MB, DH11, running RT-11 5.04 plus TSX > - Kermit is installed on the machine > 2x CDC 384MB SMD disks attached to Emulex Controller emulating MSCP > 1 DigiData 800/1600 BPI 9-track drive attached to TM-11 emulating > controller It wouldn't happen to be an Emulex UC07 or UC08 would it? If so there are a couple possibilities that open up. > How I can do that: > 1. Kermit transfer of 2.11BSD images to RT-11 Slow but sure - the sum total of data to move is close to 80mb > q1. Is there a way to then transfer from RT-11 to one > of the CDC disks? I don't think RT-11 understands the 2.11BSD filesystem so I don't think this approach can be made to work. > q2. Is there a way to then transfer from RT-11 to tape > images on the DigiData? This can be made to work but it depends on having a program that can transfer the the files "bytes as bytes" (no record format interpretation, etc) _and_ handle multiple blocking factors on the first tape. If you have the PDP-11 volume of the archives you should see in the PDP-11/Distributions/ucb/2.11BSD directory two files called 'maketape.c' and 'maketape.data'. It's a small program and if a counterpart to that could be created for RT-11 you'd be all set to go. The layout of the first tape normally is: mtboot+mtboot+boot (512 byte blocking factor) disklabel (1024 byte blocking factor) mkfs (1024 byte blocking factor) restor (1024 byte blocking factor) icheck (1024 byte blocking factor) root.dump (10240 byte blocking factor) file6.tar (10240 byte blocking factor) file7.tar (10240 byte blocking factor) The 2nd tape contains file8.tar blocked at 10240 bytes. The "boot" tape really only need to have the first few files, up to and including 'root.dump'. Those are enough to boot the tape, run the standalone utilties to label the disk, create the filesystem and restor the root filesystem. The tar archives can be (with suitable interpolation of the installation instructions) be placed on individual tapes. This may be necessary because file7.tar may or may not fit any longer on the first tape. Why three blocking factors? Well, partly historical and partly hardware reasons. The first "file" contains the 'bootblock' and that needs to be 512 bytes since that's all the hardware will read. The standalone i/o system uses 1024 byte blocks so the next few files use 1k records. After the standalone utilities are done and the system is loaded 'tar' can use its default 20 sector (10kb) record size. > 2. A kind soul sends me a set of 9-track 2.11BSD tapes with > boot images. My tape drive may or may not work - it's been ages since it was last powered up and I fear the rubber parts may have disintegrated (or the capacitors dried out, etc). > 3. Other? If you could find a TK70+TQK70 drive+controller that would be awesome. They're pretty cheap (less than $100 I believe - I didn't pay much for mine). Or even a TK50 drive (almost free) attached to a TQK70 would be fine. The TQK70 is a vastly better controller than the TQK50 because the former has a buffer cache that makes a huge difference is how often the tape stops moving. If the Emulex controller you have is SCSI based (UC07 or 08) then someone could stage and make available a 2.11BSD Zip disk image with all the stuff needed to boot and run the installation proceedure (I've a Zip disk attached to my UC08 - works great). Alternatively a 2.11 formatted CDROM could be created and a CDrom drive (that knew about 512 byte blocks instead of 2048 byte blocks) could be used. Good Luck! Steven Schultz sms at moe.2bsd.com Received: (from major at localhost) by minnie.cs.adfa.edu.au (8.9.3/8.9.3) id OAA57080 for pups-liszt; Mon, 14 Aug 2000 14:12:09 +1000 (EST) (envelope-from owner-pups at minnie.cs.adfa.edu.au) From greg at ciswired.com Mon Aug 14 13:25:30 2000 From: greg at ciswired.com (Gregory R. Travis) Date: Sun, 13 Aug 2000 22:25:30 -0500 (EST) Subject: [pups] Needed 2.11BSD 9-track boot tapes In-Reply-To: <200008140130.SAA18988@moe.2bsd.com> Message-ID: On Sun, 13 Aug 2000, Steven M. Schultz wrote: > > From: "Gregory R. Travis" > > What I have: > > > > 11/83, QBUS, 2MB, DH11, running RT-11 5.04 plus TSX > > - Kermit is installed on the machine > > 2x CDC 384MB SMD disks attached to Emulex Controller emulating MSCP > > 1 DigiData 800/1600 BPI 9-track drive attached to TM-11 emulating > > controller > > It wouldn't happen to be an Emulex UC07 or UC08 would it? If so > there are a couple possibilities that open up. No, it's a DigiData board. Single QBUS board. Two 40-pin connectors. > > > How I can do that: > > 1. Kermit transfer of 2.11BSD images to RT-11 > > Slow but sure - the sum total of data to move is close to 80mb I've already been waiting a few weeks :-) > This can be made to work but it depends on having a program that can > transfer the the files "bytes as bytes" (no record format > interpretation, etc) _and_ handle multiple blocking factors on the > first tape. > > If you have the PDP-11 volume of the archives you should see in the > PDP-11/Distributions/ucb/2.11BSD directory two files called 'maketape.c' > and 'maketape.data'. It's a small program and if a counterpart to > that could be created for RT-11 you'd be all set to go. Yeah, it's the RT-11 part that I don't know. It's a little hard to believe that in 20+ years no-one has come up with an RT-11 program to build UNIX distribution tapes! :-) (again) > > 2. A kind soul sends me a set of 9-track 2.11BSD tapes with > > boot images. > > My tape drive may or may not work - it's been ages since it was > last powered up and I fear the rubber parts may have disintegrated > (or the capacitors dried out, etc). The Windex and electrical tape are on me. Did I mention that I would happiliy provide 9-track boot service in the future? That is. once I can get a system running! > If the Emulex controller you have is SCSI based (UC07 or 08) then > someone could stage and make available a 2.11BSD Zip disk image > with all the stuff needed to boot and run the installation proceedure > (I've a Zip disk attached to my UC08 - works great). > Alternatively a 2.11 formatted CDROM could be created and a CDrom > drive (that knew about 512 byte blocks instead of 2048 byte blocks) > could be used. Not SCSI, SMD/MSCP/Pertec formatted unfortunately greg Gregory Travis Cornerstone Information Systems ATS greg at ciswired.com 812 330 4361 ext. 18 From agrier at poofygoof.com Mon Aug 21 06:30:09 2000 From: agrier at poofygoof.com (Aaron J. Grier) Date: Sun, 20 Aug 2000 13:30:09 -0700 Subject: [pups] mystery LSI-11 heath H11 board Message-ID: <20000820133009.G12503@goldberry.poofy.goof.com> an electrician came in to my place of employment last week and installed some new lighting in the "engineering junkyard" which was previously a very dark place. The new light prompted me to do some exploring, and in doing so, I spotted a heath H11! unfortunately, it looks like the case has been stripped, as only one half-height board remains in the cardcage. The handle is labeled "Heath Serial I/O." I threw it on a flatbed scanner and the pictures are here: http://www.poofygoof.com/~agrier/lsi11f.jpg http://www.poofygoof.com/~agrier/lsi11b.jpg Is this one of heathkit's almost-like-DEC-but-not-quite boards? -- Aaron J. Grier | "Not your ordinary poofy goof." | agrier at poofygoof.com From allisonp at world.std.com Mon Aug 21 23:53:19 2000 From: allisonp at world.std.com (allisonp at world.std.com) Date: Mon, 21 Aug 2000 09:53:19 -0400 (EDT) Subject: [pups] mystery LSI-11 heath H11 board In-Reply-To: <20000820133009.G12503@goldberry.poofy.goof.com> Message-ID: Yep it's a replacement for the DEC DLV-11E and programatically the same. It's not nearly as rugged however but worth ahving for any PDP11. Allison On Sun, 20 Aug 2000, Aaron J. Grier wrote: > an electrician came in to my place of employment last week and installed > some new lighting in the "engineering junkyard" which was previously a > very dark place. The new light prompted me to do some exploring, and in > doing so, I spotted a heath H11! > > unfortunately, it looks like the case has been stripped, as only one > half-height board remains in the cardcage. The handle is labeled "Heath > Serial I/O." I threw it on a flatbed scanner and the pictures are here: > > http://www.poofygoof.com/~agrier/lsi11f.jpg > http://www.poofygoof.com/~agrier/lsi11b.jpg > > Is this one of heathkit's almost-like-DEC-but-not-quite boards? > > -- > Aaron J. Grier | "Not your ordinary poofy goof." | agrier at poofygoof.com > From grog at lemis.com Wed Aug 30 12:24:28 2000 From: grog at lemis.com (Greg Lehey) Date: Wed, 30 Aug 2000 11:54:28 +0930 Subject: [pups] Identifying old computers (was: [no subject]) In-Reply-To: <4120008518183739203@yeayea.com>; from spoof@yeayea.com on Fri, Aug 18, 2000 at 01:37:39PM -0500 References: <4120008518183739203@yeayea.com> Message-ID: <20000830115428.D32302@wantadilla.lemis.com> On Friday, 18 August 2000 at 13:37:39 -0500, Spoof wrote: > Hello! Sorry, this languished in my inbox for a while because it didn't have a recognizable subject. I don't recognize the machines, either, but maybe somebody on the PUPS list does. Greg > If you are receiving this email, it is because I found your name during a > websearch about 'classic computing'. At any rate, I have obtained two > computers and I'd like to find out what they are. if you could help me > identfy them i would greatly appreciate it. I was told by the source of > these computers (who seemed very convinvced) that they were PDP-4 > computers. Every site I've seen that covers the pdp-4 says that there were > only about 50 of them ever sold. However, Digital's own site does mention > that some were sold for nuclear applications, and the computers I got were > indeed from a nuclear lab. > > The thing is, there doesnt seem to be any mention of "Digital" or the PDP > name anywhere. > > I'll describe the computers: > > One looks newer, it says "Tracor Northern TN-1610" on the faceplate. It > has 18 ligts across the face and 18 switches directly below, in a bank > labeled "Switch Register". There is another bank of 6 ligts labeled "RUN, > CPU BUS, VIRT, PWR, BUS, USER" > There is a small bank of 3 switches labeled ADDR/DATA, PHYS/VIRT, and INTR. > There is a last bank of 6 switches labelled LOAD ADDR, EXAM, CONT, > ENAB/HALT, START, LOAD DATA. There is also a power switch. > On the bottom of the faceplate is a logo raised in plastic which I didn't > understand until I looked inside the case and found a circuit board which > said "California Data Procesors" (the logo said "CDP" in a funky '60s > style), I've never heard of CDP- perhaps I heard "PDP4" when he actually > said "CDP-4"? > > The second computer looks older. (1960's vs. 1970s). > It's faceplate says "ND812" and "Nuclear Data Inc". There is a rotating > switch labelled "Select Register" with the following positions: Status, S, > R, K, J, Address, PC, External. > There is a keyswitch with three postions: Power off, Power on, Control off. > There is a bank of 12 lights, labelled "Selected Register", the lights are > labelled 0-11 and an extra (13th) light labeled "Overflow". > > There is another bank of 12 lights, labeled "memory Register", again > labeled 0-11. Next to it is a pair of lights labeled "Memory Field" 0 or 1. > next to that is another pair of lights labeled "Run" and "Interrupt. > > Under the lights is a bank of 12 switches labeled "Switch Register". > > There are two switches simply labeled 0 and 1. > > There are two switches labeled Start and Stop > > Another two switches labeled Load AR and Load MR > > Another two labeled Next Word and Cont > > And another two labeled Step and Instr > > > The older computer seems put together in a complicated sort of way (stacked > PCB's wired together) whereas the newer one is more modular (I.E. large > cards that are simply slide in and out of sockets.) > > Both seem to have core memory but it's arranged in such a way that I can't > actually see it with out breaking some paper seals which I dont want to do > unless necessary. The parts of the boards that I can see have intricate > patterns that seem to indicate core memory (plus the guy told me that they > both used core mem). > > I have a (kind of lousy) digital camera and i can take pictures of the > faceplates if you think this might help in your identification. > > As I said, both were in use in a lab. The older one has a set of two tape > drives (they look to be regular audio cassette size) and the newer one has > one tape drive. However I was supplied with piles of punched tape programs > (i guess there was a tape reader with these computers at some point?) i was > given a lot of documentation but most of it has "NDI" written on it and it > is about taking nuclear data measurements. > Both are in large rackmount cases (which I don't have) and were mounted > with other equipment. > > > I'm interested to know what these computers are, how much they cost when > new, and what their capabilities are. Supposedly they were replaced by a > single $4000 MCI interface card in a PC. > > If you have no idea but you think you know someone who might, please do not > hesitate to suggest that person to me. > > Thank you for taking the time to read this email. > > -Kev > > > _____________________________________________ > Free email with personality! Over 200 domains! > http://www.MyOwnEmail.com > -- Finger grog at lemis.com for PGP public key See complete headers for address and phone numbers