I have a spare sun 2/170 backplane that I am going to try to tie together 
the p2 lines so that I can get 8 meg of ram through 1 meg cards.
Any caveats? 

The 170 cardcage has more than enough slots for my use.  I know that Sun has 
unusual uses for the p2 bus, thus it must be isolated from non-Sun 
cards.  

What types of multiport serial cards are there? What drivers do they use?

8 responses total.

   I have heard of people wiring more P2 connectors than the Sun-2
originally had, so I think its do-able.  Probably the main thing to
worry about is the wire you will use.  Duplicate whatever they did
and you should be OK.

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.

What is your estimation of system load on 2400 baud file transfers (incoming)

I would guess about 25% of the system.

Interesting problem : I cannot get my system to boot with 8 meg of ram
installed.  7 meg is ok, any other combination is ok.
8 megs and it continuously reboots, regardless of which board I use as the 
8th meg.  (I.e '11114' configuration fails similarly to a '41111' config.)
I like my 4 meg board though.  7 megs of ram now.  Almost like a real computer.

I just obtained a *very* handy box that has mouting and faceplates for 
a big archive tapedrive and in the back of the box has two mounts for full-
height 5 1/4" drives and has power for all of this.  This should really tidy
up my setup.

If the memory isn't completely decoded, it's possible it wraps around
after 8 M.  In this case, the autosizing code in Unix will erase
itself.

   Are you sure that the slot for the 8th meg is P2 connected?

I figured it out.
It's booting, but it's acting as if the 8th meg is a monochrome video board.
sheesh

Response not possible - You must register and login before posting.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss