Another semi-fail - again with the W65C02

For discussing the 65xx hardware itself or electronics projects.
User avatar
BigEd
Posts: 11464
Joined: 11 Dec 2008
Location: England
Contact:

Re: Another semi-fail - again with the W65C02

Post by BigEd »

> 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.
User avatar
BigDumbDinosaur
Posts: 9428
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Another semi-fail - again with the W65C02

Post by BigDumbDinosaur »

BillO wrote:
I should point out here too that the 27CXXX series EPROMs we all use with abandon are also only rated at a Voh of 2.4V - and at a much lower 400uA. :wink:
Voh of the AMD 27C256-55 EPROM I'm using is Vcc × 0.7 minimum, which is definitely in CMOS logic 1 territory.
Quote:
BigDumbDinosaur wrote:
Dr Jefyll wrote:
But it won't be necessary unless the GAL is pretty darn slow.
He's using a 15ns GAL, which is plenty fast for this application. The cumulative prop delay in my POC V1.1 unit is around 15ns and it will boot at 15 MHz with a 45ns OTP ROM.
Yet in my other project the 15ns GAL limits the speed to below 15MHz. On that one I can get 17MHz with using a 7ns GAL.
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.
Quote:
As it turns out I have decided to do away with the delay for this project. It works without it and at a speed much higher than I am going to rate the project. I need the extra output pin on the GAL for something more practical.
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!
User avatar
BillO
Posts: 1038
Joined: 12 Dec 2008
Location: Canada

Re: Another semi-fail - again with the W65C02

Post by BillO »

BigDumbDinosaur wrote:
Voh of the AMD 27C256-55 EPROM I'm using is Vcc × 0.7 minimum, which is definitely in CMOS logic 1 territory.
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?
Quote:
Quote:
Yet in my other project the 15ns GAL limits the speed to below 15MHz. On that one I can get 17MHz with using a 7ns GAL.
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.
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?
Quote:
Quote:
As it turns out I have decided to do away with the delay for this project. It works without it and at a speed much higher than I am going to rate the project. I need the extra output pin on the GAL for something more practical.
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.
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
User avatar
BigEd
Posts: 11464
Joined: 11 Dec 2008
Location: England
Contact:

Re: Another semi-fail - again with the W65C02

Post by BigEd »

For future reference, we have (by coincidence) had two threads going on at the same time both relating to glue logic and SRAM accesses: 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:
User avatar
GaBuZoMeu
Posts: 660
Joined: 01 Mar 2017
Location: North-Germany

Re: Another semi-fail - again with the W65C02

Post by GaBuZoMeu »

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
Post Reply