MSCP disk vs KA630s

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

I'm still working my MicroVAX-II emulator, this time on adding MSCP
disk support.  And, as you can doubtless infer from my sending this,
I've run into another issue I'd like to bounce off the collective
wisdom here.

I'm using AA-L621A-TK as my reference for MSCP-over-Unibus (and,
mostly, Qbus; I've never seen an MSCP-over-Qbus spec, but this doc
includes reserved bits called Q which appear to be the additional bits
for Q-22 addressing).  It says, of ring data buffers,

                    For responses, the host sets the length  equal  to
                    the   size  of  the  response  buffer,  in  bytes,
                    beginning with <text+0>.  The  minimum  acceptable
                    size  is  60  bytes  of  message  text  (64  bytes
                    overall).   Before  actual   transmission   of   a
                    response, the controller reads the length field in
                    the message envelope.  If the port's  response  is
                    longer  than  the  response  buffer, the port will
                    fragment  its  response  into  as  many   response
                    buffers as necessary.
...
                    Note that if a  controller's  responses  are  less
                    than  or  equal  to  60 bytes, then the controller
                    need not check the size of the response slot.

When I try to "b dua0" to the KA630 boot ROMs, I'm seeing response ring
buffers with length 0.

I can see multiple possibilities here.  It's possible I have a bug and
the buffer lengths aren't actually 0 on a real system.  It's possible
the boot ROM code authors were lazy and didn't bother setting lengths
because all Qbus disk controllers in question were known to take
advantage of the last of the above-quoted sentences.  It's possible the
boot ROM code does this deliberately to lock out third-party disk
interfaces written to the spec.  It's possible that the boot ROM code
isn't supposed to do that but it's buggy, and the bug wasn't
discovered/fixed because nobody tested with an interface that checked
response buffer lengths.  (Did I miss any possibilities? :-)

I went to have a look at simh, because it seems to use real KA630 boot
ROM code as well.  But either I'm missing something or it too is taking
advantage of that last sentence; I don't see anything that I can
identify as the code fetching the response buffer length.  Looking at
NetBSD's MSCP code, it looks to me as though it's setting the buffer
lengths correctly, for what that's worth.

Anybody have any thoughts they'd care to share on this?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B