BillO wrote:
BigDumbDinosaur wrote:
That's a 70ns SRAM that generates TTL-compatible outputs, not CMOS levels. In theory, the Voh minimum of 2.4 would not represent a valid logic 1 to the 65C02. We've had discussion in the past as to whether the WDC MPUs in fact recognize a TTL logic 1 as valid.
Sorry folks - I directed you to the wrong datatsheet. The memory I am using is W24257
A :
https://courses.cs.washington.edu/courses/cse477/99sp/docs/W24257A.pdfYou will find the speed I quote and the correct page are there.
Ah-hah! That's more like it. That SRAM's timing should make it a no-brainer to interface to any 65xx MPU.
Quote:
I know it states minimum Voh as 2.4v, but I have never seen these chips output less than 4.2v in practice. It is, after all a CMOS chip and a Voh of 4.2v will certainly meet TTL input specs so there would be no need to cripple the output drive of them to reduce them to 2.4v.
The problem is that you can't bank (no pun intended) on the device producing anything higher than
Voh. A number of factors that are out of your control affect
Voh, not the least of which is normal variances in the manufacturing process. Therefore, prudence would dictate designing to the worst-case, which would be
Voh = 2.4.
Quote:
Surely Tdw is only valid while the chip is selected? As I said, the chip select was going high before the end of the write cycle - that can't be correct either.
Tdw is based on the (reasonable) assumption that the device will remain selected until the completion of the write cycle. If the order of things is reversed—
/WE is still low when
/CE goes high—a technically undefined condition has been created, "undefined" meaning
Tdw as specified can no longer be used.
Quote:
Ahhh, the sweet feeling of egg on my face. Well, that works just dandy at 14MHz with or without the delay to the CPU (even with a 120ns ROM!!).
Were those eggs scrambled or fried?
As I earlier said, you shouldn't have to do anything funky with the Ø2 signal just to get an SRAM working.
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.
BillO wrote:
Dr Jefyll wrote:
Quote:
What is the opinion on the delay to the CPU? The timings look a lot better that way.
I presume you mean a delay like what's in the diagram above (right?). And I don't have an answer. Looks can be deceiving. What's more credible is an actual test. (Example: max achievable speed. Or, spikiness on the supply rails.) But if there's no demonstrable downside then yeah, go for the nice looking waveforms!
Yes, I mean a delay as in that diagram.
Max speed is 14MHz, but I suspect that 120ns ROM is the limiting factor as I can get to that speed with or without the delay. Unfortunately I do not have a faster ROM to fit this board.
Faster EPROMs are available if you are inclined to spend a little money. The link ROM is what I've been using.
Quote:
I'll test for spikiness both ways although this fast RAM draws a lot of current and is usually the source of any spikes when it's selected or deselected.
You may discover that the EPROM generates more noise than the SRAM.
Quote:
It just makes sense that a 0ns effective delay would be better.
I see no reason to introduce any contrived delays. You've already proved that your machine will work without them.
Using a PLD, the pin-to-pin delay is usually a fixed number that is theoretically unaffected by the complexity of the logic within. Your GAL is rated at 15ns pin-to-pin and in your application, you aren't using any pins as nodes. Hence chip selects will appear 15ns after the 'C02 has driven
A0-A15 to a stable state and your
/RD and
/WD outputs will uniformly lag Ø2 by 15ns. Given such uniform timing, circuit behavior is quite predictable and should remain so right up to the 65C02's 14 MHz official maximum.