> I'm not designing a heart-lung machine. If I were I'd be more prudent. In this case I'm designing a toy.

A very important point! We do see some very solid advice here on the forum which is appropriate for industrial-grade engineering, but that degree of rigour isn't always justified. It's still worth being careful which corners you cut, because an unreliable system isn't much fun to use or very easy to debug.

Voh of the AMD 27C256-55 EPROM I'm using is Vcc × 0.7 minimum, which is definitely in CMOS logic 1 territory.


Are you using any pins as nodes in the other project? I find it hard to believe that a 15ns GAL can't stay with a 15 MHz clock. Also worth noting is if inputs to the GAL are being driven at TTL levels instead of CMOS levels there may be delay over and above the nominal 15ns rating.


I was going to suggest implementing wait-stating so you won't have to get bogged down by the performance of the ROM, but I think you'd need an extra pin to use as a node to set up the flop needed to generate the wait-state. That would be in addition to the pin driving RDY on the 'C02. The 16V8 isn't going to cut it.

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

At what current draw? Most of these CMOS chips use similar output circuitry (I'm sure someone will step in to disclaim this) and will provide different Voh at different current draws. This really only makes sense. For instance, the ST Micro M27C1001 specifies Voh = 2.4V @ 400uA AND Voh = Vcc-0.7V @ 100uA. The 2nd spec is for CMOS environments - like we are talking about. I wonder what the spec for the W2457AK would be at a more reasonable 100uA rather than whopping 4mA?

No, no nodes. I can post the CUPL code if you wish. In fact, that restriction goes away if I use !WRB to drive /OE instead of !(Phi2 & RWB), but I did not mention that as it goes against the common wisdom. However, facts are facts - but ... whatever, right?

True - I have run out of real estate. A faster EPROM would be a better solution. BTW, thanks for that link. I ordered 5 of the 55ns devices.

_________________
Bill

For future reference, we have (by coincidence) had two threads going on at the same time both relating to glue logic and SRAM accesses:

Another semi-fail - again with the W65C02 (BillO thread)
Slower SRAM works but fast doesn't???? (dolomiah thread)

We've also in the recent past had another thread relating to CMOS 6502s and trouble with clock skew, which again looks a bit like a glue logic problem and uses some of the same kinds of reasoning to get to the bottom of it:

Project: semi-fail - suggestions please (BillO thread)

Perhaps it would be helpful to setup a sort of warning either as a pinned topic within the forum or perhaps within Garth's excellent primer. A warning to realize that the WDC 65C02 is not a plug in replacement for any 65(C)02. It only may work but the change in choosing a different timing origin (PHI2 instead of PHI2Out) is more important than (not only) a beginner may realize and can cause these strange "somehow it works but not fully" behavior.

Also mentioned in Garth's primer, but perhaps not prominent enough, the use of (too) fast components that may cause various trouble due to their speed when combined with slow signals and their impulsive current demands ("decoupling"). In the analog world of operational amplifiers and the like there the phrase "bandwidth of interest" is used. It should remind the designer to use appropriate components. Using much too fast components will nearly always end up in a redesign. This can be well compared to this (digital) world - using 10 ns RAMs in a 4 MHz design is not necessary and may cause trouble, slow 120ns types would be sufficient.


Arne