6502.org

Yeah, I know, but just look at all the fun we're having!
Sold! Love your circuit.

The whole question of the right split between address setup time and pulse width is key ...

Address Setup time is quoted as 10ns for SC26C92 UART, whereas the minimum pulse width is fully 70ns! By those figures, it seems favouring the pulse width in the tradeoff may be best here. At 20MHz, a 25/75 split feels just right (100ns cycle with a wait-state), especially considering how quickly the WDC 65C02 gets an address on the bus. But the TTL CPU is much slower on that score. It takes 21ns for it to produce an address (in theory that is) and it really needs the additional setup time that a 50/50 split affords. However, that ratio likely would put the pulse width offside for the UART (I know the UART works with a 62.5ns pulse, but 50ns seems like a stretch). I need a 50/75 split
Me too! An extra half-cycle would be just great ...
Does "across" mean "in parallel with" in this context?
Currently, a wait state is only generated by the SBC if it's on the FAST clock. I think I can do the same when using RDY by adding a gate on the enable signal of the wait-state circuit. There is also a jumper which disables wait-states altogether when running with slower oscillators.
Yes! That little chip sure brings lots of subtleties along
Agreed. For sure that's a problem. It's tempting to only invoke the wait state logic for ROM and the UART. After all, the VIA runs just fine at 20MHz now on the SBC. But, that probably changes with the TTL CPU. It will likely violate the required address setup time for the VIA (as mentioned above, the TTL CPU will take 21ns to generate an address, leaving only 4ns setup time at 20MHz. That works for fast RAM, but everything else will probably need a wait state). Maybe the solution is to run the VIA with PHI2/2 all the time if wait states are enabled? That way, it won't double up reads and writes when it's chip select is asserted.
That's what the SBC does now ... and given all the complications above, I wish I could keep it that way!

But the problem with the current wait-state circuit in the SBC is that it takes too long to trigger (too many gates in series) and by then PHI2 has gone high already. It all works perfectly well at 16MHz with the 65C02. (Funny thing, a wait-state circuit that only works at slower clock rates ). At 20MHz with the TTL CPU, we only have 4ns after the address is stable to detect and trigger the wait state before the rise of PHI2 - a tall order I think. By contrast, the RDY signal must be brought low only before the fall of PHI2 - plenty of time for that.
It does seem one potential solution is to go ahead with an RDY wait-state circuit and add a second flip-flop to extend the wait-state to three cycles for the UART, one cycle of address setup and two cycles of pulse width. Or were you suggesting a hybrid approach, using RDY to pause the CPU but the also pausing the clock to stretch the pulse width in the middle of the wait-state?

Yes. One end of the capacitor goes to one end of the resistor, and the other end of the capacitor goes to the other end of the resistor.

Spent some more thoughts on making use of Jeff's circuitry.

IMHO running the 6522 with PHI2/2 isn't a good idea...
because if we would be (hypothetically spoken) using the SBC later for testing a TTL implementation of the 6526,
we can't test if it would be working at 20 MHz.

I'm attaching a schematic about how I would be trying to build the RDY wait state circuitry "if it would be my project",
the schematic adds wait states for UART and ROM access only:

Dang !

From the datasheet of the SC26C92C1A UART in the SBC,
it appears that /WE and /RD for that UART have to be active for >70ns !

With the schematic in my posting above...
if the CPU would be runing at 20MHz, /WE and /RD would be active for one cycle, and that's 50ns.

So the UART needs two wait states, and /WE and /RD need to be active in those two wait states.

Fortunately, Jeff did a circuitry for two wait states:




So after modifying my schematic to have two wait states, it looks like this:

Houston, we have a problem.

The W65C22 datasheet says, that address and /CS are supposed to be stable >10ns before the rising edge of PHI2.

If the CPU is running at 20MHz, PHI2 would be low for 25ns.

This gives a setup time for TTL CPU plus address decoder of <15ns after the falling edge of PHI2.

