Re: hpdrive changes: dac holdoff

Ok, and the dac holdoff requirement seems to come from AMIGO's need to
change the parallel poll response synchronously with reception of
certain command bytes.

One of the more disturbing aspects of the hpdrive patches is they
change the behavior of data read/writes on some of the boards, such as
the conditions under which they are interrupted and return early.
There may or may not be good motivation for this, however:
1) know it WILL break people's existing code
2) there should be a clear and defensible rationale for the change,
and specification of exactly what the required behavior now is
3) if the behavior of data reads and writes is to be changed, it
should be changed consistently for all boards

Whether the patches are merged is up to Dave, as I am not the primary
maintainer of linux-gpib any more.  However, I feel I should fully
disclose what my position on all this is.  I don't particularly care
about HPDRIVE or AMIGO, etc.  The patches in their current state
introduce finely-tuned behavior in scattered locations for no clear
reason other than they are apparently required to make hpdrive work.
That makes linux-gpib support for hpdrive likely to be broken by
anyone refactoring the code, especially anyone who doesn't have a
strong interest and knowledge of hpdrive and associate protocols, such
as myself.  There are parts of the patches which are just general
improvements and could be cherry picked out, but if all the patches
are merged in anything like their current state, my response will be
to abandon main line linux-gpib completely, and just make a minimally
maintained pre-merge fork for use in my own work.  Maybe this is fine
though, as I haven't done much development on linux-gpib for a long
time, except when I needed to fix something for work.

On Wed, May 5, 2021 at 2:21 PM Ansgar Kueckes <[email protected]> wrote:
>
> See the files attached.
>
> The Identify command was some kind of extension to the HP-IB standard.
> HP realized that the HP-IB standard lacked a device identification
> mechanism (comparable to the PCI Device Id). So they implemented a
> special circuit in their HP-IB controllers which worked similar to a
> poll where the addressed device's controller replied with a defined
> two-byte ID. It works by sending an UNT followed by the primary address
> of the queried device as secondary address. However, the mechanism never
> became part of the IEEE standard and was implemented in HP's own HP-IB
> controller chips only.
>
> The only other chip that can detect and handle the Identify is a nec7210
> by activating secondary addressing and using the UNT as TALK to address
> 31. Which normally is an invalid address, but the nec7210 is implemented
> entering talker state when being configured to 31 as second primary
> address when in dual extended addressing mode. Actually this is a flaw
> in the nec7210 design, but for the sake of compatibility all 7210
> implementations also implement that special behavior.
>
> -Ansgar
>
> > 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.
> >
>


-- 
Frank