TUHS

tuhs@tuhs.org

6420 discussions

Re: Some nice progress with hardware and Ultrix in the PUPS archive

by Michael Sokolov

Dear Tim, You write: > I'd be glad to run off TK50's from images > for you, though I think your earlier idea, about installing from > the miniroot image that's commonly put on 4.2- and 4.3BSD derived > distributions, is a *far* better idea as it avoids using a TK50 > tape drive at all. I will need to boot from a tape at some point in any case. I have to boot from SOMETHING. Since none of the disks in this machine is bootable, I have to boot either from a tape or over the network. Since the only two computers in my apartment are the VAX in question and my DOS machine, netbooting is not an option. Well, I could attach another disk to the PC, download FreeBSD, and install it, but this is _WAY_ too much pain. Also there is no guarantee of success with this approach, since there are all kinds of traps waiting to catch me. The spare disk I'm talking about may turn out to be toast, FreeBSD may not like something about this PC, the DELQA in the VAX may turn out broken, etc., etc., etc. OTOH, the labor investment in just trying it out is enormous (this PC has a VERY special configuration, and adding another disk may turn out to be a royal pita, plus downloading FreeBSD or some other PeeCee UNIX clone over my 14400 BPS modem is going to be a nightmare). On the other hand, I know that the TK50 boot path is working, since I have been able to boot from some VMSish tape (see my previous messages), thus all I need is a good Ultrix tape. Another friendly PUPS member has promised to send me copies of his Ultrix tapes, so hopefully I'll get something going. > It's not that tape copies are bad ideas - it's just that TK50's > are so slow. If you were coming from 9-track or DLT or something > fast, that wouldn't be so bad. Are 9-track tapes faster than TK50s? In addition to the TK50 I also have the CDC Keystone and the QT13 which seems to work after all, but I _STRONGLY_ doubt that it's going to be any easier. This big beast is very dirty, it has been exposed to a little rain, and it has been dropped on concrete pavement a couple times, so before I even try plugging it in, I would have to perform a very careful cleaning and inspection procedure, and I currently don't have anywhere near the resources and knowledge needed for that operation. > If you can get just about any OS running on your > Q-bus machine, under any CPU - i.e. NetBSD, RT-11, 2.11BSD, RSX, > whatever you might have - then you can just write the miniroot > straight to a "scratch" disk. Again, regardless of what approach I take, I'll need to boot from some device first. See above. Sincerely, Michael Sokolov Cellular phone: 216-217-2579 ARPA Internet SMTP mail: msokolov(a)harrier.Uznet.NET Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA13664 for pups-liszt; Tue, 8 Dec 1998 03:51:29 +1100 (EST) >From Michael Sokolov <msokolov(a)harrier.Uznet.NET> Tue Dec 8 02:49:46 1998 Received: from harrier.Uznet.NET (harrier.ml.org [193.220.92.194]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id DAA13659 for <pups(a)minnie.cs.adfa.edu.au>; Tue, 8 Dec 1998 03:51:04 +1100 (EST) Received: from dosdev (pm8-105.dial.qual.net [205.212.2.105]) by harrier.Uznet.NET (8.8.8/8.8.8) with SMTP id VAA15637 for <pups(a)minnie.cs.adfa.edu.au>; Mon, 7 Dec 1998 21:50:03 +0500 Message-Id: <199812071650.VAA15637(a)harrier.Uznet.NET> From: Michael Sokolov <msokolov(a)harrier.Uznet.NET> Date: 7 Dec 1998 16:49:46 GMT To: pups(a)minnie.cs.adfa.edu.au Subject: 9-track tape interfaces Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk Dear Tim, Your explanation of 9-track tape interfaces is extremely helpful! Thanks! This area has always been a huge gap in my hardware knowledge. What I still don't understand is how do all these interfaces handle the issue of recording density (800 BPI vs. 1600 BPI vs. 6250 BPI). You are saying that the Pertec unformatted interface is very low-level. Do you mean that it gives the controller the raw stream from the heads without trying to separate data and clock bits? It is my understanding (please correct me if I'm wrong) that the difference between 1600 and 6250 BPI is the data encoding (PE vs. GCR) and that the actual magnetic density (flux transitions per inch) is the same. If so, does this mean that a Pertec unformatted transport can be made 1600 or 6250 BPI at the formatter's discretion without the transport knowing or caring about the density? I mean, is it like the ST-506/412 MFM vs. ST-506/412 RLL thing? And how does the Pertec formatted interface address this issue? In this case the controller has to tell the transport what density it wants with the transport being able to accept or deny the request depending on its capabilities, right? You write: > Yep, Pertec formatted. The QT13 is nice because it'll emulate > either MU: or MS:-type devices. This brings me to the following question. Assuming that the Pertec formatted interface does carry explicit density control information, which software interface would be a better choice in terms of density control, TS-11 or TMSCP? It is my understanding that the original UNIBUS TS-11 is a formatter for Pertec unformatted transports that supports 1600 BPI only, right? If so, the TS-11 interface doesn't give the OS any control over the density, does it? If so, what density does the QT13 choose in this mode? And what about TMSCP? How much control does it give to the OS in terms of density selection? > Yep, a TS05 is a rebadged Cipher F880 (with some slightly-different > firmware). And where does it stand density-wise? According to DEC, TS05 is a 1600 BPI only transport, and as far as I can remember, the Cipher at CWRU had "1600 BPI" printed on the back somewhere. However, it had a switch on the front panel labeled "HI DEN" or something like that. What the hell is this? According to DEC docs, on TS05 this switch is labeled "ENTER" and the docs call it "reserved". > It probably had 4 50-pin edge connectors [...] Yes. > [...] so that multiple drives could > be chained on the same Pertec-formatted-bus. (There are terminators at > each end of the bus, much like SCSI.) There's provisions for at least > 4 formatters per bus, with each formatter potentially running multiple > drives. Huh! I have never thought about it this way. > (again, with slightly different firmware - for instance a DEC TU80 > controller > will only work with TU80 drives or their CDC equivalent, the Keystone.) CDC Keystone is exactly what I have here. The interface coming out of the (incredibly huge) cabinet is Pertec formatted. Does it have a Pertec unformatted interface lurking inside or not? Which densities does it support? > TU80's and TS(V)05's are simple > Pertec formatted interfaces. Other times they convert to some other > interface (Massbus, LESI, etc.) before the cables come out to the "real > world". Hmm, the only DEC tape transport with LESI I know of is TU81+. Are there any others? And what about that plus? Has there ever been a TU81 without the plus? My manuals are at my main VAX farm from which I'm currently away, but I remember the picture of the TU81+ in there looked similar to the Keystone I have here. Since you say above that TU80 is Keystone in disguise, does it mean that TU80, TU81, and TU81+ are all the same beast with different interface converters tacked on? And what is LESI anyway? I have heard somewhere that the KLESI controller can drive more than just a TU81+, so is LESI actually more than just a tape interface? Oh, what about that leading edge strobe vs. trailing edge strobe? Your vmsnet.pdp11 posting with the QT13 switch settings says that Kennedy 9300 uses trailing edge strobe while all others use leading edge strobe. Mine, however, is set for trailing edge strobe, and it was connected to the Keystone. Does this mean that the Keystone and Kennedy 9300 are the same beast, or is it simply that the 9300 is not the only transport using trailing edge strobe? Sincerely, Michael Sokolov Cellular phone: 216-217-2579 ARPA Internet SMTP mail: msokolov(a)harrier.Uznet.NET Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA13678 for pups-liszt; Tue, 8 Dec 1998 03:51:55 +1100 (EST) >From Michael Sokolov <msokolov(a)harrier.Uznet.NET> Tue Dec 8 02:51:09 1998 Received: from harrier.Uznet.NET (harrier.ml.org [193.220.92.194]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id DAA13671 for <pups(a)minnie.cs.adfa.edu.au>; Tue, 8 Dec 1998 03:51:39 +1100 (EST) Received: from dosdev (pm8-105.dial.qual.net [205.212.2.105]) by harrier.Uznet.NET (8.8.8/8.8.8) with SMTP id VAA15642 for <pups(a)minnie.cs.adfa.edu.au>; Mon, 7 Dec 1998 21:51:19 +0500 Message-Id: <199812071651.VAA15642(a)harrier.Uznet.NET> From: Michael Sokolov <msokolov(a)harrier.Uznet.NET> Date: 7 Dec 1998 16:51:09 GMT To: pups(a)minnie.cs.adfa.edu.au Subject: Sigma unidentified flying board Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk Dear Tim, You write: > Any chance it's a simple parallel I/O? > > Could also be the bus interface for a Sigma and/or DSD MFM drive > controller (if so, it probably emulates RL02's). The assembly number > sounds vaguely DSD-like. From looking at the board I see that the BDMGI and BDMGO fingers are simply shorted and not connected to any circuitry. This means that the board is non-DMA, right? If so, it can't emulate RL-11 or any other DEC disk controller because they are all DMA, right? The BIAKI and BIAKO fingers ARE connected to some circuitry, though, so at least this board interrupts, right? And what's DSD? What MFM controller are you referring to? The "SIGMA INFORMATION SYSTEMS, INC." label and the assembly number are etched, not silk-screened, stamped, or stickered, so it suggests that Sigma is the original designer. Sincerely, Michael Sokolov Cellular phone: 216-217-2579 ARPA Internet SMTP mail: msokolov(a)harrier.Uznet.NET Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA14057 for pups-liszt; Tue, 8 Dec 1998 05:32:10 +1100 (EST) >From Rick Copeland <rickgc(a)calweb.com> Tue Dec 8 04:41:59 1998 Received: from mail.calweb.com (mail.calweb.com [208.131.56.12]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id FAA14052 for <pups(a)minnie.cs.adfa.oz.au>; Tue, 8 Dec 1998 05:32:00 +1100 (EST) Received: by mail.calweb.com (8.8.6/8.8.6) with SMTP id KAA09365 for <pups(a)minnie.cs.adfa.oz.au>; Mon, 7 Dec 1998 10:31:55 -0800 (PST) X-SMTP: helo rgc from rickgc(a)calweb.com server @12.22.0.83 ip 12.22.0.83 Message-Id: <3.0.32.19981207104119.00926100(a)pop.calweb.com> X-Sender: rickgc(a)pop.calweb.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 07 Dec 1998 10:41:59 -0800 To: pups(a)minnie.cs.adfa.oz.au (Unix Heritage Society) From: Rick Copeland <rickgc(a)calweb.com> Subject: Rugged 1182 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk Dear PUPS list, I recently picked up a rack mounted computer that is called a "Rugged 11/82". One individual I know has suggested that it is a pdp 11/82 is a ruggedized box. Has anyone on this list seen one of these. Is there any software in the PUPS archive that might run on one of these? Sincerely, Rick Copeland Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA14248 for pups-liszt; Tue, 8 Dec 1998 05:53:26 +1100 (EST) >From Tim Shoppa <SHOPPA(a)trailing-edge.com> Tue Dec 8 04:53:01 1998 Received: from timaxp.trailing-edge.com (trailing-edge.wdn.com [198.232.144.27]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with SMTP id FAA14243 for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Tue, 8 Dec 1998 05:53:13 +1100 (EST) Received: by timaxp.trailing-edge.com for PUPS(a)MINNIE.CS.ADFA.OZ.AU; Mon, 7 Dec 1998 13:53:01 -0500 Date: Mon, 7 Dec 1998 13:53:01 -0500 From: Tim Shoppa <SHOPPA(a)trailing-edge.com> To: PUPS(a)MINNIE.CS.ADFA.OZ.AU Message-Id: <981207135301.2f0000e2(a)trailing-edge.com> Subject: Re: Rugged 1182 Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk >I recently picked up a rack mounted computer that is called a "Rugged >11/82". One individual I know has suggested that it is a pdp 11/82 is a >ruggedized box. Has anyone on this list seen one of these. I have seen ruggedized 11/83's, as well as "Industrial 11/83"'s, but it's not clear yet exactly what you have. The obvious solution is to look inside and see what Q-bus and/or Unibus boards are present. > Is there any >software in the PUPS archive that might run on one of these? Some ruggedized PDP-11 systems didn't have a real Q-bus or Unibus backplane at all, making it very difficult (if not impossible) to use them with a standard disk controller. That's why it's vital that you figure out what exactly is in your machine. Assuming that the guts are indeed a Q-bus or Unibus KDJ-based CPU, you'll be able to run 2.11BSD once you get a compatible disk, load, and console system up and going on it. -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA14657 for pups-liszt; Tue, 8 Dec 1998 06:42:52 +1100 (EST) >From Tim Shoppa <SHOPPA(a)trailing-edge.com> Tue Dec 8 05:42:28 1998 Received: from timaxp.trailing-edge.com (trailing-edge.wdn.com [198.232.144.27]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with SMTP id GAA14652 for <PUPS(a)MINNIE.CS.adfa.edu.AU>; Tue, 8 Dec 1998 06:42:35 +1100 (EST) Received: by timaxp.trailing-edge.com for PUPS(a)MINNIE.CS.adfa.edu.AU; Mon, 7 Dec 1998 14:42:28 -0500 Date: Mon, 7 Dec 1998 14:42:28 -0500 From: Tim Shoppa <SHOPPA(a)trailing-edge.com> To: PUPS(a)minnie.cs.adfa.edu.au Message-Id: <981207144228.2f0000e2(a)trailing-edge.com> Subject: Re: 9-track tape interfaces Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk > Are 9-track tapes faster than TK50s? In every reasonable case that I know of, yes. >In addition to the TK50 I also have >the CDC Keystone and the QT13 which seems to work after all, but I >_STRONGLY_ doubt that it's going to be any easier. This big beast is very >dirty, it has been exposed to a little rain, and it has been dropped on >concrete pavement a couple times, so before I even try plugging it in, I >would have to perform a very careful cleaning and inspection procedure, and >I currently don't have anywhere near the resources and knowledge needed for >that operation. You're lucky - there's an incredible scarcity of moving parts on a TU80/CDC Keystone: two reel motors and a blower are all you've got. There's also two metallic "hub" sensors used to sense tape motion/tension. Clean these and the heads, load a scratch tape with write ring, power it up, close the door, make sure the logic is on, and hit "TEST" followed by "EXECUTE". It'll go into a self-test mode, including some maximum-Maytag gymnastics, which will run for 15 minutes or so on a 2400-foot tape. [Unknown Sigma board] > From looking at the board I see that the BDMGI and BDMGO fingers are >simply shorted and not connected to any circuitry. This means that the >board is non-DMA, right? If so, it can't emulate RL-11 or any other DEC >disk controller because they are all DMA, right? The BIAKI and BIAKO >fingers ARE connected to some circuitry, though, so at least this board >interrupts, right? Hmm - you said it has a 40-pin connector. Given that it doesn't do DMA, I'm guessing that it's either a DLV11-type clone (a single serial line) or a parallel interface (either a DRV11-C type or a line-printer driver, possibly either Data Products or Centronics interface.) > And what's DSD? Data Systems Design - they made some disk controller subsystems. > The "SIGMA >INFORMATION SYSTEMS, INC." label and the assembly number are etched, not >silk-screened, stamped, or stickered, so it suggests that Sigma is the >original designer. Any obvious buffers (or banks of buffers) near the external connector? What are the date codes on the chips? > What I still don't understand is how do all these interfaces handle the >issue of recording density (800 BPI vs. 1600 BPI vs. 6250 BPI). You are >saying that the Pertec unformatted interface is very low-level. Do you mean >that it gives the controller the raw stream from the heads without trying >to separate data and clock bits? At least at 800 and 1600 BPI, the Pertec Unformatted interface does do the data recovery. There's a line from the formatter that puts the drive into either PE (1600 BPI) or NRZI (800 BPI) mode, and some optional lines that set the thresholds of the analog comparators used for data recovery. I'm not too sure about Pertec Unformatted drives at 6250 BPI. > It is my understanding (please correct me >if I'm wrong) that the difference between 1600 and 6250 BPI is the data >encoding (PE vs. GCR) and that the actual magnetic density (flux >transitions per inch) is the same. 6250 BPI is definitely higher flux density on the tape (in addition to the different encoding.) > And how does the Pertec formatted interface address this issue? In this >case the controller has to tell the transport what density it wants with >the transport being able to accept or deny the request depending on its >capabilities, right? There are a couple "spare" lines on the Pertec formatted interface so that the host can tell the formatter such "optional" information. The interpretation of these spare lines was never perfectly standardized: sometimes they're used to select 800 vs 1600 or 1600 vs 6250 BPI operation, other times they're used to put the drive into streaming vs non-streaming mode, other times it's used to change the speed on a streaming drive. The IDEN line was the most commonly used line on the Pertec formatted interface to choose these options, but some CDC drives implemented a scheme where density/speed negotiation were done in a much more complex way. > This brings me to the following question. Assuming that the Pertec >formatted interface does carry explicit density control information, which >software interface would be a better choice in terms of density control, >TS-11 or TMSCP? It depends on what your OS's driver is capable of. In most cases TMSCP gives you more control. > It is my understanding that the original UNIBUS TS-11 is a >formatter for Pertec unformatted transports that supports 1600 BPI only, >right? Right. > If so, the TS-11 interface doesn't give the OS any control over the >density, does it? The "official DEC" TS-11 interface didn't. The DEC TSV05 interface (which was upward-compatible with the TS11's) gave the software control over the "high speed" vs "low speed" bit. And as I pointed out, some drives could be set to interpret this bit as a density select. I don't think the ability to set/clear this bit ever made it into 2.11BSD (looking at the ts driver code there I don't see it, at least) and I have no idea if it ever made it to the 4.xBSD's. > If so, what density does the QT13 choose in this mode? The QT13 will support either IDEN-style density select or CDC-style density select, and I believe in MS: mode this choice is made through the TSV05 speed-select bit. >And what about TMSCP? How much control does it give to the OS in terms of >density selection? TMSCP is much more flexible, and supports at least two different schemes for selecting and reporting density. Here's what I've figured out about possible reported-back density values in the TMSCP packets (as excerpted from my DUSTAT.MAC): DENTBL: TBLENT 1 ,<NRZI 800 BPI> TBLENT 2 ,<PE 1600 BPI> TBLENT 4 ,<GCR 6250 BPI> TBLENT 10 ,<Cartridge (TK50)> TBLENT 401 ,<NRZI 800 BPI> TBLENT 402 ,<PE 1600 BPI> TBLENT 404 ,<GCR 6250 BPI> TBLENT 420 ,<TU82 special high density>;according to RSTS/E TBLENT 1001 ,<Cartridge (TK50)> TBLENT 1002 ,<Cartridge (TK70)> ; 20xx entries are supposed to be RV80, whatever that is, ; according to RSTS/E sources. I'm pretty sure that 2.11BSD properly handles TU81 density select in its TMSCP driver. (Steve, can you confirm this? I know you've made some effort to get write caching to work with TU81's over the years!) In any event, remote density selection/reporting is largely a frill, as any drive/controller combination that I ever used let you explicitly select it with a physical button or a switch and displayed the current selection in some useful way on the drive. >> Yep, a TS05 is a rebadged Cipher F880 (with some slightly-different >> firmware). > And where does it stand density-wise? According to DEC, TS05 is a 1600 >BPI only transport, and as far as I can remember, the Cipher at CWRU had >"1600 BPI" printed on the back somewhere. However, it had a switch on the >front panel labeled "HI DEN" or something like that. What the hell is this? Some Cipher's (I think F890's) supported a special 3200 BPI mode. It was never in real wide use, but it was supported on some other manufacturer's drives (some Kennedy 96xx's, for example.) I know that some F880's had a button that said "HI DEN" but was for all normal purposes non-functional (I think it did become useful for selecting diagnostics.) > CDC Keystone is exactly what I have here. The interface coming out of >the (incredibly huge) cabinet is Pertec formatted. Does it have a Pertec >unformatted interface lurking inside or not? Which densities does it >support? 1600 BPI only, it's an "embedded-formatter" drive, so there is no internal Pertec unformatted interface. > Hmm, the only DEC tape transport with LESI I know of is TU81+. Are there >any others? Yep, the RC25 also used the LESI bus. (LESI="Low End Storage Interconnect".) > And what about that plus? Has there ever been a TU81 without >the plus? Hmm - the non-plus may have been the version without write-caching. Not real sure. >Keystone I have here. Since you say above that TU80 is Keystone in >disguise, does it mean that TU80, TU81, and TU81+ are all the same beast >with different interface converters tacked on? They all look similar, and have similar mechanics, but the 81's electronics can do 6250 BPI, something an 80's can't. > And what is LESI anyway? I have heard somewhere that the KLESI >controller can drive more than just a TU81+, so is LESI actually more than >just a tape interface? It was CDC's attempt at a SCSI-like universal interface. > Oh, what about that leading edge strobe vs. trailing edge strobe? Your >vmsnet.pdp11 posting with the QT13 switch settings says that Kennedy 9300 >uses trailing edge strobe while all others use leading edge strobe. Mine, >however, is set for trailing edge strobe, and it was connected to the >Keystone. Does this mean that the Keystone and Kennedy 9300 are the same >beast, or is it simply that the 9300 is not the only transport using >trailing edge strobe? Hmm - some combinations of drives may not be sensitive to this. (It's also possibly a misprint in my QT13 manual, as I remember having to futz with this switch's setting in some cases to get everything to work.) No, the Keystone and the Kennedy 9300 are not the same beast. The Keystone is a cute little streaming tape drive, while the 9300 is a humongous vacuum-column 125IPS machine. (I'm sure someone will now chime in about the days when Univac UniServo drives ruled the earth...) -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927

26 years, 2 months

Re: Some nice progress with hardware and Ultrix in the PUPS archive

by Warren Toomey

In article by Michael Sokolov: > As I was thinking about how else can I get correctly written Ultrix > tapes, the following idea sneaked into my mind. The PUPS archive already > contains PDP-11 Ultrix. How about VAX Ultrix? With Warren's permission, I > would be more than happy to upload my VAX Ultrix tape images (I have them > sitting as files on my DOS disk). Once that is done, would someone > volunteer to download them, write them to two TK50 cartridges, and send > them to me? TIA for any help. We have to be careful with 3rd party UNIXes. We would have to get approval from DEC (or whoever they are) to allow us to add their product into the archive. I did this with V7M and the later Ultrix-11s before DEC got bought out. Warren Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA04900 for pups-liszt; Sun, 6 Dec 1998 01:36:15 +1100 (EST) >From Tim Shoppa <SHOPPA(a)trailing-edge.com> Sun Dec 6 00:33:16 1998 Received: from timaxp.trailing-edge.com (trailing-edge.wdn.com [198.232.144.27]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with SMTP id BAA04895 for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Sun, 6 Dec 1998 01:36:03 +1100 (EST) Received: by timaxp.trailing-edge.com; Sat, 5 Dec 1998 9:33:16 -0500 Date: Sat, 5 Dec 1998 9:33:16 -0500 From: Tim Shoppa <SHOPPA(a)trailing-edge.com> To: msokolov(a)harrier.Uznet.NET CC: PUPS(a)MINNIE.CS.ADFA.OZ.AU Message-Id: <981205093316.2de002c3(a)trailing-edge.com> Subject: Re: System Industries MSCP disk controller problem Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk > I have just tried configuring the board as you have suggested and it >works! Thanks! You have saved the Project! "It has to be simple or I can't do it :-)". In this case (like just about all), it's a matter of getting rid of unknowns. > When I tried starting WOMBAT, it also worked. However, there are tons of >configuration parameters you can set there. Oh yeah - the Webster controllers are wonderfully configurable. It's incredibly useful, as one physical disk can be partitioned up many ways into "virtual" MSCP units - especially useful for OS's which don't deal well with large units (or when it's desirable to have many different versions of many different OS's on the same disk.) >Do you have a full manual for this controller? Would you mind sending me a >xerox copy? Sure, for the cost of copying and postage. Or I'd trade you for some surplus of yours. > What about VAXen? Can you still call 1-800-DIGITAL with a _BIG_ credit >card in hand and order a VAX? Yep - high end 3100 and 4000 units are still available. (It looks like someone has already pointed you towards the Emulex QD21 and QT13 docs available around the net.) > And while we are at it, I have a question about 9-track tape transports >and controllers in general. I often hear about something called Pertec. >What is it? Is it some kind of standard interface that nearly all tape >transports use? Nearly all non-SCSI, non-proprietary interface tape drives will have either (or both) Pertec formatted and Pertec unformatted interfaces. Pertec unformatted drives have three cables; one carries read data, another carries write data, and the third carries control signals. It's a rather low-level interface - the controller tells the drive to go forward, then reads or writes data, with the controller responsible for all the timing. The controller gets to do the nitty-gritty work of repositioning and spacing forward and backward over tape marks. Pertec formatted drives have two 50-pin cables. It's a higher-level interface, where the "formatter" does a lot of the nitty-gritty work, and the controller in the backplane just has to spew out data bytes (or take them in). Many times you'll see a Pertec unformatted drive with a formatter bolted onto it with two 50-pin cables coming out. (In most cases, a formatter could control multiple physical drives.) Other times you'll find "embedded formatter" drives, where there is no 3-cable unformatted interface lurking inside. > It is what this QT13 controller is for? (It has 2 50-lead >connectors.) Yep, Pertec formatted. The QT13 is nice because it'll emulate either MU: or MS:-type devices. > I remember at CWRU there was a very neat-looking tape >transport called Cipher. It looked EXACTLY like DEC TS05, suggesting that >it's what the TS05 really is. Yep, a TS05 is a rebadged Cipher F880 (with some slightly-different firmware). > That one also had a two-50-lead-cables >interface as far as I could tell (it was disconnected). It also appeared to >be dual-ported. It probably had 4 50-pin edge connectors, so that multiple drives could be chained on the same Pertec-formatted-bus. (There are terminators at each end of the bus, much like SCSI.) There's provisions for at least 4 formatters per bus, with each formatter potentially running multiple drives. > Does this mean that DEC also used this Pertec interface? Yep. Actually, the DEC TS05/TSV05/TU80 controllers are rebadged Dilog boards (again, with slightly different firmware - for instance a DEC TU80 controller will only work with TU80 drives or their CDC equivalent, the Keystone.) >Then why are there different DEC controllers for different DEC 9-track tape >transports (TSV05 for TS05, KLESI for TU81+, etc.)? If they were all Pertec >one controller would fit all, wouldn't it? Or is that some DEC 9-track tape >hardware uses Pertec and other DEC hardware doesn't? At the guts of most DEC tape drives, you will often find either a Pertec formatted or unformatted interface. TU80's and TS(V)05's are simple Pertec formatted interfaces. Other times they convert to some other interface (Massbus, LESI, etc.) before the cables come out to the "real world". > Moving on to the next and last unidentified flying board. This one is a >total mystery. The board is labeled "SIGMA INFORMATION SYSTEMS, INC." and >"ASSY NO 400135 REV A". There are NO microprocessors, ROMs, or any other >LSI chips on the board, only SSI/MSI chips, resistors, and capacitors. It's >a dual-height board. It has 3 8-switch packs. There is one 40-lead shrouded >header connector on the board, and a straight 40-lead ribbon cable connects >it to a bulkhead which has a female 37-lead D-sub connector on the outside. >Any ideas on what in the world is this? Any chance it's a simple parallel I/O? Could also be the bus interface for a Sigma and/or DSD MFM drive controller (if so, it probably emulates RL02's). The assembly number sounds vaguely DSD-like. -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA04942 for pups-liszt; Sun, 6 Dec 1998 01:44:43 +1100 (EST) >From Tim Shoppa <SHOPPA(a)trailing-edge.com> Sun Dec 6 00:42:42 1998 Received: from timaxp.trailing-edge.com (trailing-edge.wdn.com [198.232.144.27]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with SMTP id BAA04937 for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Sun, 6 Dec 1998 01:44:33 +1100 (EST) Received: by timaxp.trailing-edge.com for PUPS(a)MINNIE.CS.ADFA.OZ.AU; Sat, 5 Dec 1998 9:42:42 -0500 Date: Sat, 5 Dec 1998 9:42:42 -0500 From: Tim Shoppa <SHOPPA(a)trailing-edge.com> To: PUPS(a)MINNIE.CS.ADFA.OZ.AU Message-Id: <981205094242.2de002c3(a)trailing-edge.com> Subject: Re: Some nice progress with hardware and Ultrix in the PUPS archive Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk > As I was thinking about how else can I get correctly written Ultrix >tapes, the following idea sneaked into my mind. The PUPS archive already >contains PDP-11 Ultrix. How about VAX Ultrix? As Warren pointed out, there might be a problem with putting such tapes on the PUPS archive. I'd be glad to run off TK50's from images for you, though I think your earlier idea, about installing from the miniroot image that's commonly put on 4.2- and 4.3BSD derived distributions, is a *far* better idea as it avoids using a TK50 tape drive at all. It's not that tape copies are bad ideas - it's just that TK50's are so slow. If you were coming from 9-track or DLT or something fast, that wouldn't be so bad. If you can get just about any OS running on your Q-bus machine, under any CPU - i.e. NetBSD, RT-11, 2.11BSD, RSX, whatever you might have - then you can just write the miniroot straight to a "scratch" disk. You can also write the root dump and tar savesets straight to another scratch disk, in "raw" format, if you desire. -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927

26 years, 2 months

Re: System Industries MSCP disk controller problem

by Michael Sokolov

Dear Tim, I have just tried configuring the board as you have suggested and it works! Thanks! You have saved the Project! When I tried starting WOMBAT, it also worked. However, there are tons of configuration parameters you can set there. All 4 disks connected to this controller are already configured and formatted, so for now I'd just leave it alone and install Ultrix on these disks as they are. For the future, however, I would really appreciate being able to configure all that stuff. Do you have a full manual for this controller? Would you mind sending me a xerox copy? > What else are commercial developers left to do now that > DEC (after over a decade of trying to) has finally abandoned their > PDP-11 product line? What about VAXen? Can you still call 1-800-DIGITAL with a _BIG_ credit card in hand and order a VAX? > You might be a bit hasty in casting these off, as you aren't having > the best of luck with the rest of the peripherals, either! Well, now that the WQESD works and while I'm waiting for the TQK50 (one very friendly PUPS member is providing me with a working one), I can turn my attention to these two. Let's start with the 2-drive ESDI one. The Emulex logo and copyright appear in a lot of places, so there is no problem with identification. The board is labeled "ASSY QD2110402 REV G", and just like every other Emulex board I have ever seen, it has a 40-pin chip with an Emulex SUB-ASSY sticker. In this case it's "QD2110202-00G". Do you know anything about this board? It has two switch packs, one of 4 and one of 8. What are the switch settings? Now let's turn to the 9-track tape controller. Again there is no problem with identification (straight Emulex). The board is labeled "ASSY QT1310401-00 REV E" and the 40-pin chip is labeled "QT1310201-02 REV K". Again it has one 4-switch pack and one 8-switch pack. There is something seriously wrong with this board, since when it's present in the backplane the CPU refuses to power up. It stalls at that infamous 9 very early in the power-up sequence, before any console tests or displays, suggesting that something is HORRIBLY wrong with Q-bus (maybe a short or something?). And while we are at it, I have a question about 9-track tape transports and controllers in general. I often hear about something called Pertec. What is it? Is it some kind of standard interface that nearly all tape transports use? It is what this QT13 controller is for? (It has 2 50-lead connectors.) I remember at CWRU there was a very neat-looking tape transport called Cipher. It looked EXACTLY like DEC TS05, suggesting that it's what the TS05 really is. That one also had a two-50-lead-cables interface as far as I could tell (it was disconnected). It also appeared to be dual-ported. Does this mean that DEC also used this Pertec interface? Then why are there different DEC controllers for different DEC 9-track tape transports (TSV05 for TS05, KLESI for TU81+, etc.)? If they were all Pertec one controller would fit all, wouldn't it? Or is that some DEC 9-track tape hardware uses Pertec and other DEC hardware doesn't? Moving on to the next and last unidentified flying board. This one is a total mystery. The board is labeled "SIGMA INFORMATION SYSTEMS, INC." and "ASSY NO 400135 REV A". There are NO microprocessors, ROMs, or any other LSI chips on the board, only SSI/MSI chips, resistors, and capacitors. It's a dual-height board. It has 3 8-switch packs. There is one 40-lead shrouded header connector on the board, and a straight 40-lead ribbon cable connects it to a bulkhead which has a female 37-lead D-sub connector on the outside. Any ideas on what in the world is this? > I'm willing to bet that you have severe Q-bus continuity problems, > especially now that you've told us that you have an expansion Q-bus > cabinet and that you've been randomly moving Q-bus cards around. I am perfectly aware of the fact that Q-bus requires grant continuity and, no, I was NOT moving cards around "randomly". I have them in the order DEC recommends in all of its manuals. There is no problem with the expansion backplane either, the WQESD is quite happy sitting there right now. > Is the "BA23" indeed a real DEC BA23, and not the Sigma "clone"? A real DEC one, of course. While I have never been a DEC engineer or anything like that, I have certainly seen and used enough BA23s to tell one from a third-party box. The expansion backplane is Sigma, though. > The sigma 5.25" 9-slot backplanes have very different backplane > wirings (and, indeed, putting a DEC dual-wide Microvax CPU into > it will very likely cause damage.) Yes, I know. The yellow sticker on the expansion backplane says: "CAUTION! Do not install MicroVAX or KDJ11-B series CPUs into this backplane." Sincerely, Michael Sokolov Cellular phone: 216-217-2579 ARPA Internet SMTP mail: msokolov(a)harrier.Uznet.NET Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id IAA27264 for pups-liszt; Fri, 4 Dec 1998 08:36:51 +1100 (EST) >From "David C. Jenner" <djenner(a)halcyon.com> Fri Dec 4 07:35:51 1998 Received: from mgate.nwnexus.com (mgate.nwnexus.com [206.63.63.200]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id IAA27258 for <pups(a)minnie.cs.adfa.edu.au>; Fri, 4 Dec 1998 08:36:42 +1100 (EST) Received: from halcyon.com (66-a-usw.rb1.blv.nwnexus.net [206.63.251.66]) by mgate.nwnexus.com (8.8.8/8.8.8) with ESMTP id NAA25750 for <pups(a)minnie.cs.adfa.edu.au>; Thu, 3 Dec 1998 13:36:22 -0800 Message-ID: <36670437.966A4527(a)halcyon.com> Date: Thu, 03 Dec 1998 13:35:51 -0800 From: "David C. Jenner" <djenner(a)halcyon.com> Reply-To: djenner(a)halcyon.com X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: PDP-11 Unix Preservation Society <pups(a)minnie.cs.adfa.edu.au> Subject: Re: System Industries MSCP disk controller problem References: <199812032008.BAA08080(a)harrier.Uznet.NET> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk > > The sigma 5.25" 9-slot backplanes have very different backplane > > wirings (and, indeed, putting a DEC dual-wide Microvax CPU into > > it will very likely cause damage.) > > Yes, I know. The yellow sticker on the expansion backplane says: > "CAUTION! Do not install MicroVAX or KDJ11-B series CPUs into this > backplane." I have a box with one of these. I noticed the bussing appeared to be non-standard, but exactly what is the problem here? I also have a couple of Netcom HV1148 backplanes that appear to be non-standard. Any experience with these? What can you do with these backplane? What sort of Q-Bus system can you use them in? Thanks, Dave Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA28393 for pups-liszt; Fri, 4 Dec 1998 12:45:17 +1100 (EST) >From Michael Sokolov <msokolov(a)harrier.Uznet.NET> Fri Dec 4 11:44:38 1998 Received: from harrier.Uznet.NET (harrier.ml.org [193.220.92.194]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id MAA28387 for <pups(a)minnie.cs.adfa.edu.au>; Fri, 4 Dec 1998 12:45:04 +1100 (EST) Received: from dosdev (pm9-180.dial.qual.net [205.212.2.180]) by harrier.Uznet.NET (8.8.8/8.8.8) with SMTP id GAA08380 for <pups(a)minnie.cs.adfa.edu.au>; Fri, 4 Dec 1998 06:44:46 +0500 Message-Id: <199812040144.GAA08380(a)harrier.Uznet.NET> From: Michael Sokolov <msokolov(a)harrier.Uznet.NET> Date: 4 Dec 1998 01:44:38 GMT To: pups(a)minnie.cs.adfa.edu.au Subject: Emulex QT13 and related questions Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk Dear Tim and other Q-bus gurus, Emanuel Stiebler has pointed me to a message posted to vmsnet.pdp11 by Tim a while ago, and there I have found the info on Emulex QT13. Thanks! Since none of my two non-working TQK50s is currently installed, I have tried configuring the QT13 as the primary TMSCP controller and plugging it in. Guess what, this time it powered up without that ugly 9! Nice! I probably won't do much with it, though, since although I do have a 9-track tape transport here in my apartment, I want to leave it alone for now. It's enormous, by far the biggest piece of equipment here, and I don't feel like playing with it now. Some time later maybe. This exercise does raise a few questions, though. Suppose some time later I decided to use this beast. Suppose I wanted to make this QT13 a secondary TMSCP controller. This and other very similar exercises require knowing the rules for floating CSR and vector assignments. What can I find the complete rules for this? My ancient UNIBUS DZ11 manual only lists the earliest floating devices, no MSCP or DHUs or anything like that. I once had some MicroVAX manual that included a table for "common configurations", but I don't have it any more, plus I'm really looking for the complete rules and not just "common configurations". Any ideas? Of course if I had a KA655 or a KA660 I would just type "CONFIGURE" at the ">>>" prompt, but I only have a plain 650 which doesn't have this luxury. Also looking at the configuration of this QT13 board, I noticed that it was originally configured for trailing edge strobe. Tim's notes indicate that this is for Kennedy 9300 only and that the rest should use leading edge strobe. The tape transport I have here is labeled as CDC KEYSTONE. Is this another name for Kennedy 9300 or a different beast? Does anyone know anything about this transport? Sincerely, Michael Sokolov Cellular phone: 216-217-2579 ARPA Internet SMTP mail: msokolov(a)harrier.Uznet.NET Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id NAA28457 for pups-liszt; Fri, 4 Dec 1998 13:14:10 +1100 (EST) >From Michael Sokolov <msokolov(a)harrier.Uznet.NET> Fri Dec 4 12:13:33 1998 Received: from harrier.Uznet.NET (harrier.ml.org [193.220.92.194]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id NAA28452 for <pups(a)minnie.cs.adfa.edu.au>; Fri, 4 Dec 1998 13:13:57 +1100 (EST) Received: from dosdev (pm11-9.dial.qual.net [205.212.3.9]) by harrier.Uznet.NET (8.8.8/8.8.8) with SMTP id HAA08416 for <pups(a)minnie.cs.adfa.edu.au>; Fri, 4 Dec 1998 07:13:41 +0500 Message-Id: <199812040213.HAA08416(a)harrier.Uznet.NET> From: Michael Sokolov <msokolov(a)harrier.Uznet.NET> Date: 4 Dec 1998 02:13:33 GMT To: pups(a)minnie.cs.adfa.edu.au Subject: Re: System Industries MSCP disk controller problem Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk David C. Jenner <djenner(a)halcyon.com> wrote: > I have a box with one of these. I noticed the bussing appeared to > be non-standard, but exactly what is the problem here? I don't think it's non-standard. It's probably just a different standard. Strictly speaking, there is no such thing as a Q-bus backplane. There are Q/Q, Q/CD, and other types of Q-bus'ish backplanes. Generally, you call something a "Q-bus backplane" if it has Q-bus in rows A and B. Rows C and D may be used for lots of different things. In theory you can have these rows used for something REALLY weird. Allison J. Parent tells me that once upon a time you could get a special version of BA11 where rows C and D were customer-wired, i.e., you could have absolutely anything you want in there. In practice, however, there are only two types of row C&D wiring. On some backplanes you have Q-bus in both A&B and C&D, with the grant continuity going in a serpentine. Some BA11 versions are like this. Such backplanes are called Q/Q. On other backplanes Q-bus goes straight down the A&B rows without ever touching rows C and D. In these backplanes rows C&D are connected in a daisy chain, i.e., the fingers on the solder side of the board in slot 1 connect to the fingers on the component side of the board in slot 2, the fingers on the solder side of the board in slot 2 connect to the fingers on the component side of the board in slot 3, and so on. This way immediately adjacent boards can use rows C&D as a totally private interconnect that has zero effect on or relationship with anything else in the system, just like an over-the-top cable. The best example of this is RLV11, although the most common example is MicroVAX II and III memory. Such backplanes are usually called Q/CD, and the examples are some versions of BA11 and all BA2xx and BA4xx backplanes. Finally, there are mixed backplanes that have several Q/CD slots followed by many Q/Q slots. These are specifically designed for MicroVAXen and other CPUs using rows C&D as a private memory interconnect. These backplanes are BA23 (3 Q/CD slots and 5 Q/Q slots) and BA123 (4 Q/CD slots and 8 Q/Q slots). Getting back to the Sigma backplanes, the inability to put a MicroVAX CPU in there suggests that they are Q/Q. Sincerely, Michael Sokolov Cellular phone: 216-217-2579 ARPA Internet SMTP mail: msokolov(a)harrier.Uznet.NET Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id QAA29379 for pups-liszt; Fri, 4 Dec 1998 16:19:44 +1100 (EST) >From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Fri Dec 4 15:21:40 1998 Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id QAA29374 for <pups(a)minnie.cs.adfa.oz.au>; Fri, 4 Dec 1998 16:19:36 +1100 (EST) Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id QAA03261; Fri, 4 Dec 1998 16:21:40 +1100 (EST) From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Message-Id: <199812040521.QAA03261(a)henry.cs.adfa.oz.au> Subject: Re: New Apout PDP-11 simulator To: grog(a)lemis.com (Greg Lehey) Date: Fri, 4 Dec 1998 16:21:40 +1100 (EST) Cc: pups(a)minnie.cs.adfa.oz.au (Unix Heritage Society) In-Reply-To: <19981204154443.E38307(a)freebie.lemis.com> from Greg Lehey at "Dec 4, 98 03:44:43 pm" Reply-To: wkt(a)cs.adfa.oz.au X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk [greg] Looks good. When are you going to add support for 2.11BSD? :-) [warren] I've just started. Emulating all 150+ syscalls is going to take a while. I'll try to modify the V7 syscall support for 2.11BSD; that should get most simple programs working. After that, one syscall at a time.... [greg] Hmm. I suppose the networking will cause you the most headaches (maybe... maybe, of course, you can pass them through to FreeBSD almost unchanged). Most of the things I use the PDP 11 for are networking (letting people dial in, etc), but I'll certainly try things out as soon as you think it would be worthwhile. I'm thinking sometime early next year for an initial release with just the `V7' syscalls in the 2.11BSD emulation. As you said, many of the syscalls will be a pass-thru, with just args and return values to be mapped. I'll let the list know as I go... Warren Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id VAA00320 for pups-liszt; Fri, 4 Dec 1998 21:32:38 +1100 (EST) >From Michael Sokolov <msokolov(a)harrier.Uznet.NET> Fri Dec 4 20:31:01 1998 Received: from harrier.Uznet.NET (harrier.ml.org [193.220.92.194]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id VAA00315 for <pups(a)minnie.cs.adfa.edu.au>; Fri, 4 Dec 1998 21:32:17 +1100 (EST) Received: from dosdev (pm7-62.dial.qual.net [205.212.2.62]) by harrier.Uznet.NET (8.8.8/8.8.8) with SMTP id PAA09422 for <pups(a)minnie.cs.adfa.edu.au>; Fri, 4 Dec 1998 15:31:28 +0500 Message-Id: <199812041031.PAA09422(a)harrier.Uznet.NET> From: Michael Sokolov <msokolov(a)harrier.Uznet.NET> Date: 4 Dec 1998 10:31:01 GMT To: pups(a)minnie.cs.adfa.edu.au Subject: Some nice progress with hardware and Ultrix in the PUPS archive Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk Dear Ladies and Gentlemen, Emanuel Stiebler has graciously provided me with a reference to a freely downloadable copy of the Emulex QD21 manual. Using that manual, I have got mine configured correctly and ran firmware diagnostics on it. It looks like the Emulex card is OK, but for some reason it isn't seeing the drive attached to it. Probably a defective drive reporting not ready or maybe just a connection problem (the drive is mounted in some very weird way so that I can't even check the connection, let alone see the jumpers or anything). Oh well, I'll figure it out later. Right now i have the WQESD controller configured as the primary one, and it has 4 working 320 MB disks attached to it, so it should be enough for me to build and release 4.3BSD- Quasijarus1. But there is something even more interesting. I got the TK50 to work! Yay! It turned out that one of the TQK50 boards was working after all, it was simply being screwed up by the rest of the system standing on its ears. After I got the VAX to boot from some VMSish tape I have (it boots, asks for date and time, prints something about some "standalone backup" and gives me a "$" prompt, but I'm absolutely NULL in VMS, so this doesn't do me much good), I realized that I couldn't boot from my Ultrix tapes because there is something wrong with the way I wrote them. I wrote them on a TZ30 (half-height native-SCSI TK50 clone) connected to a 386 with an Adaptec 1520A running FreeBSD booted from a floppy (the 386's big ESDI hard disk is filled with DOS stuff only). In fact, when I tried reading that tape back on this very same FreeBSD thing it didn't read! Something is clearly wrong. As I was thinking about how else can I get correctly written Ultrix tapes, the following idea sneaked into my mind. The PUPS archive already contains PDP-11 Ultrix. How about VAX Ultrix? With Warren's permission, I would be more than happy to upload my VAX Ultrix tape images (I have them sitting as files on my DOS disk). Once that is done, would someone volunteer to download them, write them to two TK50 cartridges, and send them to me? TIA for any help. Sincerely, Michael Sokolov Cellular phone: 216-217-2579 ARPA Internet SMTP mail: msokolov(a)harrier.Uznet.NET

26 years, 2 months

New Apout PDP-11 simulator

by Warren Toomey

All, I've just spent the week tidying up my Apout program. This runs PDP-11 user-mode programs (specifically 7th Edition binaries), and translates V7 syscalls to native syscalls. I've tidied the program up and optimised it a bit too. Over the summer break (it's summer down here) I want to add floating-point and start work on emulating 2.11BSD user-mode binaries. The program runs on FreeBSD 2.2.x and 3.0 systems: porting to other 32-bit little-endian Unix systems should be relatively easy. Porting to big-endian systems might be harder :-) I'll have a look at that too. Anyway, an alpha of the new 2.2 version is at: ftp://minnie.cs.adfa.edu.au/pub/PDP-11/Sims/Apout Cheers, Warren Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id PAA24007 for pups-liszt; Thu, 3 Dec 1998 15:51:17 +1100 (EST) >From Michael Sokolov <msokolov(a)harrier.Uznet.NET> Thu Dec 3 14:48:30 1998 Received: from harrier.Uznet.NET (harrier.ml.org [193.220.92.194]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id PAA23997 for <pups(a)minnie.cs.adfa.edu.au>; Thu, 3 Dec 1998 15:50:45 +1100 (EST) Received: from dosdev (pm8-114.dial.qual.net [205.212.2.114]) by harrier.Uznet.NET (8.8.8/8.8.8) with SMTP id JAA06898 for <pups(a)minnie.cs.adfa.edu.au>; Thu, 3 Dec 1998 09:48:58 +0500 Message-Id: <199812030448.JAA06898(a)harrier.Uznet.NET> From: Michael Sokolov <msokolov(a)harrier.Uznet.NET> Date: 3 Dec 1998 04:48:30 GMT To: pups(a)minnie.cs.adfa.edu.au Subject: Re: System Industries MSCP disk controller problem Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk Tim Shoppa <SHOPPA(a)trailing-edge.com> wrote: > This sounds a lot like the Webster WQESD, which was repackaged > and sold by many different folks (Sigma, DSD, Qualogy, American > Digital, etc.) Quite possible, since this funny Xerox system has a lot of Sigma components. The outer box in which the BA23 is mounted is made by Sigma, the funny way the ESDI drives are mechanically mounted is clearly a Sigma invention, the card connecting the BA23 backplane to the expansion backplane in the outer Sigma box is made by Sigma, and so is another totally unmarked card of unknown purpose (its presence or absence appears to have absolutely no effect on anything). The system is not 100% Sigma, though. There also another 2-drive ESDI controller (that's the one that was at 172150 from the beginning) and a 9-track tape controller, both made by Emulex (QD21 and QT13, respectively) and both appear toast (I want to get rid of both). > If it is a repackaged WQESD, SW9 on the 10-switch pack was originally > on, with SW10 and SW5-8 off, to put the CSR at 160334. > To set it to be 172150, you put SW10 on, and SW5-9 off. Before I got your E-mail, SW5 and SW8 were ON and the rest were OFF (don't remember if it was the original position). I also tried SW10 ON and the rest OFF. In both cases the effect is exactly the same. At power-up the CPU screams, but then gives the ">>>" prompt. Trying to read different locations with the E/P/W command (the Q-bus I/O page is mapped at 0x20000000 in the VAX address space), I see that the card responds somehow to 160334 and to 160400, but not to 172150. (I know that it's this card and not something else, since when I pull it out the CPU is happy and no one responds to these addresses.) > Then again, it might not be a repackaged WQESD, but instead a Dilog > or Emulex. I'm 99% sure that it's neither Dilog nor Emulex. I have seen quite a few Dilog and Emulex cards, and I think I should be able to detect them easily. > Is there a 10-pin header on the card edge? Can you describe the > positions and types of "big chips" on the board? This is a quad-height board. All components are thru-hole and all chips are in DIP packages. There are no 4-sided chips or surface-mounted components. Hold it with the component side up, the fingers to the right and the handles to the left. On the left (handle) side there is a row of shrouded header connectors. From top to bottom, they are: 10-pin (connected to something, but purpose unknown), 34-pin (ESDI control and status), 20- pin (drive 0 data), 20-pin (drive 1 data), 20-pin (drive 2 data). Directly behind the bottom 20-pin header there is another 20-pin header for drive 3 data. The biggest chip is a 48-pin DIP labeled DP8466AN (National Semiconductor as far as I can tell), and it's right behind the drive 3 data connector. There are two AM2901CPCs behind the 34-pin connector. There is one 28-pin EPROM right about in the center, shifted downward a little. The ROM size is obscured by the sticker saying "ESDI V2.41 9901-8918 REV.A". There is a stack of narrow 24-pin DIP chips going from the top of the board to right above the EPROM. All have stickers, suggesting that they are programmable. The stickers have different 6-character codes on them, all starting with "1583". Directly to the right from the last one there is one more such chip labeled "SYS IND 1583W3". Actually, I was wrong about there being 2 switch packs. There are 3 of them, one of 10 and two of 4. The 10-switch one is right above the chip labeled "SYS IND 1583W3". In the top right corner (right next to row A fingers) there is a 4-switch pack. All switches are ON. Directly behind it there is a 16-pin DIP chip labeled "1583I1" (the only chip with a sticker not mentioned before). At the top of the board directly to the left from the 10-chip stack there is a 10 MHz oscillator, the only clock on the board. Directly to the left from it there is the last 4-switch pack. All switches are ON. Finally, there are 3 LEDs between the top handle and the 10-pin header. The top one is red and the other two are green. > Some > other switches also set the interrupt priority, and this being > off can also confuse some tests and OS's. What's the correct priority for disk MSCP? Should it be different between primary and secondary? > As to your power-on self-test woes, you're going to have to tell > us what's in the system and what slot it lives in, as well as what > sort of backplane it's all in. The outer box is Sigma. It provides funny mounting for 4 ESDI drives, an expansion Q-bus backplane, and a big bay for a BA23. The BA23 contains the CPU, the memory, and all peripherals except the controller in question. First comes the KA650 CPU. Then two MS650 memory modules. Then DELQA, DZQ11, TQK50, and the Sigma Q-bus extender card. The latter takes the Q-bus into the expansion backplane, where the controller in question is the only device. It's in the expansion backplane instead of the BA23 because that's where the actual drives are. I have tried pulling the Sigma Q-bus extender card out and putting the ESDI controller right in the BA23 backplane, but this didn't change anything, so there is nothing wrong with the Q-bus expansion. You know what, I just looked a little closer and noticed that in this configuration (both 4-switch packs all ON, SW1-9 on the 10-switch pack OFF, and SW10 ON) the controller responds not only to 160334 and 160400, but to just about any address in the Q-bus I/O page (except 172150)! No wonder the CPU screams about it! What the hell is going on? How can it possibly do this? Is someone trying to port Plug-n-Pray to Q-bus? Is it something like KFQSA with a separate address for each drive and everything soft- configured? Sincerely, Michael Sokolov Cellular phone: 216-217-2579 ARPA Internet SMTP mail: msokolov(a)harrier.Uznet.NET Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id BAA25817 for pups-liszt; Fri, 4 Dec 1998 01:27:17 +1100 (EST) >From Tim Shoppa <SHOPPA(a)trailing-edge.com> Fri Dec 4 00:25:04 1998 Received: from timaxp.trailing-edge.com (trailing-edge.wdn.com [198.232.144.27]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with SMTP id BAA25812 for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Fri, 4 Dec 1998 01:27:04 +1100 (EST) Received: by timaxp.trailing-edge.com for PUPS(a)MINNIE.CS.ADFA.OZ.AU; Thu, 3 Dec 1998 9:25:04 -0500 Date: Thu, 3 Dec 1998 9:25:04 -0500 From: Tim Shoppa <SHOPPA(a)trailing-edge.com> To: PUPS(a)MINNIE.CS.ADFA.OZ.AU CC: SHOPPA(a)trailing-edge.com Message-Id: <981203092504.2de002c1(a)trailing-edge.com> Subject: Re: System Industries MSCP disk controller problem Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk >> This sounds a lot like the Webster WQESD, which was repackaged >> and sold by many different folks (Sigma, DSD, Qualogy, American >> Digital, etc.) > Quite possible, since this funny Xerox system has a lot of Sigma >components. I regularly work with "PDP-11 systems" now that don't have a single DEC component in them. CPU by Mentec ( http://www.mentec.com/ ), disk controller by Andromeda ( http://www.andromedasystems.com/ ), async and parallel I/O by the Logical Company ( http://www.logical-co.com ), etc. What else are commercial developers left to do now that DEC (after over a decade of trying to) has finally abandoned their PDP-11 product line? At least the other companies named are still doing active support and (at least in Mentec's case) development! > The outer box in which the BA23 is mounted is made by Sigma, >... >though. There also another 2-drive ESDI controller (that's the one that was >at 172150 from the beginning) and a 9-track tape controller, both made by >Emulex (QD21 and QT13, respectively) and both appear toast (I want to get >rid of both). You might be a bit hasty in casting these off, as you aren't having the best of luck with the rest of the peripherals, either! >> If it is a repackaged WQESD, SW9 on the 10-switch pack was originally >> on, with SW10 and SW5-8 off, to put the CSR at 160334. >> To set it to be 172150, you put SW10 on, and SW5-9 off. > Before I got your E-mail, SW5 and SW8 were ON and the rest were OFF >(don't remember if it was the original position). I also tried SW10 ON and >the rest OFF. In both cases the effect is exactly the same. At power-up the >CPU screams, but then gives the ">>>" prompt. Trying to read different >locations with the E/P/W command (the Q-bus I/O page is mapped at >0x20000000 in the VAX address space), I see that the card responds somehow >to 160334 and to 160400, but not to 172150. (I know that it's this card and >not something else, since when I pull it out the CPU is happy and no one >responds to these addresses.) >> Is there a 10-pin header on the card edge? Can you describe the >> positions and types of "big chips" on the board? > This is a quad-height board. All components are thru-hole and all chips >are in DIP packages. There are no 4-sided chips or surface-mounted >components. Hold it with the component side up, the fingers to the right >and the handles to the left. On the left (handle) side there is a row of >shrouded header connectors. From top to bottom, they are: 10-pin (connected >to something, but purpose unknown), 34-pin (ESDI control and status), 20- >pin (drive 0 data), 20-pin (drive 1 data), 20-pin (drive 2 data). Directly >behind the bottom 20-pin header there is another 20-pin header for drive 3 >data. The biggest chip is a 48-pin DIP labeled DP8466AN (National >Semiconductor as far as I can tell), and it's right behind the drive 3 data >connector. There are two AM2901CPCs behind the 34-pin connector. There is >one 28-pin EPROM right about in the center, shifted downward a little. The >ROM size is obscured by the sticker saying "ESDI V2.41 9901-8918 REV.A". That clinches it - it's a Webster WQESD, running Wombat V2.41. 9901-8918 is evidently the SI part number for the complete system. It's a bit confusing to go from the SI part number because they all begin with "9900" or "9901"! > What's the correct priority for disk MSCP? Should it be different >between primary and secondary? A summary of the WQESD switch settings, and the various ways in which you can invoke Wombat, lives at: ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-11/hardware as the file "WQESD.txt". >> As to your power-on self-test woes, you're going to have to tell >> us what's in the system and what slot it lives in, as well as what >> sort of backplane it's all in. > The outer box is Sigma. It provides funny mounting for 4 ESDI drives, an >expansion Q-bus backplane, and a big bay for a BA23. The BA23 contains the >CPU, the memory, and all peripherals except the controller in question. >First comes the KA650 CPU. Then two MS650 memory modules. Then DELQA, >DZQ11, TQK50, and the Sigma Q-bus extender card. The latter takes the Q-bus >into the expansion backplane, where the controller in question is the only >device. It's in the expansion backplane instead of the BA23 because that's >where the actual drives are. I have tried pulling the Sigma Q-bus extender >card out and putting the ESDI controller right in the BA23 backplane, but >this didn't change anything, so there is nothing wrong with the Q-bus >expansion. I'm willing to bet that you have severe Q-bus continuity problems, especially now that you've told us that you have an expansion Q-bus cabinet and that you've been randomly moving Q-bus cards around. You have to tell us exactly which slot each card is in, and preferably the original configuration as well (the Sigma backplanes have different wirings than the common DEC ones.) Is the "BA23" indeed a real DEC BA23, and not the Sigma "clone"? The sigma 5.25" 9-slot backplanes have very different backplane wirings (and, indeed, putting a DEC dual-wide Microvax CPU into it will very likely cause damage.) As a start, work just with the BA23. Put the CPU in slot 1, with the two memory boards in slots 2 and 3. Put the WQESD in slot 4. Have nothing else plugged in at all - especially not the boards that jumper the two backplanes together. Set the DIPswitches on the WQESD as follows: 10-switch pack: Switches 1-2 off, 3 on, 4-9 off, 10 on. 4-switch pack near the edge connector: 1-3 on, 4 off. 4-switch pack near the handles: 1-4 on. Then try to start up wombat with the following sequence of console commands: Microvax II: Halt the processor U I D/P/W 20001F40 20 D/L 20088008 80000002 D/W 20001468 AC S 400 If this doesn't start Wombat, tell us *exactly* what the error message produced is. -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927

26 years, 2 months

System Industries MSCP disk controller problem

by mxs46＠k2.scl.cwru.edu

Dear Ladies and Gentlemen, I wonder, is anyone here familiar with System Industries (SI) Q-bus MSCP controllers for ESDI disks? The VAX I'm working has one. It's quad-height board with connectors for 4 ESDI drives. I couldn't find a model number or anything like that, but there is a sticker on one of the chips that says "SYS IND" on it (that's how I deduced that it's SI). The problem I'm having is that I have no idea how to configure it. It has two DIP switch packs, one with 4 switches and one with 10. Originally it was configured to be the secondary disk MSCP controller at 160334. I want it to be the primary one at 172150. I tried every reasonable switch combination I could think of, but no luck. What's even worse is that I can't leave it as secondary either. For some reason its configuration makes the CPU (KA650) unhappy. When I pull it out, the CPU passes all power-up tests beautifully. When I put it in, I still get to the ">>>" prompt eventually, but first I get a load of error messages from the self-tests. Then when I try to boot from DUB0, it tells me "DEVASSIGN", suggesting that it doesn't recognize the second disk MSCP controller at all. All docs I have suggest that 160334 is the correct address for secondary disk MSCP. It's in the floating address range, though, so I suspected that it's the side effect of adding or removing other cards. I tried making the configuration as close to the original as I could. No luck still. The only card I had to pull out is the secondary TMSCP (Emulex QT13 9-track tape controller), because it appears totally toast (the CPU refuses to power up with that infamous 9 when this card is present). But then secondary TMSCP should be AFTER secondary disk MSCP in the floating address space, right? I tried some more investigation and by pure accident I discovered that the SI controller also responds somehow to 160400. What the hell is that address for? Could this be what makes the CPU unhappy? Does anyone have any clues? Is anyone here familiar with SI MSCP disk controllers? TIA for any help. Sincerely, Michael Sokolov Cellular phone: 216-217-2579 ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id OAA12137 for pups-liszt; Tue, 1 Dec 1998 14:27:04 +1100 (EST) >From Tim Shoppa <SHOPPA(a)trailing-edge.com> Tue Dec 1 13:24:21 1998 Received: from timaxp.trailing-edge.com (trailing-edge.wdn.com [198.232.144.27]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with SMTP id OAA12127 for <PUPS(a)MINNIE.CS.adfa.edu.AU>; Tue, 1 Dec 1998 14:26:35 +1100 (EST) Received: by timaxp.trailing-edge.com for PUPS(a)MINNIE.CS.adfa.edu.AU; Mon, 30 Nov 1998 22:24:21 -0500 Date: Mon, 30 Nov 1998 22:24:21 -0500 From: Tim Shoppa <SHOPPA(a)trailing-edge.com> To: PUPS(a)minnie.cs.adfa.edu.au Message-Id: <981130222421.2de00129(a)trailing-edge.com> Subject: Re: System Industries MSCP disk controller problem Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk > I wonder, is anyone here familiar with System Industries (SI) Q-bus MSCP >controllers for ESDI disks? The VAX I'm working has one. It's quad-height >board with connectors for 4 ESDI drives. I couldn't find a model number or >anything like that, but there is a sticker on one of the chips that says >"SYS IND" on it (that's how I deduced that it's SI). The problem I'm having >is that I have no idea how to configure it. It has two DIP switch packs, >one with 4 switches and one with 10. Originally it was configured to be the >secondary disk MSCP controller at 160334. I want it to be the primary one >at 172150. I tried every reasonable switch combination I could think of, >but no luck. This sounds a lot like the Webster WQESD, which was repackaged and sold by many different folks (Sigma, DSD, Qualogy, American Digital, etc.) If it is a repackaged WQESD, SW9 on the 10-switch pack was originally on, with SW10 and SW5-8 off, to put the CSR at 160334. To set it to be 172150, you put SW10 on, and SW5-9 off. Then again, it might not be a repackaged WQESD, but instead a Dilog or Emulex. Is there a 10-pin header on the card edge? Can you describe the positions and types of "big chips" on the board? >pure accident I discovered that the SI controller also responds somehow to >160400. What the hell is that address for? Could this be what makes the CPU >unhappy? It might be because you've enabled the on-board PDP-11 bootstrap, a very big no-no when used in a Microax system. (This bootstrap effectively tries to jam code by DMA into main memory, and can wreak all sorts of havoc on a Microvax.) Some other switches also set the interrupt priority, and this being off can also confuse some tests and OS's. As to your power-on self-test woes, you're going to have to tell us what's in the system and what slot it lives in, as well as what sort of backplane it's all in. Incidentally, I happen to use a Webster WQESD in my 4.3BSD-Reno machine, and am very happy with it there. -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927

26 years, 2 months

2.9BSD/DZ-11 clone screw

by Daniel A. Seagraves

I got my hands on a Aviv DZ-11 clone. 16-line MUX. So, I go about shoving it in the 83. It boots 2.9BSD off a RL02. Shove device in, set CSR and interrupt vector, and fire up BSD. I screwed with the dtab line - With it using dzdma in place of dzou, I can't make the MUX go. The kernel attaches it, but I can't seem to be able to talk to it. So, I switched to dzou. Now, upon boot, I get the message: dz 0 csr 160100 vector 320 no address found for dzou SERIOUS CONFIGURATION ERROR^G^G^G I've tried other vectors and other bus slots, and get no improvements with either method (dzdma or dzou). Any ideas? (Oh, and if you've got another SDZV11, the DIP switches are BACKWARDS of their labels! 1=0 and 0=1. Cute, eh?) I also have a DHV11, but no idea how to tell BSD it's there. All I ever get from it is dh ? csr 160020 vector 370 didn't interrupt I think I need to set the DM address, but have no idea what to set it to. ------- Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id MAA28694 for pups-liszt; Sat, 28 Nov 1998 12:11:23 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.edu.au) >From "Steven M. Schultz" <sms(a)moe.2bsd.com> Sat Nov 28 10:56:52 1998 Received: from moe.2bsd.com (0(a)MOE.2BSD.COM [206.139.202.200]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id MAA28689 for <pups(a)minnie.cs.adfa.oz.au>; Sat, 28 Nov 1998 12:11:09 +1100 (EST) (envelope-from sms(a)moe.2bsd.com) Received: (from sms@localhost) by moe.2bsd.com (8.9.0/8.9.0) id QAA23331 for pups(a)minnie.cs.adfa.oz.au; Fri, 27 Nov 1998 16:56:52 -0800 (PST) Date: Fri, 27 Nov 1998 16:56:52 -0800 (PST) From: "Steven M. Schultz" <sms(a)moe.2bsd.com> Message-Id: <199811280056.QAA23331(a)moe.2bsd.com> To: pups(a)minnie.cs.adfa.oz.au Subject: Re: 2.9BSD/DZ-11 clone screw Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk > From: "Daniel A. Seagraves" <DSEAGRAV(a)toad.xkl.com> > > I got my hands on a Aviv DZ-11 clone. 16-line MUX. So, I go about... > shoving it in the 83. It boots 2.9BSD off a RL02. Shove device in, > I screwed with the dtab line - With it using dzdma in place of dzou, I can't > make the MUX go. The kernel attaches it, but I can't seem to be able to talk > to it. So, I switched to dzou. Now, upon boot, I get the message: How are you trying to talk to it? If the line is marked as "modem controlled" you will see/hear nothing until there is 'CD' (carrier detect) present. Typically the /dev nodes are "modem controlled" unless you add 0200 (128 dec) to the minor device number. For 2.9 the major device number of the DZ is 21 so /dev/tty00 would be "mknod /dev/tty00 c 21 0" and expect modemcontrol while "mknod /dev/tty00 c 21 128" would be a "hardwired" line w/o modem control. > dz 0 csr 160100 vector 320 no address found for dzou > SERIOUS CONFIGURATION ERROR^G^G^G That's not surprising since there is no such symbol in the DZ driver ;) 'dzdma' is a replacement for the transmit interrupt routine - the xmit interrupt goes to 'dzdma' (IF 'DZ_DMA' is enabled in the kernel config file). 'dzdma' calls 'dzxint' at the end of dzdma's processing. Thus if you change 'dzdma' to anything it should be to 1) a symbol which exists <grin> and 2) 'dzxint'. I think something bad happens if DZ_DMA is enabled but dzxint is called directly - it probably won't work since there are two different 'dzxint' routines (one for use with dzdma and one without and the args are different). So if the symbol 'dzdma' is present in the kernel you probably want to least the "xmit field" in /etc/dtab as 'dzdma'. If 'dzdma' is not present in the kernel then use 'dzxint'. > I've tried other vectors and other bus slots, and get no improvements > with either method (dzdma or dzou). Any ideas? Try remaking the device nodes to indicate no modem control. Or perhaps create a cable that asserts the necessary signals. > I also have a DHV11, but no idea how to tell BSD it's there. > All I ever get from it is > dh ? csr 160020 vector 370 didn't interrupt Quite so. The original 2.9BSD didn't support the DHV or DHU devices. Later on there were drivers created but the original distributions lack (according to the CSRG archive CDs) 'dhv' and 'dhu' support. The closest 2.9 came was the venerable DH/DM. 2.11BSD does have DHV support but the silo handling of those devices is *terrible*. If you have any choice in the matter at all get a DHQ-11 and set it for 'DHU' mode. The DHQ can run in DHV or DHU modes with the latter being far preferable (its behaviour is that of the older DH-11 with regard to silo alarm level selectability). > I think I need to set the DM address, but have no idea what to set it to. Not for a DHV. An older DH/DM you would have needed to but that is one of the differences (and why the DHV isn't compatible with the DH driver) is how modem signals are handled. On a 2.11BSD system there is a single line: dhv ? 160440 310 5 dhvrint dhvxint # dhv terminal mux for the DHV-11. Where the CSR/Vector were set to whatever didn't conflict with something else. Good Luck. Steven Schultz sms(a)moe.2bsd.com

26 years, 2 months

List of licensees

by Warren Toomey

In article by Kelwin Wylie: > I am curious to see who else has a source code license. > I imagine there might be privacy concerns, but if there isn't, > I would like to see the list. > Kelwin I can't see any harm, and it's good to know who you can share stuff with. Here are the names I have. There are obviously more people/organisations with licenses. Warren James A. Capp Greg Lehey Ali Bahrami Oleg Levanidov Pat Barron Yi Li Harald Barth Andrew Lynch Craig Bevans Douglas M. Wells Joseph Bickel James MacKeivitch Stefan Bieschewski Keizo Maeda Robin Birch Masahiro Matsumoto Hartmut Brandt Doug McIntyre Matthias Bruestle Kristen McIntyre W. C. Bulte Kirk McKusick Jozc Capkyn Giegrich Michael Brian Chase Shuji Mochida Atindra Chaturvedi Andreas Muller Peter Chubb Dieter Muller Efton Collins Joseph Myers Peter Collinson Gregory Neil Shapiro Rick Copeland Lyndon Nerenberg Matthew Crosby Peter Nikolaev Zhivkov Donald Cruikshank Ray Nouell Mrian Crzig Lennox Kevin Ogden J. D. Knaebel Joergen Pehrson Carlo Dapor Carl Phillips Eric Delgado Paul Pierce Erick Delios James R. Willing Barry Dobyns Charles Retter John Dodson Bruce Robertson Anthony Duell Chang Sang-Thong Alexander Duerrschnabel Michael Schmitz Kevin Dunlap Steven Schultz Hendrik Dykstra Daniel Seagraves Charles E Owen Michael Shalayeff Eric Fischer Gregg Sigfried Gregor Fismer Barry Silverman Robert G. Van Herick Michael Sokolov David Galloway Chris Steinke Glenn Geers Jason Stevens Edmund Goppelt Mark Thompson Brent Graveland Warren Toomey Arno Griffioen Jennine Townsend John Harvard Pete Turnbull Martin Heller Christopher Vance Michael Homsey Paul Vixie Michael J. Haertel Jason Wells Jay Jaeger Ken Wellsch Martin James Crehan Jim Williams David Jenner John Wilson Neil Johnson Norman Wilson Soren Jorvang Kelwin Wylie Moto Kawasaki Thomas Yanuklis Eugene Kim Thomas Zenker Kern Koh Leendert van Doorn Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA23319 for pups-liszt; Fri, 27 Nov 1998 09:26:59 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.edu.au) >From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Fri Nov 27 08:28:31 1998 Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id JAA23313 for <pups(a)minnie.cs.adfa.oz.au>; Fri, 27 Nov 1998 09:26:51 +1100 (EST) (envelope-from wkt(a)henry.cs.adfa.oz.au) Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id JAA13602; Fri, 27 Nov 1998 09:28:31 +1100 (EST) From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Message-Id: <199811262228.JAA13602(a)henry.cs.adfa.oz.au> Subject: Re: Pro/Venix and Y2K To: SHOPPA(a)trailing-edge.com (Tim Shoppa) Date: Fri, 27 Nov 1998 09:28:31 +1100 (EST) Cc: pups(a)minnie.cs.adfa.oz.au (Unix Heritage Society) In-Reply-To: <981126115034.2a2004dc(a)trailing-edge.com> from Tim Shoppa at "Nov 26, 98 11:50:34 am" Reply-To: wkt(a)cs.adfa.oz.au X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk In article by Tim Shoppa: > The following exchange recently took place on comp.sys.dec.micro/ > vmsnet.pdp-11/alt.sys.pdp11. In it, I made the guess that PRO Venix > is based on 2.9BSD - does anyone know more details about its heritage? I understand that Venix is a cut-down SysIII in binary-only format. We have SysIII in the archive in source form, if that's of any help. I doubt it will have the device handler for the PRO 380 Time-Of-Year clock. Warren Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id JAA23443 for pups-liszt; Fri, 27 Nov 1998 09:56:13 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.edu.au) >From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Fri Nov 27 08:57:56 1998 Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id JAA23438 for <pups(a)minnie.cs.adfa.oz.au>; Fri, 27 Nov 1998 09:56:07 +1100 (EST) (envelope-from wkt(a)henry.cs.adfa.oz.au) Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id JAA13789; Fri, 27 Nov 1998 09:57:57 +1100 (EST) From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Message-Id: <199811262257.JAA13789(a)henry.cs.adfa.oz.au> Subject: Re: Pro/Venix and Y2K To: grog(a)lemis.com (Greg Lehey) Date: Fri, 27 Nov 1998 09:57:56 +1100 (EST) Cc: pups(a)minnie.cs.adfa.oz.au (Unix Heritage Society) In-Reply-To: <19981127092329.U67961(a)freebie.lemis.com> from Greg Lehey at "Nov 27, 98 09:23:29 am" Reply-To: wkt(a)cs.adfa.oz.au X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk In article by Greg Lehey: > On Friday, 27 November 1998 at 9:28:31 +1100, Warren Toomey wrote: > > I understand that Venix is a cut-down SysIII in binary-only format. We have > > SysIII in the archive in source form, if that's of any help. > > Interesting. How did we get that? Or is it a 16 bit version? > Greg It's a PDP-11 version donated by Kirk. We also have SysV for the PDP-11, donated by John Holden, but I can't put it in the archive because the SCO license specifically doesn't cover SysV. Cheers, Warren Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id KAA23485 for pups-liszt; Fri, 27 Nov 1998 10:02:15 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.edu.au) >From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Fri Nov 27 09:03:50 1998 Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id KAA23480 for <pups(a)minnie.cs.adfa.oz.au>; Fri, 27 Nov 1998 10:02:08 +1100 (EST) (envelope-from wkt(a)henry.cs.adfa.oz.au) Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id KAA13818; Fri, 27 Nov 1998 10:03:50 +1100 (EST) From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Message-Id: <199811262303.KAA13818(a)henry.cs.adfa.oz.au> Subject: Re: List of licensees To: grog(a)lemis.com (Greg Lehey) Date: Fri, 27 Nov 1998 10:03:50 +1100 (EST) Cc: pups(a)minnie.cs.adfa.oz.au (Unix Heritage Society) In-Reply-To: <19981127092818.V67961(a)freebie.lemis.com> from Greg Lehey at "Nov 27, 98 09:28:18 am" Reply-To: wkt(a)cs.adfa.oz.au X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk In article by Greg Lehey: > There seem to be some obvious omissions, such as Dennis and Tim > Shoppa. I also have the feeling that a number of others should be > there, but I can't put a name to them. I can only give the details of the people for whom I actually have license numbers (both SCO, AT&T and Western Electric). If you _are_ covered by a UNIX source license, and would like access to the archive, then please fax your license to me at +61 6268 8581. I only require the pages with the signatures, the license numbers, and the list of UNIX versions covered. Thanks, Warren

