[Simh] Limits on MSCP controllers

[Clem Cole]

On Mon, Jun 24, 2019 at 2:13 AM Timothe Litt <litt at ieee.org> wrote:

>
>
> MSCP is basically an evolution of the Massbus protocol, on a different
> PHY, and informed by the TOPS-10/20 experiences with high-end  (large,
> redundant, on-line serviceable) configurations.
>
That was certainly my impression/memory.



> ...
>
> SimH is really about preserving the ability to run legacy software, not
> slavishly implementing hardware.  As Bob has documented, there are
> certainly cases where an OS depends on low-level hardware design.  In those
> cases, strict fidelity matters.
>
Amen....

>
>
> Note also that as a rule, SimH does not implement hardware features unless
> some OS requires them - this is especially true of maintenance/diagnostic
> features.  There are also subtle differences - e.g. an OS under SimH may
> carefully order & fence disk writes to ensure file system consistency in
> failure cases.  But while SimH will present them in order to the host OS,
> the host OS and/or hardware may not have the desired semantics.  (E.g. due
> to caching, position optimization.)  Bob & I had many discussions (and
> differing opinions) about how important these effects are in the very early
> days of SimH.  (While we were still at DEC...)  The decision was to ignore
> these issues - even with host OS support, there's no good way to divine the
> legacy OSs' intent and pass it on to the host.  Here SimH performance
> trumps fidelity.
>
And I for one admire how well you (Mark, Bob, Tim et al) have done over the
years.   It's a tough thing .. but I think the high order bit for design is
to ensure legacy SW keeps running.  Additions to the simh kit seem like it
should be to support real HW and real SW from the past.   This means is VMS
or UNIX or whatever supported it, simh needs to try to provide support for
it.   The issue, of course, as Bob pointed out, is 3rd party much less CSS
HW.   Many legacy systems did support both, but often neither was well
documented.  If adding things like a KS-11 (CSS) or support for an
ENABLE-11 (Able computer) can be done, that's a good thing, provided it can
be well documented.  Then standard distributions can run.

Adding support for HW that never existed I have a harder time with
frankly.   The argument in favor is to allow native support for more modern
HW without having to map if >>if<< someone can write the support for both
simh and the OS in question.  But that strikes me as a 'nice to have' and
not something I worry too much about personally.

Anyway - my thoughts..
Clem

ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20190624/89b6dd59/attachment.html>