Hey Mark!
Thank you for your comment.
Of course I was so confident it was ok: I had checked it with my other working Issue 4A and it was oriented the same way! My luck was that last time I wanted to check it, it was reassembled and closed, and I didn't want to open it again!
Today I did some more investigation.
I exchanged the two ULAs and they worked as expected, they are both ok in the working Issue4A but they fail both on the board under test.
So next things to check are: Logic, in particular IC3 and IC4 (demux), TR6.
I still have doubts about the upper ram, I disabled it by forcing the \CAS low but this works if both the logic and the upper ram work.
Anyway, last thing to check is the CPU. Also we must be sure the ROM can be accessed from the CPU. It seems not easy but I think we can make some reasoning.
My first idea was to use my logic analyser (a Labnation's smartscope) to check each chip, this requires some decoding module (it can be written in .NET). I had just the time to test some gate of IC23, and it seems to work, though there might be some issue if the signals are too slow. I'm not sure how to interpret this... I'll see it later in the upcoming week.
As you suggested, it was interesting to check if the ULA is able to receive the commands from the CPU. This means to check \IOREQ from the CPU and the \IOREQ in the ULA. They are not the same signal, due to TR6. If I understand correctly, TR6 do fix a bug in the ULA, and \IOREQ in the ULA is active if and only if BOTH \IOREQ from the CPU and A0 are low. So it was important to check both signals. if \IOREQ on the ULA is never active, while it is on the CPU side, this means TR6 is failing.
And I found something really interesting. Well, I had 5 out of 8 lower DRAM chips populated, IC6 to IC10, while IC11 to 13 are unpopulated. With that setup I was able to see both signals, \IOREQ on CPU side and on ULA side. As expected, sometimes (with A0 HIGH) \IOREQ on ULA side is NOT active /H even if \IOREQ on cpu side is LOW. This means two things: TR6 works correctly and CPU is executing some program. Indeed I noticed some low pulse on \IOREQ every few seconds, as it should do a Diag ROM (remember it buzz the speaker to signal if a dram chip is failing or not).
So can we deduce the ROM is working as expected? it seems reasonable to me.
The other interesting and surprising part is that if I move a chip and populate IC13, 12 or 11 the pulses are not visible anymore. This was reproducible. So i found that some of the socket may have some bad contact. I checked it and after some working at least IC11 and 12 are fixed. I haven't tested IC13 still. Not sure how to interpret this, maybe something related to A0? I don't know.
Last thing to check is the logic. IC3 seems ok, I had a quick look to 2 out of 4 selectors and seems ok, nothin obvious. I need to check IC4. Last to check are IC25 and IC26 (but that shouldn't be a problem, if they fails), More important are IC23, IC24 and the Upper RAM.
IC4 is the perfect candidate for the problem I'm seeing. I noticed that while IC3 is a LS157, IC4, IC25 and IC26 are 74HCT257. Short of the LS/HCT difference (does it matter? Idk), there shouldn't be any difference, \E is always LOW so outputs are never in Z state and they should behave like LS157... right?
So I think I'll probably stop here with the investigation and blindly change IC3 and IC4 with two HCT157 or 257.
Ah, the clock is mostly ok. I say mostly because while in logic mode the oscilloscope shows some bounce. I don't know how to interpret this, but it could be also the instrument.
Bye and thank you
Standby alert 