26 years, 2 months

Over 100 Ancient UNIX Licenses

by Warren Toomey

All, I've just received another 5 SCO Ancient UNIX license details in the mail, bringing the total purchased from SCO to 101. I think that's pretty impressive. Just thought you'd like to know. Cheers all, Warren Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id DAA22073 for pups-liszt; Fri, 27 Nov 1998 03:52:43 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.edu.au) >From Tim Shoppa <SHOPPA(a)trailing-edge.com> Fri Nov 27 02:50:34 1998 Received: from timaxp.trailing-edge.com (trailing-edge.wdn.com [198.232.144.27]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with SMTP id DAA22068 for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Fri, 27 Nov 1998 03:52:29 +1100 (EST) (envelope-from SHOPPA(a)trailing-edge.com) Received: by timaxp.trailing-edge.com for PUPS(a)MINNIE.CS.ADFA.OZ.AU; Thu, 26 Nov 1998 11:50:34 -0500 Date: Thu, 26 Nov 1998 11:50:34 -0500 From: Tim Shoppa <SHOPPA(a)trailing-edge.com> To: PUPS(a)MINNIE.CS.ADFA.OZ.AU Message-Id: <981126115034.2a2004dc(a)trailing-edge.com> Subject: Pro/Venix and Y2K Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk The following exchange recently took place on comp.sys.dec.micro/ vmsnet.pdp-11/alt.sys.pdp11. In it, I made the guess that PRO Venix is based on 2.9BSD - does anyone know more details about its heritage? Donato B. Masaoy III wrote: > > Came into a Pro 380 and loaded Venix as a means of tyring out Unix. > Noticed that at 2000 it sets itself back to 1970. Is there fix for this? > Should I bother? The PRO 380 Time-Of-Year clock has two modes: 1. BCD mode, where the year is stored in two decimal digits. 2. Binary mode, where the year is stored as at least 7 bits (more likely 8 bits - it's been a couple of months since the changes were implemented the fix in RT-11's PI.SYS, PIX.SYS, and SETUP.SAV to make it Y2K compliant.) When in BCD mode, 31-Dec-99 rolls over into 1-Jan-00, and the clock keeps accurately ticking. Venix evidently chokes on this and doesn't interpret "00" as "2000". As Unix is incapable of representing times internally outside the range 1970-2038, the obvious fix is to interpret BCD years in the range 70-99 as being in the 1900's, and the BCD years in the range 00-38 as in the 2000's. This is, for example, how BSD2.11 interprets the two-digit 11/93 or 11/94 clock year. Of course, finding the sources to Pro 380 Venix to implement the changes may be difficult. The PUPS archive has a version of 2.9BSD patches for the Pro, and if you're lucky Venix may be close enough that you can use the Pro-specific clock sources to patch your kernel binary. In the 2.9BSD Pro patches, the clock code is in "/sys-dev/prostuff.c", and begins: /* These two fuctions handle the pro 300's clock * This code is defunct at the end of the century. * Will Unix still be here then?? */ -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id FAA22435 for pups-liszt; Fri, 27 Nov 1998 05:49:47 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.edu.au) >From "David C. Jenner" <djenner(a)halcyon.com> Fri Nov 27 04:48:45 1998 Received: from mgate.nwnexus.com (mgate.nwnexus.com [206.63.63.200]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id FAA22430 for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Fri, 27 Nov 1998 05:49:37 +1100 (EST) (envelope-from djenner(a)halcyon.com) Received: from halcyon.com (66-a-usw.rb1.blv.nwnexus.net [206.63.251.66]) by mgate.nwnexus.com (8.8.8/8.8.8) with ESMTP id KAA03033; Thu, 26 Nov 1998 10:48:52 -0800 Message-ID: <365DA28D.5C541C8C(a)halcyon.com> Date: Thu, 26 Nov 1998 10:48:45 -0800 From: "David C. Jenner" <djenner(a)halcyon.com> Reply-To: djenner(a)halcyon.com X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Shoppa <SHOPPA(a)trailing-edge.com> CC: PUPS(a)MINNIE.CS.ADFA.OZ.AU Subject: Re: Pro/Venix and Y2K References: <981126115034.2a2004dc(a)trailing-edge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk There probably isn't much BSD lineage in Version 1 of Venix, but there is some in Version 2. Probably mostly in the form of the usual add-ons like VI. There's some confusion about this (at least in my mind), so any authoritative info would be interesting. First of all there's: "Venix/Pro" from Venturecom, which is definitely of AT&T lineage, probably V7/SysIII for V1 of Venix/Pro, and perhaps a bit of BSD stuff mixed in for V2 of Venix/Pro. This is what you find at Internet archives. Then there's: "Pro/Venix" from DEC, which is a repackaging of Venix/Pro. Again, there are Versions 1 and 2 of this. I have V1 and docs for V2, but no disks for V2. I'd really like to find a copy of the distribution of DEC Pro/Venix V2, if it's legal (and having the Ancient Unix license would seem to make it OK for at least the AT&T side). For Pro/Venix, V2, the manual entry for "clock(7) - time-of-day clock" is: /dev/clock refers to a time-of-day, battery-backed-up clock. This device node is provided primarily for the benefit of the date com- mand, which will read from it given the -l flag (usually done on system start-up), and write to it if a new date is set. ... struct clkbuf { int clk_sec; /* second (0-59) */ int clk_min; /* minute (0-59) */ int clk_hour; /* hour (0-23) */ int clk_mday; /* day of month (1-31) */ int clk_mon; /* month (0-11) */ int clk_year; /* year (00-99) */ int clk_wday; /* day of the week (Sunday = 0) */ int clk_yday; /* day of the year (0-365) */ int clk_dst; /* non-zero if daylight savings applies */ }; So, it looks bad at least from the internal representation of the year. Since I don't have this version, I can't comment on exactly what happens. Dave Tim Shoppa wrote: > > The following exchange recently took place on comp.sys.dec.micro/ > vmsnet.pdp-11/alt.sys.pdp11. In it, I made the guess that PRO Venix > is based on 2.9BSD - does anyone know more details about its heritage? > > Donato B. Masaoy III wrote: > > > > Came into a Pro 380 and loaded Venix as a means of tyring out Unix. > > Noticed that at 2000 it sets itself back to 1970. Is there fix for this? > > Should I bother? > > The PRO 380 Time-Of-Year clock has two modes: > > 1. BCD mode, where the year is stored in two decimal digits. > 2. Binary mode, where the year is stored as at least 7 bits (more > likely 8 bits - it's been a couple of months since the changes > were implemented the fix in RT-11's PI.SYS, PIX.SYS, and > SETUP.SAV to make it Y2K compliant.) > > When in BCD mode, 31-Dec-99 rolls over into 1-Jan-00, and the > clock keeps accurately ticking. Venix evidently chokes on this > and doesn't interpret "00" as "2000". > > As Unix is incapable of representing times internally outside > the range 1970-2038, the obvious fix is to interpret BCD years > in the range 70-99 as being in the 1900's, and the BCD years > in the range 00-38 as in the 2000's. This is, for example, > how BSD2.11 interprets the two-digit 11/93 or 11/94 clock year. > > Of course, finding the sources to Pro 380 Venix to implement > the changes may be difficult. The PUPS archive has a version of 2.9BSD > patches for the Pro, and if you're lucky Venix may be close > enough that you can use the Pro-specific clock sources to patch > your kernel binary. In the 2.9BSD Pro patches, the clock > code is in "/sys-dev/prostuff.c", and begins: > > /* These two fuctions handle the pro 300's clock > * This code is defunct at the end of the century. > * Will Unix still be here then?? > */ > > -- > Tim Shoppa Email: shoppa(a)trailing-edge.com > Trailing Edge Technology WWW: http://www.trailing-edge.com/ > 7328 Bradley Blvd Voice: 301-767-5917 > Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA22497 for pups-liszt; Fri, 27 Nov 1998 06:05:10 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.edu.au) >From Ken Wellsch <kcwellsc(a)math.uwaterloo.ca> Fri Nov 27 05:04:36 1998 Received: from math.uwaterloo.ca (kcwellsc(a)math.uwaterloo.ca [129.97.140.144]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id GAA22489 for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Fri, 27 Nov 1998 06:05:00 +1100 (EST) (envelope-from kcwellsc(a)math.uwaterloo.ca) Received: (from kcwellsc@localhost) by math.uwaterloo.ca (8.8.8/8.8.8) id OAA22036; Thu, 26 Nov 1998 14:04:36 -0500 (EST) From: Ken Wellsch <kcwellsc(a)math.uwaterloo.ca> Message-Id: <199811261904.OAA22036(a)math.uwaterloo.ca> Subject: Re: Pro/Venix and Y2K To: SHOPPA(a)trailing-edge.com (Tim Shoppa) Date: Thu, 26 Nov 1998 14:04:36 -0500 (EST) Cc: PUPS(a)MINNIE.CS.ADFA.OZ.AU In-Reply-To: <981126115034.2a2004dc(a)trailing-edge.com> from "Tim Shoppa" at Nov 26, 98 11:50:34 am Organization: University of Waterloo, Math Faculty Computing Facility (Alumni) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk Hi Tim, | The following exchange recently took place on comp.sys.dec.micro/ | vmsnet.pdp-11/alt.sys.pdp11. In it, I made the guess that PRO Venix | is based on 2.9BSD - does anyone know more details about its heritage? There are several folks with vastly better knowledge on this than I, but should they not speak up, I'll mumble on what little I know. Venix is an outgrowth of V6 UNIX I believe - from my fadding memory of the little I played with it, the file system is definitely V6 based (with the notion of "huge" files, i.e. the index pointers would switch from direct to indirect, while I believe V7 took a much better approach). The 2BSD branch I believe took a much later fork, V7 or later? It also played a more central role than Venix I expect, contributing a goodly amount of later PDP-11/UNIX based things that others borrowed (e.g. Ultrix 3 from DEC took csh and vi among other goodies). | As Unix is incapable of representing times internally outside | the range 1970-2038, the obvious fix is to interpret BCD years | in the range 70-99 as being in the 1900's, and the BCD years | in the range 00-38 as in the 2000's. This is, for example, | how BSD2.11 interprets the two-digit 11/93 or 11/94 clock year. Gee, I didn't think there was one "UNIX" in the world 8-) How big are your integers? Do you use signed or unsigned values for the epoch since Jan 1 1970? It seems hard to believe anything in the UNIX world of today has this limitation. I'll agree there is likely just the one "RT-11" though 8-) -- Ken Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA22536 for pups-liszt; Fri, 27 Nov 1998 06:17:19 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.edu.au) >From Tim Shoppa <SHOPPA(a)trailing-edge.com> Fri Nov 27 05:15:17 1998 Received: from timaxp.trailing-edge.com (trailing-edge.wdn.com [198.232.144.27]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with SMTP id GAA22531 for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Fri, 27 Nov 1998 06:17:10 +1100 (EST) (envelope-from SHOPPA(a)trailing-edge.com) Received: by timaxp.trailing-edge.com for PUPS(a)MINNIE.CS.ADFA.OZ.AU; Thu, 26 Nov 1998 14:15:17 -0500 Date: Thu, 26 Nov 1998 14:15:17 -0500 From: Tim Shoppa <SHOPPA(a)trailing-edge.com> To: PUPS(a)MINNIE.CS.ADFA.OZ.AU Message-Id: <981126141517.2a2003cb(a)trailing-edge.com> Subject: Re: Pro/Venix and Y2K Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk >There's some confusion about this (at least in my mind), so any >authoritative info would be interesting. I agree - and would love more definitive information (Or, even better, the sources to Pro/Venix.) I've learned an amazing amount about segments of the Unix lineage just from the comments in the past week, but the gaps in my knowledge still loom large! It's entirely possible that Pro/Venix uses the Pro clock in BCD mode - it looked to me that the 2.9BSD version does it in binary mode. >struct clkbuf { > int clk_sec; /* second (0-59) */ > int clk_min; /* minute (0-59) */ > int clk_hour; /* hour (0-23) */ > int clk_mday; /* day of month (1-31) */ > int clk_mon; /* month (0-11) */ > int clk_year; /* year (00-99) */ > int clk_wday; /* day of the week (Sunday = 0) */ > int clk_yday; /* day of the year (0-365) */ > int clk_dst; /* non-zero if daylight savings applies */ >}; > >So, it looks bad at least from the internal representation of the >year. It depends on what you want to call "bad". It's quite possible to build a Y2K compliant system out of non-Y2K compliant components! 2.11BSD's date(1) was patched for Y2K in such a way that "00" in the two-digit year would be interpreted as the year 2000. (See patch #327 for the details.) Would similar fixes for more historic Unices be useful to the general folk here? -- Tim Shoppa Email: shoppa(a)trailing-edge.com Trailing Edge Technology WWW: http://www.trailing-edge.com/ 7328 Bradley Blvd Voice: 301-767-5917 Bethesda, MD, USA 20817 Fax: 301-767-5927 Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id GAA22638 for pups-liszt; Fri, 27 Nov 1998 06:50:39 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.edu.au) >From "David C. Jenner" <djenner(a)halcyon.com> Fri Nov 27 05:49:47 1998 Received: from mgate.nwnexus.com (mgate.nwnexus.com [206.63.63.200]) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id GAA22633 for <PUPS(a)MINNIE.CS.ADFA.OZ.AU>; Fri, 27 Nov 1998 06:50:31 +1100 (EST) (envelope-from djenner(a)halcyon.com) Received: from halcyon.com (66-a-usw.rb1.blv.nwnexus.net [206.63.251.66]) by mgate.nwnexus.com (8.8.8/8.8.8) with ESMTP id LAA03155; Thu, 26 Nov 1998 11:49:55 -0800 Message-ID: <365DB0DB.CD18A664(a)halcyon.com> Date: Thu, 26 Nov 1998 11:49:47 -0800 From: "David C. Jenner" <djenner(a)halcyon.com> Reply-To: djenner(a)halcyon.com X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tim Shoppa <SHOPPA(a)trailing-edge.com> CC: PUPS(a)MINNIE.CS.ADFA.OZ.AU Subject: Re: Pro/Venix and Y2K References: <981126141517.2a2003cb(a)trailing-edge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pups(a)minnie.cs.adfa.edu.au Precedence: bulk It's "bad" in the sense that the evidence available (empirical, and sparse code) suggests that the software (and probably the hardware) is working with only two-digit years. You could, of course, try to remedy the Y2K problem by properly handling the clock. But the evidence suggests that the problem may be spread over lots of code. As you say, it would be nice to have the Pro/Venix code (as opposed to the Venix/Pro code). DEC's Pro/Venix is more flexible than Venturecom's Venix/Pro. You can write and link custom device drivers with the kernel in Pro/Venix. There is some hope you could actually "fix" /dev/clock, but this probably isn't enough to solve the whole Y2K problem. Again, any knowledge about the whereabouts of even the binary distribution disks of DEC's V2 Pro/Venix would be great. Dave Tim Shoppa wrote: > > >There's some confusion about this (at least in my mind), so any > >authoritative info would be interesting. > > I agree - and would love more definitive information (Or, even > better, the sources to Pro/Venix.) I've > learned an amazing amount about segments of the Unix lineage > just from the comments in the past week, but the gaps in > my knowledge still loom large! > > It's entirely possible that Pro/Venix uses the Pro > clock in BCD mode - it looked to me that the 2.9BSD version > does it in binary mode. > > >struct clkbuf { > > int clk_sec; /* second (0-59) */ > > int clk_min; /* minute (0-59) */ > > int clk_hour; /* hour (0-23) */ > > int clk_mday; /* day of month (1-31) */ > > int clk_mon; /* month (0-11) */ > > int clk_year; /* year (00-99) */ > > int clk_wday; /* day of the week (Sunday = 0) */ > > int clk_yday; /* day of the year (0-365) */ > > int clk_dst; /* non-zero if daylight savings applies */ > >}; > > > >So, it looks bad at least from the internal representation of the > >year. > > It depends on what you want to call "bad". It's quite possible > to build a Y2K compliant system out of non-Y2K compliant > components! > > 2.11BSD's date(1) was patched for Y2K in such a way that "00" in > the two-digit year would be interpreted as the year 2000. (See > patch #327 for the details.) > > Would similar fixes for more historic Unices be useful to the general > folk here? > > -- > Tim Shoppa Email: shoppa(a)trailing-edge.com > Trailing Edge Technology WWW: http://www.trailing-edge.com/ > 7328 Bradley Blvd Voice: 301-767-5917 > Bethesda, MD, USA 20817 Fax: 301-767-5927

26 years, 2 months

Re: What *was* the Tahoe?

by mxs46＠k2.scl.cwru.edu

Wortner, Frank (RSCH) <Frank_Wortner(a)ml.com> writes to me: > P.S. You might want to forward this to the PUPS list, since I'm no longer > an active member (emal address changes, etc.) Doing so. Forwarded message: >From Frank_Wortner(a)ml.com Wed Nov 25 11:31 EST 1998 Return-Path: <Frank_Wortner(a)ml.com> >From "Wortner, Frank Thu Nov 26 02:27:07 1998 Received: from hudutilgw.ml.com by k2.cwru.edu (8.6.12/SMI-SVR4) id LAA16359; Wed, 25 Nov 1998 11:31:34 -0500 Received: from mail1.ml.com ([199.201.57.137]) by hudutilgw.ml.com (8.9.1/8.9.1/MLgwo-4.02) with ESMTP id LAA25304 for <mxs46(a)k2.scl.cwru.edu>; Wed, 25 Nov 1998 11:27:52 -0500 (EST) Received: from ewfd12.exchange.ml.com (ewfd12.exchange.ml.com [146.125.111.6]) by mail1.ml.com (8.9.1/8.9.1/MLml5-4.03b) with ESMTP id LAA00612 for <mxs46(a)k2.scl.cwru.edu>; Wed, 25 Nov 1998 11:27:12 -0500 (EST) Received: by EWFD12 with Internet Mail Service (5.5.2232.9) id <XJFJ99ZK>; Wed, 25 Nov 1998 11:27:13 -0500 Message-ID: <B27EB33BAB29D2119ABF0001FA7EF28911B0D4@EWFD04> From: "Wortner, Frank (RSCH)" <Frank_Wortner(a)ml.com> To: "'mxs46(a)k2.scl.cwru.edu'" <mxs46(a)k2.scl.cwru.edu> Subject: Re: What *was* the Tahoe? Date: Wed, 25 Nov 1998 11:27:07 -0500 This one I know the answer to. "Tahoe" was the internal name for a computer called the "Compter Consoles Inc. 632." (At least that's what I recall." The machine itself was a light grey cube about the size of a VAX 750 CPU. The cube housed the CPU, the disk drives (Fujitsu "Super Eagles" I think) and an auto-loading tape drive. If I recall correctly, the manufacturer was located in Rochester, New York, USA. I used to sys admin one of these beasts -- a *long* time ago. They were pretty durable: mine not only survived an air condioner failure during which the temperature rose to more than 100 degrees Fahrenheit, it actually kept on working without a break for several hours! It was a good box, an attempt at a "VAX-killer," but it never really managed to grab a substantial base from DEC's boxes. Frank P.S. You might want to forward this to the PUPS list, since I'm no longer an active member (emal address changes, etc.)

26 years, 2 months

Re: Net2 Status: likely outcome

by mxs46＠k2.scl.cwru.edu

Warren Toomey <wkt(a)henry.cs.adfa.oz.au> writes: > Therefore, once SCO reads through the legal documents (which they now > own), I'd be pretty sure that they will still treat Net/2 as > contaminated, and people will need a 32V license in some form in order to > legally acquire a copy of the Net/2 tape. Then until/unless Warren tells me otherwise, I'll keep Net/2 together with the real 4BSD distributions in Distributions/4bsd/net2, readable by the members of the pupsarc group only. Sincerely, Michael Sokolov Phone: 440-449-0299 (Home) 216-217-2579 (Cellular) ARPA Internet SMTP mail: mxs46(a)k2.scl.cwru.edu Received: (from major@localhost) by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id RAA15311 for pups-liszt; Wed, 25 Nov 1998 17:22:17 +1100 (EST) (envelope-from owner-pups(a)minnie.cs.adfa.oz.au)

26 years, 2 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