Re: System Industries MSCP disk controller problem

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 about VAXen? Can you still call 1-800-DIGITAL with a _BIG_ credit card in hand and order a VAX? 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 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. 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. 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) 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 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) 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) 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 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) 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) 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