Today I received from [Nigel] an alternative ROM dump of another instance of the machine's PCU board.  This is from a later revision than [Rees'] and I refer to it as the [Tony] version.

There was some concern that Rees' dumps may have suffered bit rot since there were unrepeatable reads of the last ROM 8-2.  I did a casual diff and there were over 5,000 differences, so I had to dig in.

At length I found that there were a couple bytes of new code added fairly early in the image, but just that small change causes all the subsequent routines to move out a bit, and so there were a huge number of "benign" differences.

Locating the material change was a bit of a needle-in-a-haystack, but what I found was that [Tony's]
version simply disables 'mode 5' -- the planned-for-but-incomplete 'information' feature.  There was also some removal of a section of data lump later in an undecoded witchcraft script, but I suspect that it will be perhaps some menu text.  (This system is Japanese, so I can't read it with my eyes.  Oh, yes, btw, I'm pretty sure the character encoding is "JIS X 0201".)

While the loss of the feature is in some way sad (though the implementation is all still right there, and also you could simply put in the old roms to get it back), the stopper that was added put me on the track of the mode selection menu.  What was added was a test for a case of '5', which is ignored.  There were existing rejected cases of 0, 7, and 8.  So the coincidence of the number, plus the case 7 and 8, but no more, made me think that these numbers directly associate with the front panel buttons.  The buttons are soft keys with different meanings in different context, such as when you're using the 'mode 4' tape recorder.

Following along the path of variable-with-the-button number back to the hardware, I was able to piece together with high certainty that the buttons are simple SPST w/pullup on port 68h (8255c-a).  I also found the associated key scanner and debounce routine in sub_1A5F, which is invoked from isrCTCb0_1A48 -- the periodic timer ISR.

There is a debounce count of 4.  I tried to game out plausible debounce periods (e.g. I usually go for 50 ms myself) backwards to a sensible input clock, and the best solution I could find was 1 MHz.  I'm a little disappointed I didn't make it to the system clock of 4 MHz (as I was able to with CTCa-0 and -1), but there are some 7474's on board so maybe there is external division.  Just a guess.

As an added bonus, there are also front panel LEDs that light to indicate mode, so I was able to correlate them to another port 65h (8255b-b).  That is 5 of the bits, and since there are three more LEDs on the panel (indicating learning progress), I suspect that is the function of those other three.  (I don't know enough about the learning system yet to be conclusive.)

So!  Two PPI ports fully deciphered, and all without a physical sample.  Just puzzling though code.  (And OK the operating manual provide critical context.)

But I will hit a limit on what I can decipher from code alone, so I'd really like it if some of the folks with the hardware can do some buzzing-out and whatnot.  This gave me one of my kooky ideas:

• I should be able to make a custom firmware that puts the ports in a known state which can easily be verified with a multimeter.  E.g. There are three PPIs which I call 'a', 'b', and 'c' solely based on their port number in the code, but what physical chip is that?  What is the part designation?  Same with the CTCs.  (There's only one PIO, so that's unambiguous.)
• I wouldn't presume to configure any of the ports differently than what the actual firmware does in fear of causing some damage (though I doubt it based on the board shots), but each of those PPIs has at least one output port.  So notionally I could, say, set b7 high on one device, b6 high on another device, and b5 high on the other.
• This would be a lot faster than buzzing out the decoder logic, which plausibly is at IC 14, 16, 18, possibly with associated nearby SSI logic.
• Similar approach with the CTC's.  And if the tester's multimeter had even a rudimentary frequency counter function, then all the better.

Anyway, I don't know if I'll get any takers, but this did send me on a diversion of building a custom firmware for this purpose.  I can do that easily enough in assembler for something of this scope, but why not make things more challenging, and see if I can't get a C implementation working?

Oh, incidentally, I think IC 16 is for memory decoding more than port decoding.