That article is great, thank you!

lol, this is me: "Since few designers understand, let alone consider read/write timing, it is a wonder that most microcomputer systems work at all"

I will keep experimenting.

Here are a pair of traces. The bottom one is the original setup using phi1-qualified writes, where I get this phantom write occasionally. The top one is the working setup using /phi2-qualified write, where phi2, /phi2 are symmetric outputs from halved clock via hc74 flipflop. Vertical scale is 2V (0-5V signal), horizontal is 10ns.

Both traces capture a rising edge of /MW which is /WE on the RAM AS6C1008. From the RAM datasheet this is what locks the actual write. It seems to want 25ns setup time before the rising edge (this shouldn't be an issue), and 0ns+ hold time after. The 65c02 datasheet says we get 10ns+ hold time for both address and data after the phi2 falling edge (am I reading that correctly?). So we want the rising /WE edge within 10ns of the falling phi2 one.

Looking at the 50% voltage point (is that right?), it seems like the bad case shows about 20ns between the falling phi2 and the rising /WE. There's about 10ns lag between phi1 and phi2 plus about 12ns lag from phi1 to /we, which seems about what to expect from the hc139's datasheet. So that's too slow to be guaranteed to lock the addr/data that the 65c02 is holding?

In the good case we see only about 7-8ns lag from phi2 to /we, in fact /we rises a little before the cpu's phi1 output. I don't have the /phi2 signal on the trace since I was assuming it was just the inverse of phi2, but maybe that's not quite right since otherwise you'd expect a similar 12ns lag for the hc139?

But from these traces it seems like any write strobe generated downstream of phi1 is going to be too slow to meet the 10ns limit after phi2? So I'm probably missing something!

For completeness, here's a trace of clock in (ch3, purple) with Q (ch1, yellow) and /Q (ch2, blue) outputs. It does look like 2-3ns lag between the two, so perhaps explains the slight discrepancy above.

One other idea I'm curious about. I followed Michael's diagram and simply wired the SRAM's /CS1 to ground. What if I wired /CS1 to phi1, leaving CS2 = /HI and /WE = /MW as is. I This would give a rising edge on /CS1 before the /WE rising edge. Would that lock the write earlier (the datasheet describes write cycle 2 "controlled by CE#, CE2") and potentially fix my problem?

I'll give it a try but curious if I'm reasoning correctly there.

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

I don't think you're missing anything. All that this means is that your design is out of spec according to the data sheet. Unfortunately, the data sheet is mostly fictional. Our universal lived experience is that HC logic works fine for this. Regardless of hold time, whatever was last on the bus will stick around for *milliseconds* due to bus capacitance. As long as your /WE goes high before the 6502 has started driving the bus *in the following cycle* you will be fine.

That being said, though, why not just use an AHC part and be in spec? The only downside is that your system might be able to go faster!

You have it set up like this, right?

Keep in mind that the kind of glitch you are experiencing is not the kind of glitch that happens if your write strobe rises too late. If your write strobe rises after the 6502 has started changing the bus for the next cycle you may get the *wrong data* in the *right place.* Your glitch is the *right data* in the *wrong place* (or in multiple places). In other words, it's an address bus problem. *Unless* (this just occurred to me) it's holding so long that the address lines have started to change from $01FC to $01FB. A0 and A1 will be '1' in $01FB, so if WE\ is still low when A0 and A1 have changed (but not the other address lines yet) the SRAM will write to $01FF. (Maybe a better way to say this is that the only difference between $01FF and $01FB is the A2 line. If A1 and A0 go high before A2 goes low *AND* WE\ is still asserted at that time, it could account for overwriting $01FF.)

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

for sure, sounds like an AHC part is a safer bet, at least for the '139. also, given a 7-8ns lag of phi1 from phi2, it sounds like it would be almost impossible to do clock-qualifying with the onboard phi1 in a way that met the 10ns spec. tho as you say it might still work in practice if you had fast ac/ahc logic there. but again sounds safer to stick with a clock divider.

and as both of you point out, the symptom i'm seeing is likely that the address bus is already starting to change for the second write in the jsr push-word sequence. the spec says a min of 10ns for both addr and data hold, but a max of 30ns setup before the second address is ready. so the 20ns delay I measured is somewhere in that no-man's land where it might actually be writing the previous $f1 data item that's still hanging around onto some corrupted address like you say.

thanks for the advice and patience as i bend my brain around this stuff...

Hi pdragon,

I was looking at the image of your breadboard wiring (with some envy, it must be said - it is quite neat) as I am always looking to see how other people do things, when I spotted some links that I have no clue as to their purpose. I've circled them in the attached image.

DRG

eagle-eyed if there's space I try to mark n/c pins with a no-op purple 'staple' like that. the ones of the left are part of the hookup for an SD card that's not present in the photo.

i did resolve the issue eventually by avoiding the phi1 out from the 65c02 and generating my own anti-symmetric phi2/phi1 clock signals from a flip-flop. fairly up-to-date schematic here https://docs.google.com/presentation/d/ ... slide=id.p

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