6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 2:57 pm

All times are UTC




Post new topic Reply to topic  [ 50 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
PostPosted: Tue Jun 19, 2018 9:12 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
> 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.


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 20, 2018 5:15 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
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!


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 20, 2018 5:43 am 
Offline
User avatar

Joined: Fri Dec 12, 2008 10:40 pm
Posts: 1007
Location: Canada
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


Top
 Profile  
Reply with quote  
PostPosted: Wed Jun 20, 2018 7:15 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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:


Top
 Profile  
Reply with quote  
PostPosted: Sun Jun 24, 2018 12:20 am 
Offline
User avatar

Joined: Wed Mar 01, 2017 8:54 pm
Posts: 660
Location: North-Germany
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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 50 posts ]  Go to page Previous  1, 2, 3, 4

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 14 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: