On 2018-04-10 00:25, Mark Pizzolato wrote:
On Monday, April 9, 2018 at 3:08 PM, Johnny Billquist wrote:
On 2018-04-09 22:16, Mark Pizzolato wrote:
On Monday, April 9, 2018 at 11:57 AM, Johnny Billquist wrote:
For serial ports, that
obviously means that you might connect one line to a physical line,
another to a telnet listener, and another one not connected to anything at
all.

You can actually do that right now.  Each line on any multiplexer
device can have a separate TCP listener or be connected to a remote
TCP port or to a local serial port, or be part of the pool of ports
which may optionally be configured to listen for the mux device.

Right. But I cannot skip a few lines. And simh really dislikes me if the number 
is
not a multiple of 8.

Once the Qbus 4 vs 8 ports for the Qbus DZV11 bug that Bob pointed
out is fixed, you certainly can skip as many lines as you want.  Simh
is simulating the hardware.  You couldn't buy a 2 port DZ11.  They all
had 8 ports.  You can choose to connect as many or as few of these
lines to wherever you want with the current implementation and
have the others either be completely disconnected/unused or
generically listening on a specific TCP port.

So how do I disable (not connect) some lines in simh?

With simh as it is currently written, all of your DZ devices do need to
be configured to have adjacent CSR address blocks and Vectors.
They can't separately be scattered around the I/O space.

...which I can with real hardware.

And exactly
how many units/lines the controller have should also be a factor here then.

This also comes back to disks, where I might not want to configure
four disks on one controller, but maybe one controller per disk.

The device simulation for DEC's disk controllers usually default to
the maximum number of disk devices each controller was capable of
supporting.
Each of those device units can be disabled so if you want one
controller per disk, you absolutely can.

Up to 4 separate MSCP controllers can be configured today (with up to
16 separate drives).  A single RP controller with up to 8 drives is available.

This functionality has solved most user problems without issue.  If
you've got a simulation need for more than this, you can extend or
rewrite what's there now.  Since configurations that can be simulated
today can far exceed what was ever possible on any real system, it
seems like a lot of work to address the theoretical flexibility you're
asking for.  :-)

I'd like to have more than 4 disks on one MSCP controller. There is absolutely
no reason for the limit of 4. That's just an implementation detail on some of
the existing MSCP controllers, but there are MSCP controllers who also take
more than 4 disks.

And that exists in real life, and I cannot do that (and a bunch of other
setups) in simh, so I'd say that simh is rather more limited than real life. :-)

Same story for TMSCP.

Please identify Qbus or Unibus controllers that had hardware support for
connection of more than 4 units and I'll include those controllers (with
their limits) in the simulator.  A pointer to the documentation for these
devices would be helpful.

The CMD SCSI controller, for example. I can have as much as 7 disks on one controller there. Or 7 tapes. And that exists for both Unibus and Qbus, and I happen to have both. But why do you want to have a limitation in simh at all here? The MSCP was designed to explicitly not have such limitations in the architecture. And while I'm at it, it would be nice (although this is just cosmetic) to be able to set the disk identifier to any string, and not have my arbitrary sized disk always be identified as an RA81.

And that limitation of 7 is obviously because of limitations on SCSI, which can only have 8 devices on the bus, and the controller is one.

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: b...@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Reply via email to