SuperPET OS/9 MMU question

First some context, then some questions follow :)

I have mentioned before, I think, that I am working on a PET core for
the Mega 65. See https://github.com/Rhialto/PET2001_MiSTer/ and
https://github.com/Rhialto/PET_MEGA65 . The published version is up to a
8296-D. -GD and SuperPET are in the works (including a 6702!).

I ported some VIA test programs from VICE that were running on the
VIC-20 to the PET, so that I could validate the VIA implementation that
I was using.  It turned out I had to replace it, since it was failing
too many of the tests.

So I took another VIA (fortunately there were at least two others to
choose from), the one from Gideon Zweijtzer. I made another change,
because I was reminded by some other code I saw somewhere: looping back
some outputs to inputs (in particular CB1 and CB2). After all, in the
real hardware, those are connected with each other too, when they get
connected to their single input/output pin. So I connected things up
like so (in Verilog):

gideonvia6522 via
(
..
        .ca2_o(video_gfx),
        .ca2_i(1'b1 &(video_gfx | ~via_ca2_t)), // loop back output to input
        .ca2_t(via_ca2_t),

        .cb1_o(via_cb1_o),
        .cb1_i(1'b1 &(via_cb1_o | ~via_ca2_t)),// loop back output to input, but messes up viasr??ifr tests from VICE
        .cb1_t(via_cb1_t),

        .cb2_o(audio),
        .cb2_i(1'b1 &(audio | ~via_cb2_t)),    // loop back output to input, but messes up viasr??ifr tests from VICE
        .cb2_t(via_cb2_t),
...
);

*_o: output
*_1: input
*_t: output enable / data direction

so the idea is that if the output is 0 it can pull the input to 0 as
well. In my case I just put 1 as input so the input is either the output
(if active) or 1.

So I ran the VIA tests again, using the same reference data that was
once upon a time collected on a VIC-20. All tests now passed, *except*
the ones that involved the shift register and the interrupt flag
register (the viasr??ifr.prg tests from VICE
https://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/VIC20/via_sr/).

The failing tests all showed extra cases of "CB1 active transition" and
"CB2 active transition" flags in the Interrupt Flag Register.

Now this makes sense, since like I said, the input senses the output and
of course when the shift register is working, these lines change and
active transitions are bound to happen.

When I removed the loopbacks, all tests passed as expected.

The big question is, when testing on a VIC-20, apparently, somehow these
"active transitions" don't seem to happen.  The corresponding bits are
not set in the collected test data.

I see nothing in the chip dissection
http://forum.6502.org/viewtopic.php?f=4&t=7241
that indicates, for example, that these edge detections are disabled
when the shift register is active.

So why then?

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert                            <rhialto/at/falu.nl>
\X/ There is no AI. There is just someone else's work.           --I. Rose