Just to make sure we're communicating: You can still do it. You wanted 4K for the I/O. Use A15-A12 (that's four lines) to select that block, and use A0-A3 (four more lines) for register selects. That leaves A4-A11 (that's eight lines) for device selection, one address line per device. Since your I/O ICs don't have two chip selects like 65xx ones do, although it would take more room, you can reduce the propagation delay time by replacing the '138 with a 2-input gate for each IC, and use one input for the I/O block enable and one for the respective address line.

I don't get too particular about trying to give early address qualification for RAM. SRAM is the fastest of all the major parts we put on the board, available down to 6 or 8ns. Additionally, when you push the limits of a 65c02 (going beyond the specified max), the address is valid and stable almost no time before Φ2 rises anyway. Doing it BDD's way is good practice if the goal is to run absolutely as fast as possible; but I really don't see it making a significant difference when you'll run into speed limits on other things first.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Hi Garth - thanks, yes absolutely on the same page as you. I used different terms but yes I can see how the 16 address lines can be portioned up - 4 bits IO block decoding, 4 bits register select, and 8 bits for each IO select line.

It's just that I've already got a working set up - it's been working for a few months until this problem with the 6522 cropped up, which I've corrected. So changing the decoding again would be good in that it's more efficient and elegant, but can get round to doing that after a few other things which I need to do, mainly around the software.

I'll post some pictures up of her working with basic software. But now I have a little worm burrowing in my head knowing that the decoding scheme I currently have could be better