6502.org

True enough... it would be nice if Microchip would put a bit of effort into WinCUPL to fix some of the bugs and issues. I recently had it corrupt two PLD projects... of course I had backups, and after deleting and reinstalling WinCUPL, all was back to normal, such as it is.

Needless to say, "anything" contained in a comment string should be ignored...

Why would they want to spend money maintaining a 30 year old product that is distributed free and is probably only used by hobbyists who don't buy large quantities of chips? There's just nothing in it for them. They would rather force everyone to spend a fortune on ProChipDesigner.

I haven't been keeping up with this, but I will say that it was genius on Microchip's part to offer free development software and cheap programmers for their microcontrollers almost 30 years ago when they were coming up, and sell in hobbyist quantities, in a time when the other microcontroller manufacturers were charging heavily for tools and not "wasting their time" selling to hobbyists. [*] What happened is that a lot of hobbyists picked up the PIC microcontrollers and learned them, and then took them into their work projects which resulted in huge sales volumes. As for the employers and Microchip client companies, cost savings, training requirements (or lack thereof), and time to market motivated them to let their employees develop with a microcontroller they were already familiar with. It was a win for everyone but the competition.

[*] One manufacturer specifically told us in 1993 that our company was too small for them to be interested in working with us. That was National, with their COP800 line. That mentality apparently made them lose the microcontroller business.

I can agree that from a financial view, it doesn't make sense to fix WinCUPL. However, when people start looking at development tools, if a vendors "free" or trial versions are either buggy as hell and/or difficult to use, that will usually result in the end-user looking elsewhere for tools... and the same will likely go for hardware, especially if the hardware is proprietary and linked to their development tools. Who wants to spend a large amount of cash just to find out that the licensed version is every bit as bad as the trial or free version?

I think the larger issue these days is that most software companies are forcing a subscription model... so you always have defective/bug-infested code that you have to continuously pay for while the company strings their user base along. My son is a 3D Digital Animator/Technical Artist by trade. He's fed up with Adobe and AutoDesk, both of whom have gone to an expensive subscription model and their code is much worse now than ever before... and their current level of support is also horrible, to the point of being useless. You pay thousands every year and have the equivalent of alpha or beta level code to work with... crashes and all.

"Conservation of bugs" is one of those universal constants, so I rather work with older software that have known bugs than constantly updated software that fixed known bugs but introducing new (unknown) bugs. My lab computer runs Windows Vista; my CPLD design tool is Quartus version 8 which is about 20 years old; and my PCB tool is WinBoard/WinDraft whose last software update were 23 years ago.
Bill

Hmm, I don't understand this bit:
> The MPU is running at 20 MHz, not 40, which means the GAL is reacting to events that occupy two oscillator cycles, not one. That 8.1ns margin is based upon the 40 MHz half-cycle period, which is 12.5ns. The Ø2 half-cycle period is 25ns, which effectively makes the 8.1ns look like 4.05ns.

I wonder, is there another way to describe this, or draw it out?

I think the extra piece of the puzzle is the propagation delay from 74AC163 clock high to processor PHI2 low.
From your schematic the worst case timing path is as follows:
(i) 74AC163 clock high to QD low
(ii) 65C816 PHI2 low to address valid
(iii) 74AC573 input to output propagation (for A16)
(iv) 22V10 input to output propagation (An to WSE)
(v) 74AC163 setup time B valid to clock high

From the data sheets (or reasonable guesses) these values are (typical, worst case):
So your circuit's typical max frequency is 1/29.4ns which is ~34MHz, so 17MHz CPU clock.
Worst case timings give max frequency 1/50ns = 20MHz, so 10MHz CPU clock.

My suggestion would be to use a CPLD and try to put everything - the clock divider, clock stretch logic and address decoding on there.

Or, another possibility is to use RDY for wait states instead of clock stretching. That gives an extra half cycle for the circuit to figure out if wait states are needed, at the expense of a more complicated circuit to generate the bank latch enable signal.

You could get the benefit of RDY without the hassles by using a more complicated state machine for clock stretch.
Suppose you have 4 states S0-S3, S0 is the initial state. The state machine is clocked by your double-frequency oscillator.
The transitions are:
S0 always goes to S1
S1 goes to S0 if WSE is not asserted, S2 if it is
S2 always goes to S3
S3 always goes to S0
The CPU clock is high in S1, S2, S3 and low in S0.
That would give you the same clock stretching behaviour as now, but you have until the point where the unstretched clock would fall (minus a setup time) to generate the WSE signal.

This could be implemented using the AC163 plus a couple of gates:

input D = 0
inputs A,B,C = 1
QD feeds PHI2
/LOAD = !(QD & \WSE) & !QB

So the counter starts with count 7, counts up to 8 then reloads 7 if WSE is not asserted. If WSE is asserted it counts up to 9 then 10, then reloads 7, thus stretching the high phase by 2 oscillator clocks. By rejigging things a bit you might be able to put the /LOAD logic into the 22V10.