In POC V2's logic, RDY is driven high at the time when the wait state expires, but only for one clock cycle, after which the CPLD pin that controls RDY goes high-Z. By the time the MPU is ready to fetch the next opcode RDY is being pulled up solely by the (3.3K) pullup resistor, hence a WAI instruction can't produce contention with the CPLD.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

That's probably what I'll do then (once I wrap my head around how exactly to do it)

Thinking something along the lines of


This should drive RDY high for only half a clock cycle after the wait-state expires
Simulation:

Yep it works!

The waveform isn't pretty for some reason, due to the pull-up maybe?
ROMCS looks fine in comparison

I'm guessing the over/undershoot is due to the slew rate of the CPLD?

These over/undershoots and perhaps these rectangle dips in the first long "1" period (second picture) may be caused by a poor selection where you connect the ground clip of your scope probe. E.g. if you take GND from the supply it would look that kind.

If you solder a short wire (a lead from a resistor or similar) to one of the decoupling C's of your CPLD or the CPU and clip your probes GND there then things should improve. If not I would assume the power supply is not well decoupled (= too few 100 nF's here and there).

I see two potential problems.

What happens if a WAI instruction is fetched from a memory chip (eg: a ROM) which is subject to wait states? For discussion's sake let's assume the CPLD adds just one wait state on each ROM access. There'll be no problem during the two cycles it takes to fetch the WAI opcode, nor in the two cycles it takes to fetch the following byte. But then the WAI takes effect, and the CPU freezes. It continues fetching that same byte again and again, still triggering a wait state each time. Unfortunately, it also pulls RDY continuously low, thus intermittently butting heads with your CPLD -- which as you say is driving high during the cycle after each wait state expires. So: contention.

Maybe you and/or LIV2 don't intend to execute WAI from ROM, in which case there's less cause for concern. Still, it's worth remembering that WAI may execute unintentionally. A programming error or electrical noise could crash the computer and cause it to execute data... possibly from ROM, and possibly including the fateful byte $CB!

Another concern pertains to the case where WAI is used intentionally. IOW it's expected that eventually an interrupt will arrive and un-freeze things. At the appropriate time the CPU will stop driving the RDY pin low, and somehow the pin needs to be pulled high. But in this circumstance the CPLD presumably doesn't assist, and the job of pulling up is left entirely to the 3.3K resistor, which is too weak to do the job promptly.

I like the creativity of your active-pullup idea, and it may be a satisfactory choice in some situations, but it's not seamlessly foolproof to the extent that simply using a low-value resistor is.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I probably didn't adequately explain it.

During Ø2 low, the '816 establishes an effective address and indicates that to the CPLD logic via the VDA and VPA outputs. The CPLD logic, in addition to generating and latching A16-A19 at that time, is looking at the effective address to determine if it is in a range for which wait-stating is necessary. The logic to make that determination is relatively simple: A16-A19 must be %0000 and the selected device must be ROM (either $00C000-$00CFFF or $00E000-$00FFFF) or I/O ($00D000-$00D7FF).

Assuming a wait-state is required, a latch is set to indicate that a wait-state is to occur and a pair of flip-flops is clocked by Ø2, starting the wait-state sequence. The Q output of the second flop is used to drive the CPLD pin connected to RDY and at the time when the wait-state latch is set, that pin is brought out of the (normally) high-Z state. As the second flop's Q is low at that time, RDY is driven low and if one can believe the 65C816 data sheet, the MPU will halt on the next fall of Ø2.

It will take another full transition of Ø2 to get the second wait-state flop to transition, which will occur on the second rise of Ø2. Up to that point, the MPU hasn't progressed beyond the opcode fetch part of the instruction cycle due to RDY be continuously low. As soon as Ø2 goes high at the end of the wait-state period, the second flop's Q will go high, driving RDY high, restarting the MPU. On the next fall of Ø2 the wait-state latch will clear, causing the CPLD pin driving RDY to return to the high-Z state. This happens at the end of the opcode fetch part of the instruction cycle.

WAI executes in 3 cycles, and the MPU doesn't drive RDY low until the 3rd cycle. Also, during cycles 2 and 3, the expression VDA || VPA is false, indicating to the CPLD that no valid address exists on the buses. Hence even though the program counter is still pointing to ROM (assuming the WAI instruction came from ROM), the CPLD will not initiate another wait-state while the MPU is WAIting. Furthermore, RDY at the CPLD is at high-Z during the second and third cycles of WAI, eliminating any possibility of contention.

It should be noted that part of what WAI does is to internally stop the Ø2 clock—Ø2 internally remains high, which causes the MPU to cease to do anything at all until a hardware interrupt is detected. At that time, the internal clock is restarted and the next instruction will be fetched during the next rise of the external Ø2 clock.


That is a distinct possibility. At best, RDY's lazy return to high will somewhat delay the restart of the MPU. More ominously, if the WAIt was programmed with the intention of achieving single clock cycle response to an interrupt that might not come to pass. Obviously, careful PCB layout is necessary to try to minimize parasitic capacitance in the RDY circuit if reliance on the pullup is the sole means of returning RDY to the high state.

