All valid points, but the difference is that I can at least acquire the different library versions I need whenever I need them. I'm a GoboLinux user at home and a Slackware user at work, so I still have to manually fulfill dependencies. Inconvenient, yes, but I have a full understanding of my system in exchange. I'm willing to pay that price.



No, I fight that too. I just don't fight those battles here.

Righto. I was not thinking in terms (no pun intended) of exposing the flops to the world at-large.


Yeah, it isn't made very clear in any of the CUPL narratives exactly how to reset a flop. I saw an example in the Atmel WinCUPL help documentation on explicitly resetting flops. In the places where we would use something like this, the sync reset is not an issue. It might be for a state machine, however.

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

Technical note: inserting a diode in series with the RDY signal isn't likely to work as expected. The 16V8 pulls outputs down to 0.5 volts when they are low. Forward drop on a small-signal diode, such as a 1N4148 or 1N4152, is typically at least 0.6 volts at the current levels involved. WDC says in the W65C816S data sheet that RDY has to be pulled down to Vcc * .2 or lower, which would be 1.0 volt or less, assuming Vcc = 5. Subtract the diode drop from that and you have a requirement that the GAL sink its output to 0.4 volts, which it can't do. So the wait-state will work but the MPU won't see it. Skip the diode and just make sure the GAL's RDY output is tri-stated when no wait-state is in progress.

incidentally, a series resistor won't help. It would have to be no more than 220 ohms, and if the MPU executed WAI with the GAL output high, 20 MA would be drawn through the MPU, which, it would seem, is well beyond the MPU's capabilities.

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

I expect (but don't know for sure) that the processor's pin drivers are the same as the VIA's, and I found by experimentation that WDC's could pull to within 0.8V of the rail with a 220Ω load to the other rail, even pulling up. It was symmetrical. A dead short gave a 50mA pin current, meaning there's a current-limiting mechanism and it cannot be modeled as a simple resistance. Rockwell's on the other hand could only give 15-20mA trying to pull up with a short to ground but 100mA trying to pull down. That's the current for a single pin, not for all pins of a port combined. This is why I have discouraged the use of separate bus drivers on a 65c02. The NMOS 6502 OTOH had a pretty measly drive capability.

Using resistors however is a no-go in most situations because of the resulting time required to charge bus capacitances.

I asked WDC to clarify how much current RDY can sink. Meanwhile, I concur on the resistor's effect on slew rate, although 220 ohms wouldn't do much in that regard. In the CPLD code I've written for POC V2, I've arranged to tri-state RDY when not active. The external pullup for RDY is 3.3k, so slew rate should be very good.

Incidentally, buried in the '816 data sheet is a caveat about how WAI will not function as expected if RDY is forced high. In such a case, the MPU will execute WAI and then immediately move on to the next instruction, rather than wait for an interrupt before continuing.

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

Their specifications have always been a bit out to lunch, and fortunately in the way that the parts do much better than they say. In the case of this current that I measured on the VIA, the actual current was about an order of magnitude better than they guarantee for pulling down, and almost two orders of magnitude better for pulling up.