Re: I/O bus reset to fix CMD MSCP controllers (and probably others)

[Johnny Billquist <bqt%softjar.se@localhost>]

I think we're talking about the same manual.
http://www.bitsavers.org/pdf/dec/disc/uda50/AA-L621A-TK_UnibusPortDescription_1982.pdf


On 2025-03-31 19:06, Mouse wrote:
> > Anyway, I've re-read most of the UDA50 programming manual this
> > morning and [...]
>
> It seems to me that manual - at least if it's the one I found - is
> somewhat incomplete.  Quoting from a comment in the MSCP support for my
> emulator, which emulates a MicroVAX-II:
>
>   * AA-L621A-TK is silent on some important questions.  In particular:
>   *
>   * What does reading IP before the end of the four-step init sequence
>   *  return?  Are there any side effects of such a read?

Reading the IP never returns anything relevant/interesting/useful. It's 
purpose is only to trigger the controller to scan the command buffer queue.
As the controller isn't operational yet, that would imply that this side 
effect does not happen. As for what you actually return, I would 
probably respond with 0 at any time.

>   * What does reading SA during normal operation return?  Are there any
>   *  side effects of such a read?

The manual states:
"When read by the host during normal operation, it communicates status 
information including port- and controller-detected fatal errors."

I would say there are no side effects.

Chapter 7 shows a list of errors that can appear in SA.

A more detailed list of error codes explicitly for the UDA50 can be 
found in 
http://www.bitsavers.org/pdf/dec/disc/uda50/AA-M185B-TC_UDA50_Maintenance_Guide_Nov82.pdf

>   * The KA630 boot ROM seems to expect a nonzero value in SA the first
>   *  time it reads it, which seems to run counter to AA-L621A-TK's
>   *
> The host begins the initialization sequence either by  issuing  a  bus
> INIT  or  by  writing  any  value  to  the IP register.  The port must
> guarantee that the host will read zeroes in SA on the next bus  cycle.
> Initialization  then  sequences  through Steps 1-4 as described on the
> following pages.

Well, when writing to IP, the SA should then be 0 for about 100ms, after 
which Step1 should go on. So I would say the normal pattern is to write 
to IP, and then wait for Step1.

But I'm not sure what is meant by "first time" here.

>   *  but the ROM code does read from IP before reading SA.  (If the ROM
>   *  code finds zero in SA, it seems to assume the device has already
>   *  been initialized.)  I'm going to assume that reading from IP also
>   *  pushes the device from reset to step 1.

The device should move from reset to step 1 without any poking of IP 
needed. Seems to be rather clearly stated in the manual, and all the 
code I can find seems to assume the same thing.

>   * The spec is also silent on the question of what order the elements
>   *  of the command and response rings are supposed to be used in.
>   *  Calling them `ring's implies that they are to be used in cylic
>   *  order, but this is not stated; also, there's no hint where the
>   *  hands should begin in that case.  The NetBSD driver seems to use 0,
>   *  so that's what we use.

Yes, they are rings, and yes, you start at element 0. And yeah, I can't 
find this explicitly documented in the manuals I have.
I wonder if perhaps the MSCP spec means to imply that when the 
controller is kicked, it will actually always scan the whole ring, and 
you would in theory not need to care where you put your packets. 
Something that could be experimented on, I guess.
But all the code I've seen is just progressing through the circular 
rings as you might suspect.

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol