Re: hpdrive changes: dac holdoff

Where can I find a description of the AMIGO or CS/80 protocols?  Some
blurb I found sounded like the AMIGO identify command is UNT followed
by MTA, but then said it was implemented by setting the secondary
address of a nec7210 to UNT, which would suggest MTA followed by UNT?
Anyways I'd like a specific problematic protocol example.

On Wed, May 5, 2021 at 12:52 AM Ansgar Kueckes <[email protected]> wrote:
>
> Hi Frank,
>
> from the user space I guess it would be cool to merge data & events in a
> logical queue, so that the correct sequence is visible to the
> application. Most applications probably still won't need it because of
> simple transfer schemes, but those who rely on GPIB signalling will take
> advantage out of it.
>
> HP's AMIGO and CS/80 protocols, however, unfortunately mix up HP-IB
> signalling and logical commands (sent as data) for flow control, so
> there is still a need for synchronous use of GPIB commands controlled by
> the application. The GPIB controller FIFOs cannot run fully independent
> of the application, the hold-offs for the source/acceptor handshake
> (which is the best way to pause the FIFOs) still have to be functional
> in order to implement the AMIGO and CS/80 protocols.
>
> -Ansgar
>
>
> > Actually I was confused, thinking of RFD holdoffs rather than DAC
> > holdoffs.  What if linux-gpib maintained a unified input queue
> > combining data bytes and events, in the order they were received?
> > "Events" would be expanded to include unrecognized command bytes
> > (which would include secondary address bytes when the device is
> > primary addressed but not configured to use secondary addressing), and
> > device state changes related to reception of command bytes (like being
> > addressed/unaddressed etc).  Then would you really need to fiddle with
> > low level bus operation (DAC holdoffs) from user space?
> >
> > On Tue, May 4, 2021 at 1:57 AM Ansgar Kueckes <[email protected]> wrote:
> >> Hi Dave,
> >>
> >> yes, it is true that the hold-off is a bit tricky (not well documented,
> >> different hold-off types & registers to deal with hold-offs, the later
> >> NI ASICs make it even worse, and almost no sample code available), and I
> >> had in fact to do a lot of experimental work on it, so I can agree
> >> Franks concerns.
> >>
> >> However, as it is implemented now it works quite well with hpdrive for a
> >> pretty long time now for all 7210 style controller chips (at least there
> >> was no report yet that it didn't work), and in fact I don't know many
> >> other applications around which make use of the function. For the AMIGO
> >> and CS/80 protocols, the DAC hold-off is an essential part of the
> >> mechanism, and works quite reliably, even under the harsh timing
> >> conditions of those protocols. So I guess we can assume, if it works
> >> with hpdrive, it should work with all others as well.
> >>
> >> Those protocols work asynchronously and send a secondary address from
> >> the controller to the device as command. After receiving the secondary,
> >> each device needs time for preparing itself for the next step (e.g.
> >> transfers to/from media). So the device has to keep the controller off
> >> until it is ready. It does so by activating the DAC hold-off, so that
> >> the controller has to wait on the bus, until the device is ready for the
> >> next steps and releases the hold-off. The controller can now continue
> >> with e.g. sending data to the device.
> >>
> >> Today we would use other mechanisms, because mixing the GPIB features
> >> for the handshakes on device level isn't the best idea of all. Also, the
> >> original purpose of the secondary address is not being used as device
> >> command. But at that time HP-IB was quite new and HP probably was proud
> >> of the elegant design, so made more use of the features than others. I
> >> don't think there are many other applications using GPIB hold-offs.
> >>
> >> Hope this shows a bit how it works. I would be glad to give more insights.
> >>
> >> -Ansgar
> >>
> >>> Hi Dave,
> >>>
> >>> I predict exposing a dac holdoff release function is going to cause
> >>> difficulties.  Every "nec7210 compatible" chip handles dac
> >>> holdoff/release slightly differently and it was a nightmare trying to
> >>> reach some lowest common denominator in the nec7210 driver where no
> >>> bytes would get thrown away and the holdoff would reliably be
> >>> released.
> >>>
> >>> Is there anywhere I could get info on why dac holdoff release control
> >>> is required by hpdrive emulation?  Also, why does it care about
> >>> secondary addressing state?
> >>>
> >
>


--
Frank