[Simh] UDA/KDA/KRQ emulation

[Tim Shoppa]

"Bob Armstrong" <bob at jfcl.com> wrote:
>   It looks like _any_ MSCP emulation in simh on a UNIBUS machine reports the
> controller type as a UDA50, and any QBUS simulation reports the controller
> as a RQDX3.  This is a rather simple approach that leads to all kinds of
> funky and incorrect situations, especially on the QBUS.   For example, if
> you attach an RA drive to a QBUS -11 and boot RSTS, then RSTS will tell you
> that the controller is a RQDX3 with, say, an RA81 drive.   Clearly
> impossible.  Likewise if you attempt to use a RRD40 on a PDP-11 it'll think
> the controller is a RQDX3 - again, impossible.  I'm more than a little
> surprised that RSTS doesn't crash, given how fussy RSTS is about the
> hardware, but it doesn't seem to care.
>
>  
>
>   In any case it bugged me to see all these bogus hardware configurations,
> so I've hacked up (er, "enhanced") the "set rq" command in simh so you can
> now say
>
>  
>
>                 set rq uda50
>
>                 set rq kda50
>
>                 set rq rqdx3
>
>                 set rq krq50
>
>  
>
> There's no sanity checking so it's still possible to create impossible
> configurations, but at least now you can actually create _possible_
> configurations too.
>
>  
>
>   Even this is still a pretty simply minded approach, since other things
> (e.g. hardware revision level, firmware version, etc) should also change
> when you change the controller type, but at least now when the emulated OS
> shows the hardware configuration you get rational results.
>
>  
>
>   Is this worth adding to the simh code base?

If many OS's cared about the details of controller name and drive name,
then yes it might matter. (I remember with the Webster MSCP-emulating
controllers discovering what cute strings I could sub in for the
drive model names, so I do appreciate some of the details!)

We are pretty lucky that with a few exceptions, the OS is happy to deal
with a bunch of linearly-numbered blocks on the disk and doesn't
mess with RCT's and XBN's and other stuff unless/until there is a bad
block, and we should never have a bad block under emulation.

There are some examples of OS's caring about hardware/firmware revision
levels - for example the earlier rev TK50 controllers had some flaky DMA
that were corrected in later ones, and some versions of RSTS simply
refuse to work with the older flaky ones as ID'd by the revisions
bytes.

XXDP obviously cares more about drive and (especially) controller
differences but I personally don't want to have to recreate everything
to do the details the ZRQC formatter for RQDX3 MFM drives does. At
the same time, if you thought you could progress the state of the art
in understanding the MSCP devices by emulating the RQDX3 and MFM drives
to such a detailed level that ZRQC did all its low-level formatting and all
the other MSCP XXDP stuff ran perfectly too, there would be some real
value in knowing that the emulation is more correct (albeit more
complicated most likely) than before.

If we were expecting the OS running under emulation to do bad-block
replacement UDA50 style vs RQDX3 style then it might matter too. I for
one am glad that I haven't had to think about bad-block replacement
strategies in PDP-11 OS device drivers for a decade now :-).

Tim.