VAX8200: Fix DWBUA interrupt delivery

[markpizz]

VMS 4.x can leave a DWBUA adapter error interrupt pending while the UDA50/RQ controller is reinitializing. The previous VAX 8200 UBA interrupt evaluation treated a pending adapter interrupt as mutually exclusive with normal UNIBUS device interrupts. That masked the RQ interrupt needed to finish initialization, causing VMS 4.4 and 4.7 to hang during boot.

Evaluate adapter and normal UNIBUS interrupt sources independently. Adapter interrupts now use the BIIC Error Interrupt Control Register level bits, force bit, and complete bit. Vector delivery sets the documented interrupt-complete state, and posted error requests are qualified by the BIIC hard/soft error interrupt enables. DWBUA generated error requests set EICR FORCE when BUAEIE is enabled.

Also record DWBUA-initiated VAXBI transaction failures in BUACSR BIF and BIFAR, matching the DWBUA manual. The previous code only set the BIIC BER bus-timeout bit for that path.

Add aligned longword I/O-page reads by issuing two UNIBUS word reads. The DWBUA responds to longword VAXBI transactions, and this matches the two 16-bit UNIBUS cycles needed for a 32-bit read.

Add unit coverage for DWBUA adapter interrupt requests, EICR FORCE and COMPLETE behavior, BIIC error-interrupt enable gating, adapter versus device interrupt priority at the same level, BUACSR BIF recording, and aligned longword I/O-page reads.

Manual references:

• DWBUA Technical Manual, EK-DWBUA-TM-001, sections 3.2.4.2, 3.2.4.5, and 3.4.5.
• VAXBI System Reference Manual, EK-VBISY-RM-003, sections 7.2, 7.4, and 18.3.4.

Validated with focused VAX 8200 unit/integration tests and manual boot/shutdown smoke passes for VMS 4.4, VMS 4.7, and VMS 5.0-1.

[pmetzger]

Thank you for not actually crediting the person who did this in the pull request. It was my work. You even used my commit message as the pull request message without mentioning that you didn't write it.

[markpizz]

@pmetzger: Please explain how I can create a pull request with your github login?

Apart from that impossibility, please look at the actual commit that has been submitted in this PR.

You may also want to look at the many commits you picked up from the open-simh/simh PR list which you committed in the pmetzger/zimh as authored by you.

[pmetzger]

Your pull request should've mentioned that you got the fix from me. Every time I commit something based on someone else's pull request, I mention who wrote the thing.

[pmetzger]

Anyway, it's all open source, it's not like I would stop you from using it, although you don't offer people the same courtesy on your repository. But it would've been decent to have said who wrote it and where you got it.

[markpizz]

The commentary that matters is what is in the repo. That, then travels along with the repo to everywhere it is cloned. Merely adding comments in some likely disconnected commentary in some random clone of the repo loses track of that detail.

[markpizz]

Anyway, it's all open source, it's not like I would stop you from using it, although you don't offer people the same courtesy on your repository. But it would've been decent to have said who wrote it and where you got it.

Of course, you could have put a PR here, but you didn't.

[pmetzger]

FWIW, this fix isn't validated yet. The original reporter hasn't actually confirmed that the bug is gone for them and I haven't run OSes on the new code for more than an insignificant amount of time.

More generally, at this point, my code has diverged so much from SIMH that a significant fraction of my bug fixes don't apply at all, and the rest of them now require serious effort to apply in the best case. Pretty soon most of the code isn't even going to be in C.