WDC datasheets might be on the conservative side, since there are rumors that a W65C02 could be overclocked to 20MHz.
That's 42.8% more than specified. When considering this for the W65C22 VIA timing:
There might be (in theory) a chance that >7ns before the rising edge of PHI2 might do for the VIA,
what would give CPU plus address decoder a setup time of 18ns after the falling edge of PHI2.

Maybe one would want to check if the TTL CPU works at more than 20MHz,
so we should consider the option to add a wait state for VIA read/write access.

On the other hand, if we would be (hypothetically spoken) trying to build a TTL implementation of the 6526 later,
it would have a setup time relative to the _falling_ edge of PHI2, and that's why we need jumpers to disable that wait state.

IMHO the best trick is to tinker with the VIA /CS signal, so the VIA still can be clocked with PHI2.

A little schematic of what circuitry might be required:

WDC says that at room temperature and 5V, the W65C02S will usually top out at 25MHz, although it's not guaranteed to, let alone to meet the timing specs at that speed. But someone here—I don't remember who—recently got it going at 16MHz at 3.3V, twice the specified clock rate for that voltage. Regardless, in all cases, the VIA's register-select, R/W, and chip-select signals have to be valid before phase 2 rises (as ttlworks said above). How long? 3ns? 5ns? 7? All WDC guarantees is that it won't be over 10ns at 5V and across the temperature range; so the way to be absolutely sure it won't fail for lack of setup time is to give it 10ns or more.

To be pedantic, just because you can overclock the CPU, doesn't mean you can overclock the VIA.

Well, overclocking by definition means no guarantees from the manufacturer; but they do give the same graph of possible speed as a function of voltage for both, with the line crossing 25MHz at 5V. The only way to really find out what you can do is to try it. My workbench computer has 4MHz VIAs, and I found no problems below 7MHz clock speed. I did the test with a variable-frequency oscillator, so I could set it at 6.95MHz, 6.99MHz, 7.02MHz, etc. for example, not having to go in increments of what the available crystal oscillators offered.

Is this the post you're thinking of? Windfall seems to being saying the WDC '02 and '816 both are capable of 24 MHz at 3.3V.
Certainly there's no guarantee. But, given that WDC's CPU spec is known to be very conservative, it isn't unreasonable to suppose their VIA spec might also be.

Wow, so it's considerably better than I remembered!

Dieter and Jeff, those circuits are great. Certainly MUCH simpler than any of my attempts! Thank you.
It's interesting to note that decoding the microcode in the TTL CPU costs 8ns to 10ns, which means that opting for Horizontal Microcode might have allowed for the setup time to be at spec. That's water under the bridge now, of course. As it stands, I think I can get an address on the bus in about 19ns, at best (vs. 15ns required to meet the spec). It'll be interesting to see what happens. Either way, including a VIA wait-state circuit in the SBC only makes sense, and it can always be disabled to test things. I like Dieter's idea to delay the onset of the /CS signal to avoid the double reads and writes.
Btw, Jeff, sorry, I forgot to highlight this clarification. I had in fact missed the subtle distinction that the "misbehaviour" has been in fact fixed and that the STA issue is actually another category of problem altogether - unfortunate though it is! Anyway, thanks for clarifying.

Thank you for bringing it up, and yes it's another category of problem.

It's well known that an extra cycle during indexing can indicate there's been a carry from the low byte, and this optional, extra cycle is when the complete address will appear. The wrinkle is it's only optional for read instructions (LDA, ADC, CMP etc). For STA -- a write -- the extra cycle always occurs. So, we might have:

• no extra cycle (indexing without carry: LDA, ADC, CMP etc)
• the extra cycle that occurs when indexing with a carry (applicable to STA, LDA, ADC, CMP etc)
• the extra cycle that occurs when indexing without a carry (applicable to STA)

.
In the latter case an NMOS '02 will read from the complete address then (on the extra cycle) write to it. And Drass discovered the 'C02 does the same. It'd be better to read using PC then write to the complete address, but the CMOS fix doesn't extend that far. The fix does kick in with a page crossing. Whereas NMOS reads from the partial address then writes to the complete address, CMOS reads using PC then writes to the complete address.