Another possibility would be to somehow make the CPLD aware of when the MPU pulls down RDY and have the CPLD temporarily come out of high-Z and drive RDY high again when the WAIt is over, doing so for only one Ø2 cycle. I haven't tried wrapping my head around what that would require in the way of logic.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I guess I'm at a disadvantage since I'm using a 65C02 but waitstating is currently only briefly used while copying ROM to RAM then no longer used.

As an alternative you may think about clock stretching. In your case it is perhaps easier to do the copy with half speed and then open the throttle

This perhaps: http://forum.6502.org/viewtopic.php?p=11796#p11796

That's a pretty neat method thanks for posting it

For this iteration I'll probably make do with the high-z after half cycle method and maybe just add a second parallel resistor to change the pull-up to about 1K as I've already sunk money into these PCBs which weren't cheap. There are other mistakes that were made too (like the tactile button footprint I used was wrong and permanently held RST down...) but I'll have to bodge this one up and make do.

A couple of lessons learnt for next time when I'll hopefully build one with no silly mistakes!

Yeah, for you the '816 stuff isn't entirely pertinent, although it is a related topic. The subject of clock stretching is also interesting, and more relevant, but even that you can ignore if you like.

I think you'll have smooth sailing if you simply persevere with your original plan. Your only problem -- aside from the unscheduled learning experience regarding the oscilloscope probe! -- was choosing a 3.3K pullup (which is much too weak). As an experiment, don't be afraid to try 470 or even 220 ohms, and see how that looks on the 'scope.

In any case have fun, good luck, and keep us posted!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Thanks!

Yeah unfortunately I didn't even think about the pull-ups, having used them since breadboarding 6502s a couple of years ago it never occurred to me that it was fine for 1Mhz but maybe not 10!
Which leads me to another question, should I also be using lower values for IRQ,NMI,BE etc? I assume at least for IRQ it doesn't matter too much as long as the signal goes high before Interrupts are re-enabled and I don't currently use BE or NMI.

Yes, that's right -- with IRQ you only need it to go high sometime before Interrupts are re-enabled -- which'll be at least 9 cycles. In contrast, the RDY thing has to happen in less than one cycle. And, as you say, the cycles tend to be shorter if you switch from 1 MHz to 10 !

One thing bugs me regarding the low-value pullups I've been advocating, and it has to do with the lack of certain info in the WDC datasheet. Specifically, how much current can the internal open-drain buffer driving RDY sink while still maintaining a valid logic low (keeping in mind that the definition of logic low varies between families)? The datasheet does have figures pertaining to TTL; it says with Vdd=5V an output is guaranteed to sink at least 1.6 mA at 0.4V. But that's not helpful; in this case TTL has no relevance. What I'd like to know is how much current can RDY sink while maintaining a CMOS logic low of 1.5V? (RDY as an input expects a logic low to be no more than 30% of Vdd.)

"1.6 mA at 0.4V" corresponds to a pullup of 2.875 k, but clearly it's feasible to use pullup resistors much lower than that, simply because 0.4V is not the relevant figure. Unfortunately, if we want to know the lowest possible pullup resistance we need to extrapolate from what's in the datasheet or else run an experiment. To me that doesn't seem like proper engineering, and I wish the situation were otherwise.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Much better with a 1K pull-up, I even tested with WAI to makes sure the CPU could pull the line low and no issues it seems

Good to hear it's working! Shortly before you posted I edited my own post that precedes yours, replacing the rant-y portion with a more restrained explanation of the difficulty with the datasheet. Now here's an attempt to extrapolate from the datasheet's incomplete information.

From the datasheet we know the CPU's internal open-drain MOSFET -- the one which pulls RDY low -- can sink at least 1.6 mA while rising only 0.4V above ground. That tells us the On Resistance of the MOSFET is 250 ohms or less. If we (somewhat naively) assume the 250 ohm figure remains constant then we can infer the MOSFET is able to sink at least 6 mA while holding RDY down to 1.5V (recall that 1.5V is our upper limit for a CMOS logic low). Then we determine the lowest permissible pullup resistor, which is 3.5V / .006 A = 983 ohms -- fairly close to the 1K value you successfully used, LIV2.

Alright, there'll be some inaccuracy resulting from the flawed assumption that the MOSFET continues to act as a 250 ohm resistor despite the change in conditions. But the change in conditions is fairly small, so I think the 983 ohm figure ought to be close to the mark. I've extrapolated from the available spec to a different spec that's more relevant.

Also I believe there's a large safety margin, based on anecdotal reports indicating the CPU outputs are much stronger than than specified. This suggests the actual minimum usable pullup value is considerably lower than 983 ohms.

Anyone care to elaborate on these thoughts, in support or otherwise? Comments welcome -- thanks!

Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

All good I didn't take it as a rant anyway!

I tried testing various resistances with a trimpot but then my computer stopped working and I thought I'd damaged something. turns out my USB-Serial adapter was just playing up

At some point when I am not feeling so lazy I might give that another try