mdw
|
|
response 2 of 8:
| 
Aug 2 08:38 UTC 1991 |
Most non-sun cards won't use P2 at all and may co-exist quite happily
on P2 with the sun cards. You'll have to check the individual cards
to be sure. Originally, p2 was a manufacturing connector -- Intel
used them to test their cards out. That's not a very important use
of them, so most people just didn't do anything with it. The sun
designers used it for their private memory bus -- why not? Most
backplanes didn't even wire it up. More recently, with IEEE-796,
uses for a few pins were defined -- basically, some power & ground
connections, and 4 more address pins -- so you can put 16 M of
ram into your multibus machine instead of just 1 M max. A few
disk drives and other controllers are therefore likely to offer
support for those extra address lines, but almost always as
an option -- generally they can be disabled. In fact, since the
sun-2 doesn't use them, you can probably always cut any leads
going to p2 with perfect safety. Not that you should need to,
the backplane is divided into enough discontiguous chunks that
this shouldn't be necessary.
Now, the way the sun-2 works is all the system memory is on p2,
and since it's not really on multibus, it's not limited to the
1 M address space limit. But since the multibus devices do need
to get at the memory, the sun does a very clever thing. The first
256K of multibus memory space can be mapped into the p2 memory,
using mapping registers on the CPU. Essentially, these mapping
registers constitute a crude form of MMU for the I/O devices,
and in fact, on the sun-2, that's exactly what they are. (The
PDP-11/70 and VAX-11/7xx series also have mapping registers,
to go from the unibus to the backplane memory, but they're "weird")
Since the mapping registers work on page boundaries, it also
acts as something called a 'scatter/gather' map -- which means
the system can do a large I/O, say, 64K to disk or tape, and
give it discontiguous bits of main memory -- an obvious advantage
in a demand paged environment where not everything is necessarily
contiguous. That's why it's not really such a big deal that the
Sun-2 only supports the 1 M version of the multibus, and not the
extra address lines. IN fact, it's something of an advantage.
Many multibus cards, such as the Xylogics and tapemaster, have
real problems talking to more than 1 M. On the xylogics, if you
select 24 bit addressing, you end up with weird 64K segmention
problems - at least I think you do (the manual isn't entirely clear
on this, naturally). On the tapemaster, you end up with strange
1 M segmentation problems -- a single I/O has to reside entirely
within 1 M.
The only serial multiplexor I know of that's supported for the Sun-2
is the Systech MTI-1600. It uses a single Z80 to run 16 usarts, and
has a somewhat interesting hardware design: the Z80 lives on a card
in the multibus card-cage, as usual. Bht the 16 usarts live in
a separate box elsewhere, that's attached directly to the 16 DB25's
for the serial ports. That makes it a fairly compact package, without
too much hairy cabling to connect all the parts. Just one 50 pin
cable to get 16 ports -- sun, on the scsi card, takes up 2 50 pin
cables to implement just 4 ports; and those 4 ports are pretty much
naked character-by-character usarts (ugh). Systech has other
cards -- there's an MTI-800 which is essentially the 1600 with
only 8 ports (actually, just one usart card instead of two).
And I think there was another version that used some sort of weird
thin cable and could support up to 64 ports. Output-wise, the 1600
is great for the sun -- the sun pretty much just has to setup the
DMA and tell the 1600 to print it out. Only slight ugliness is
some byte swapping weirdness, but for serial I/O, that's not
much of a problem. Input-wise, the 1600 doesn't do so well. Major
problem is that the sun still does character-at-a-time processing,
even tho the card theoretically supports DMA on input as well.
There are some interesting problems with doing DMA on input tho,
that relate to things like detecting parity errors, response time,
and the like, so I can hardly fault Sun for that.
Indeed, 4.2bsd never supported anything smarter for any
VAX tty device, & only 4.3bsd that I've seen does anything
intelligent in this regard.
|