(There are other categories of extra cycles, of course -- they don't all result from indexing.)

I finally had a chance to implement the wait-state circuit above on the SBC, and only then did it dawn on me that it will not work with the TTL CPU after all. The problem is that the J-K flip flops require that chip-enable signals be available before the rising edge of PHI2, and that runs into the same issue as before: namely that the TTL CPU takes too long to generate an address and leaves no time for the downstream logic. At 20MHz, the /CS signals just don't get there in time.

But in fact RDY doesn't have to go low until just before the falling edge of PHI2 in order to take effect, so there is considerably more time here to react. Kicking the issue around with dr Jefyll and ttlworks produced the following alternative circuit:Notice in the timing diagrams that the /CS signal can arrive after the rise of PHI2, and the circuit allows it to continue through the OR-gate to bring RDY low in time to pause the CPU. The flip-flop then looks after bringing RDY high again in the subsequent cycle. As expected, a two-cycle version of the circuit chains two flip-flops together, and we can generate the delayed /RD and /WE signals for the UART just as before.

Similarly, the CE signal for the VIA can be delayed also as before to prevent spurious reads or writes to that chip. ROM presents no issue in this regard, but we do have to be careful with writes to RAM. Fortunately, the TTL CPU does supply a valid address just prior to the rise of PHI2 and the setup time for RAM is mercifully short. In addition, the single gate-delay between PHI2 and /WE provides a little additional comfort in this respect. All told, I'm fairly certain no writes to RAM can occur with an invalid address. Even so, fingers are firmly crossed on all this. The hope is that if the TTL CPU can actually manage 20MHz, it will do so with all supporting ICs fully functional.

Below is the circuit as adapted to the SBC, using just an additional 74AC32 and a 74AC175 to make it work. I've now run a couple of tests with the 65C02 on a breadboard and finished re-routing the SBC. (Incidentally, my only evidence that the RDY circuit works correctly is that I observed A15 cycling every ~32.5ms with the data bus fixed at $A9 and a 2MHz clock - 65,536 addresses at 500ns each - and then saw the interval double with single wait-states engaged. Not exactly proof, but it'll have to do). I also took the opportunity in passing to rewire the RS-232 ports as DTE ports and also made sure /OE is qualified by PHI2 for the UART, among other things.

... and, I'm happy to say, THAT IS THAT - all four cards in this crazy project are now ready for manufacture (REGISTERS, ALU & CU, K-24 and SBC cards). With some luck, I'll be posting a pic of a 4-board panel soon!

Cheers for now,
Drass

Just wanted to share the results of some testing I did as a follow-up to this in case others find it helpful. As I understand, this is a bit of a Goldilocks affair; we're looking for a resistor value that's not to high and not too low.

In my testing, I connected a pull-up resistor to simulate external circuitry holding RDY high and then triggered a WAI instruction on the WDC 65C02. Measuring on the RDY pin, I found a WAI instruction is able to pull RDY low even with very low resistor values for the pull-up. 220 Ohms seems to be the threshold. That is, RDY sits just at 1.35V when the CPU is in a WAI state and the RDY pin is being pulled high through a 220 Ohm resistor. A 470 Ohm resistor allows RDY to be pulled by WAI down to 0.6V while a 2k2 Ohm resistor allows RDY to go to 0.13V.

So, I think this says that a 470 Ohm resistor is high enough to make sure WAI still works. The question is whether it's also sufficiently low to make sure the wait-state circuitry can pull RDY low quickly when it needs to. I'm not sure how to figure out the time constants involved here. For reference, the wait-state circuit will need to pull RDY low in less than about 15ns for things to work well (assuming 20MHz operation and 7ns setup time for RDY). I gotta believe that's a comfortable margin in this instance.

Why are you making this so difficult? Use a small signal Schottky diode to isolate RDY from whatever is connected to it, along with a suitable pullup resistor in the 2.2K to 3.3K range.