6502.org

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.
I'm confused. Page 7 only illustrates the data retention characteristics. The write timing diagrams are on page 6.

Turning to page 6, of interest (to me) is the SRAM's Tdw specification, which is the amount of time the data bus must be stable after the rise of /WE. The corresponding 'C02 spec would be Tdh, the MPU's data hold time at the end of a write cycle. WDC says that is 10ns after the fall of Ø2. Tdw is 30ns minimum.

Going by those numbers and the SRAM's write timing diagram, it would seem that the SRAM is too slow for the 65C02 at any Ø2 frequency—Tdh is generally not a function of clock rate. If my theorizing is correct, the 'C02 will stop driving the data bus 20ns before the SRAM is finished sampling it.

Incidentally, in the ISSI IS61C1024AL 128KB SRAM I used in POC V1, the equivalent spec to Tdw is 0ns—which implies the SRAM's internal data sampling timing is anchored to when /WE is driven low. That is a lot friendlier when combined with the 65C02 than the Tdw spec of the SRAM you are using.
Again, if my theorizing is in the ballpark, the deliberate timing sandbagging is compensating for the discrepancy between the SRAM's Tdw and the MPU's Tdh specs, thus achieving operation.

With the WDC MPUs, the best results are going to be obtained by not qualifying device selection with Ø2. That is, device selection should occur as soon as an address that is understood by the decoding logic is present on A0-A15. Reading and writing should be separately controlled as illustrated in the circuits earlier published by Jeff and me. You shouldn't have to be doing funky things with Ø2 just to get an SRAM to work.

I think your analysis is exactly what is happening. Aside from the brief period of bus contention that you described, the SRAM will take some time to "turn around" once /WE is driven low. The SRAM's performance under such a scenario is not described in the data sheet, but could be implied by chaining the tail end of the read (/OE is low) timing to the head end of the write (/WE is low) timing. I could foresee that by the time the SRAM has gone from being a "talker" to becoming a "listener," the MPU may have completed the write cycle...and who knows what the SRAM will be hearing.

A situation similar to what Jeff described could arise when accessing I/O hardware. This could be even more problematic, since it's not uncommon for a read of a given I/O device address to access a different function in the device than a write to the same address. This is all the more reason to gate /OE inputs only when the device has been selected and the expression RWB && Ø2 is true.

This has made me curious, a RAM that does not need any setup time? I downloaded the datasheet and found the corresponding parameter tSD ("Data Setup to Write End") to be 7 ns minimum.
I think this setup time is a sort of propagation delay including a safety margin. And this means simply it takes 7 ns (worst) for a level change to travel down into the memory cell. But it might travel faster. If you assume 50% safety margin due to 50% fabrication process tolerances then (7 ns / 1.5) * 0.5 = 2.33 ns could be possible (same temperature, same voltage).

This means it is very necessary to have precisely timed /OE and /WE signals. The CPUs data hold time after write add a little "headroom" so a single gate (a fast one of course) delay would be compensated but not much more.

Knowing this I would recommend to use your clock generator combined with Dr Jefylls suggestion (One could use the Phi1 output and the fourth AC00 gate to generate the Phi2.)

my 2 cents

I had thought of that before Jeff. I had done exactly that, using the inverse of /QW to drive the OE on the RAM and ROM. It was the original configuration and it didn't work. In fact it was a bit worse as, while I was still able to cold boot to BASIC, I was not able to run any commands like LIST or PRINT without parameters.

The only difference at that time was in using the crystal based clock rather than an oscillator.

Not that I don't see your logic, but I'm fairly sure the 15ns delay in the GAL is a killer one way or another.

Let me see what I can do with what I have and try another test to make sure, but I can either have the delay in the clock going to the CPU or I can have the /RD signal - not both without physically expanding the board.

Sorry folks - I directed you to the wrong datatsheet. The memory I am using is W24257A : https://courses.cs.washington.edu/cours ... 24257A.pdf

You will find the speed I quote and the correct page are there.

Again, sorry ...

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.

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.
Agreed - however I am not doing that so I'm not sure why the mention.
I don't think taking the propagation delay out of creating a qualified write is doing anything funky. If that were the case then using 0 propagation delay logic (if such a thing were available) would be doing something funky.

IN any case - I'm going to try again to use the original configuration with the oscillator to see if that fixes the problem, however I still think 15ns delay is just too much.

The inverse of /QW isn't satisfactory, I'm afraid, or else I'm missing something. During the first half of a write cycle /QW will be high because it's qualified by PHI2 -- isn't that right? So, inverting that, you're putting a low on the /OE -- which leaves us with the scenario I described, or something slightly gnarlier (because /OE does eventually go high, but the damage is already done). What you want is to drive the /OE pins low only when Phi2 is high and RWB is high.

-- Jeff

OK ... so you want /QW to be !(phi2 & !RWB) and /QR t be !(Phi2 & RWB) as per the accepted logic. That should be easy to test and I can do it now.

Be right back....

Update:

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!!).

Thanks everyone. This has been a good experience.

What is the opinion on the delay to the CPU? The timings look a lot better that way.

edit: oops, your update makes this post semi-obsolete. I was going to ask for a drum roll to help build suspense!

If you'd still had trouble then the next step would've been this (or the equivalent): But it won't be necessary unless the GAL is pretty darn slow. I agree with BDD's remark somewhere upthread. Generally speaking, getting a RAM to work shouldn't require extraordinary measures.
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. 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. However, other duties call right now.

It just makes sense that a 0ns effective delay would be better. No?

Great result! Is there any way, or any place, where we could capture what the hazard is and the knowledge as to how to make everything work? (Indeed, now we have an answer, does it turn out that there's anything missing or misleading in the common references?)

Well, I've had enough humbling experiences to become cautious about unsupported conclusions. For example, the effective delay might not be what it seems. Scoping the inputs will show you when the chips are being told to do stuff, but it doesn't reveal how promptly they respond. All that said, here's my take. (Using the CPU clock as our reference, let's speak as though it's the /RD and /WR signals which are being advanced or retarded.)

Advancing /RD and /WR means there's less time for the memories to do their job, so that places a limit on the "early" side. Delaying /RD and /WR means they may still be active after the cycle ends and CPU has begun presenting a new address, and obviously that limits how late things can be (you don't want any spurious accesses).

Another question to ask is, which set of symptoms might might be hardest to detect and thus cause the most grief? (Assuming, I mean, that you prefer "seat-of-the-pants"ing it and/or overclocking, as opposed to a rigorous study of all the propagation times.)

Ah-hah! That's more like it. That SRAM's timing should make it a no-brainer to interface to any 65xx MPU.
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.
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.
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.
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.
Faster EPROMs are available if you are inclined to spend a little money. The link ROM is what I've been using.
You may discover that the EPROM generates more noise than the SRAM.
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.

OMG

I thought all the time the hazzle was a briefly too late rising edge of /WE (or /OE) and therefor vanishing data.

Mea culpa

Strictly speaking, of course. That spec is also for supplying 4ma. That's quite the load. Actually I know a Prudence. If I had a RAM chip that couldn't cut it Pru would dictate that I toss out the malcontented chip in favor of one more willing to play. I do understand what your saying BDD, but I'm not designing a heart-lung machine. If I were I'd be more prudent. In this case I'm designing a toy. I've used these a lot with various different CPUs, as well as similarly spec'd AS7C256s and KM68257s and others... I've yet to find one that won't get the job done. 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.
I'm partial to easy-over fried. I just find, unless I do them myself, people generally couldn't scramble eggs to save their lives. You'd think it would be easy but it seems what is easy is taking perfectly good eggs and making yellow sawdust from them.
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.
I'll look for that too but the max draw on the SRAM 150ma (a lot less in reality - but ... 'specs') and that of the EPROM is only 20ma.
I'm not so sure contrived is the right word. It may seem that way as it's never been seen done before with a 6502 system, but exactly such things are done all the time in high speed electronics and experimental physics (where my training is).

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.

Me too. But hey, in our defense, fixing that did get the thing going!