System Industries MSCP disk controller problem

System Industries MSCP disk controller problem

[Michael Sokolov]

   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 at k2.scl.cwru.edu

Received: (from major at 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)
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 at MINNIE.CS.adfa.edu.AU>; Tue, 1 Dec 1998 14:26:35 +1100 (EST)
Received: by timaxp.trailing-edge.com for PUPS at 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@trailing-edge.com>
To: PUPS at minnie.cs.adfa.edu.au
Message-Id: <981130222421.2de00129 at trailing-edge.com>
Subject: Re: System Industries MSCP disk controller problem
Sender: owner-pups at 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 at 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

System Industries MSCP disk controller problem

[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 at harrier.Uznet.NET


Received: (from major at 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 at 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 at minnie.cs.adfa.edu.au>; Thu, 3 Dec 1998 13:36:22 -0800
Message-ID: <36670437.966A4527 at halcyon.com>
Date: Thu, 03 Dec 1998 13:35:51 -0800
From: "David C. Jenner" <djenner@halcyon.com>
Reply-To: djenner at 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 at minnie.cs.adfa.edu.au>
Subject: Re: System Industries MSCP disk controller problem
References: <199812032008.BAA08080 at harrier.Uznet.NET>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-pups at 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 at 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 at 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 at minnie.cs.adfa.edu.au>; Fri, 4 Dec 1998 06:44:46 +0500
Message-Id: <199812040144.GAA08380 at harrier.Uznet.NET>
From: Michael Sokolov <msokolov@harrier.Uznet.NET>
Date: 4 Dec 1998   01:44:38 GMT
To: pups at minnie.cs.adfa.edu.au
Subject: Emulex QT13 and related questions
Sender: owner-pups at 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 at harrier.Uznet.NET


Received: (from major at 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 at 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 at minnie.cs.adfa.edu.au>; Fri, 4 Dec 1998 07:13:41 +0500
Message-Id: <199812040213.HAA08416 at harrier.Uznet.NET>
From: Michael Sokolov <msokolov@harrier.Uznet.NET>
Date: 4 Dec 1998   02:13:33 GMT
To: pups at minnie.cs.adfa.edu.au
Subject: Re: System Industries MSCP disk controller problem
Sender: owner-pups at minnie.cs.adfa.edu.au
Precedence: bulk

   David C. Jenner <djenner at 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 at harrier.Uznet.NET


Received: (from major at 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 at minnie.cs.adfa.oz.au>; Fri, 4 Dec 1998 16:19:36 +1100 (EST)
Received: (from wkt at 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@henry.cs.adfa.oz.au>
Message-Id: <199812040521.QAA03261 at henry.cs.adfa.oz.au>
Subject: Re: New Apout PDP-11 simulator
To: grog at lemis.com (Greg Lehey)
Date: Fri, 4 Dec 1998 16:21:40 +1100 (EST)
Cc: pups at minnie.cs.adfa.oz.au (Unix Heritage Society)
In-Reply-To: <19981204154443.E38307 at freebie.lemis.com> from Greg Lehey at "Dec 4, 98 03:44:43 pm"
Reply-To: wkt at 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 at 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 at 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 at 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 at minnie.cs.adfa.edu.au>; Fri, 4 Dec 1998 15:31:28 +0500
Message-Id: <199812041031.PAA09422 at harrier.Uznet.NET>
From: Michael Sokolov <msokolov@harrier.Uznet.NET>
Date: 4 Dec 1998   10:31:01 GMT
To: pups at minnie.cs.adfa.edu.au
Subject: Some nice progress with hardware and Ultrix in the PUPS archive
Sender: owner-pups at 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 at harrier.Uznet.NET