As we all know, the data sheet is pretty poor. Fortunately, it errs terribly on the conservative side, and things are way better than the minimum guaranteed, both in drive current and in timings. The WDC 65c22 I reported on before from the mid-1990's or so was only specified to pull up with 100μA to 2.4V (so I wouldn't say that's stronger than the processor bus drivers), and yet my experiment showed it was good to about two and a half orders of magnitude greater than that.
It had been a while since I last read the 65C22 data sheet, so I had a gander:
Each PA line represents a CMOS capacitive load in the input mode
and will drive two standard TTL loads in the output mode.
Two TTL loads doesn't at all sound encouraging. Interestingly enough, I seem to recall that back in the days when Commodore Semiconductor Group (CSG) was producing the NMOS 6522, they claimed the same output drive (two TTL loads). Yet I knew of people who had hooked up transistors to those outputs to control relays for one thing or another. I did something similar with my Commodore 64, which used the more advanced 6526 CIA. The CIA's output rating was the same: two TTL loads. Now I know the base current being drawn by the 2N4403 transistors I was using to drive relays exceeded two TTL loads, yet it worked and nothing failed. (I was using negative logic here: the CIA's outputs were sinking the base current, which had to be sufficient to achieve saturation.) However, I don't think I could have pushed it much farther, nor was I eager to see just what I could get away with. Changing out a blown 6526 was not a simple task.
With such bad data sheets, I think the only way to get the info you want is to experiment. If possible, take a working board with a good multilayer layout with power and ground planes used correctly--hopefully you have that already with V1--preferably with a PLCC if not PQFP, all so you're testing the processor itself instead of unwittingly testing only the board, and load it as close as possible to the processor, with chip resistors and capacitors (first one and then the other). I hope Daryl or someone else tries this too on his SBC-4 as well. I'd have to dig up info on your POC V.1 to be sure, but maybe there's some kind of memory-expansion connector you could build the artificial load on.
I'm using the watchdog timer's socket as the "expansion port." Unfortunately, the highest address line present at that socket is A4. A12 is available at the EPROM socket, but not RWB. RAM is soldered to the board, and is an SOJ32 package, so that isn't a good access point either. I don't know that I have a practical way to load all 16 address lines.
There have been times in the past that I have been pleasantly surprised to hear of people doing what the data sheets imply is impossible.
It's fairly typical in electronics that published maximum ratings tend to be conservative. In high volume production, you have to spec your product so reject rates are kept reasonably low. You recall in the early days of semiconductor production when manufacturers saw 40 to 50 percent good yield as excellent. That had quite a bit to do with what complex semiconductors like microprocessors cost back then. The yields have improved quite a bit since then, but much of that was a better way of rating parts so the majority of them would meet specs. That inevitably meant many would exceed specs.
The only thing is it's risky to base a design on an implied capability. The two TTL rating of the 65C22 is probably quite conservative, but would be expected to be conservative when one considers the volume of those things that gets made each year. It could be the 'C22 can drive 10 TTL loads. However, I don't think it could be expected in every case. I'm sure we can bet that there are going to be marginal examples now and then.
When I get around to building POC V2 I will have a fair amount invested in the project. In anticipation of building this more complicated (and more capable) device, I've upgraded my test bench setup (got a nifty refurbished HP 1725A 'scope with a 275 MHz rating, plus new probes) and gotten some other gear to facilitate the inevitable hardware debugging. While I'm always prepared for the possibility that it just flat won't work, more like it will be a case of "it sort of works," just like POC V1 did when I first got it going. Hence I'm being careful of not pushing things to a point where failure is likely. That means carefully anticipating the bus drive requirements so the thing doesn't fall on its face at anything higher than one or two MHz.
To find the point of maximum performance, I had even thought of trying to adjust the clock input duty cycle in case symmetrical is not quite ideal, and using an adjustable delay line for the '573 address-high latch enable, to go from a little ahead of the system Ф2 to a little behind it, keep adjusting, and check the frequency where it starts to have problems, adjust, check, adjust, check, until I'm satisfied I can't get any more out of it.
I'm not likely to ever try anything like that, simply because using a CPLD solves the propagation time issues, as well as the complex logic functions. I did work out timing at one time using 74ABT logic to drive the address and data lines, and concluded that memory logic timing violations would occur at about 15 MHz (the problem comes from the cascading of the bus drivers' prop delay with the memory decoding logic's prop delay). I've opined before that it can't be done at 20 MHz with discrete gates, and still believe that to be the case. In any case, a CPLD makes things quite a bit easier.
The Atmel AT1508AS CPLD I'm looking at is available in speed grades to 7.5ns, which is more than adequate for meeting all setup requirements with a 20 MHz Ø2 clock (actually, the 10ns part is fine). Since the AT1508AS can source or sink 35 mA per output (Xilinx has similar ratings for their 95xx parts) I'm also anticipating bus drive strength will not be a problem in those circuits controlled by the CPLD. All data lines will be through the CPLD in the linear memory model, since they can (should) be isolated from the MPU during Ø2 low, leaving only the A16-A23 lines "hot" during that part of the bus cycle. So the CPLD can act as a line driver, as well as a logic device. If I choose the segmented memory model, D0-D7 will not be through the CPLD, which means I might be forced to use discrete line drivers.
Not all MPU address lines would be connected to the CPLD (I'm not anticipating the need to decode memory all the way down to A0), so I may have a situation where some address lines, most likely A0-A7, would be connected directly from the MPU to system hardware. That's the bus loading about which I'm concerned. It also gives rise to a potential issue involving slew.
If A0-A7 are directly connected to RAM, ROM and I/O hardware, the hardware will see a change of state on those address lines before a similar change would appear on A8-A23, due to propagation time in the CPLD. I don't know that such slew will pose a problem, since there would be adequate time during the low half of Ø2 (25ns at 20 MHz) for the CPLD to work its magic, and in any case, no chip will be paying attention to what the address bus is doing until a chip select has been asserted. So the slew issue may be a non-issue.
In summary, there are few unknowns that can't be answered with implied capabilities. I'm inclined to think that using line drivers of some sort would be the safe route in assuring that bus loading won't sabotage timing as the clock gets bumped up. But I'm still mulling this over.