Re: QVSS driver

[Felix Deichmann <m4j0rd0m0%gmail.com@localhost>]

2015-09-25 4:28 GMT+02:00 Charles Dickman <chd%chdickman.com@localhost>:
> I noticed this and wondered about it, but 64 interrupts is a lot of
> qbus hardware. I don't think things end well either way. You either
> run into an allocated vector or you run off the end of the vectors.

Yeah so writing back uh_lastiv with the actual Q-Bus vector obtained
will allocate 64 vectors (of which only 1 or 2 are used) and reduce it
down to 8-bit iff uh_lastiv was 9-bit before. Should be the desired
behaviour.

> vertical retrace (for not implemented hardware cursor)  and DUART.

But only DUART is used and registered after matching at the moment, right?

> It should have been automatic as you say. ua_cvec contains the
> interrupt vector that was found in match and then this is used to
> program the hardware. The KA650 manual says that qbus interrupts start
> at VAX interrupt 0x200. So if ua_cvec contains the VAX interrupt then
> it is 0x200 + the qbus interrupt. This is used to program the
> interrupt controller and if it is 16bit instead of 8 (or 9) it gets it
> wrong.

OK so practice is this (correct me if I'm wrong): You take one or more
Q-Bus vectors from the uh_lastiv "pool" and write them to the vector
register(s) of the programmable device. As uh_lastiv initially starts
at 0x200, this will be a 9-bit value or less. Then you trigger the
interrupt for the match. (ua_cvec is still not of interest at this
point.) If ua_cvec contains the VAX interrupt after that and not the
Q-Bus vector, it would be better to not use this to
program/reprogram/... the interrupt controller of the device then, as
it can already be translated with a machine-specific offset of some
kind, as you say. In fact, none of the drivers I could find uses
ua_cvec to write a vector register, but uh_lastiv instead.
Accordingly, the offending line 264 is in qvaux.c where both scopes
are mixed (?):

    qv_ic_setvec(ua, QVA_QVIC, QV_DUART_VEC, ua->ua_cvec);

For the real QVSS, this is masked to 8 bit by hardware and works,
while a SIMH QVSS accepts a full 16-bit value and screws up. Now I
understand. :)

Regards,
Felix