(Fair warning: I'm not an electrical engineer, just a hobbyist; programmer by day)

So, I recently built a rev2 PCB of a 65C02 system I built not too long ago. The changes made were fairly minimal (you could argue I was overly-eager to spin a board, but hey). Mostly just bug fixes, and adding a couple of extra I/O connectors and a power switch.

First boot attempt I discovered that I had forgotten to switch the clock driving everything but the CPU to use the actual clock rather than the PHI2 output from the 65C02, so I fixed that with a bodge wire on the back. At this point things seem to be working almost perfectly, but there's some garbage data showing up on the 7-segment displays. Seems like it's always one or two extra bits getting set (segments lighting up) and it seems to be deterministic.

Then I ended up realizing that changing the clock speed affected the behavior. Every slower clock speed I've tried (1, 2, 4, 8, 10 MHz) also displays the corrupted data in the LEDs but to my utter disbelief, running it at 12 MHz "fixed" the corrupted data.

I have already spent a fair bit of time going over the connections for the LEDs, re-soldered the joints, verified continuity and checked for shorts, replaced the latches, and found nothing wrong. Unfortunately I don't have an oscilloscope currently so I haven't been able to actually see what any of the signals are looking like.

But it's strange that everything else on the computer would work perfectly on the first try and this issue would magically go away by increasing the clock speed. I was actually expecting the opposite effect, if anything.

Any thoughts or ideas on this would be appreciated!

Do you have a schematic we could see?

Sure thing. I've attached a PDF. Only difference is that I have already corrected the clock signal thing in the PDF as I did with the bodge wire on the back of the board.

Could you please post a monochrome schematic?

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

Sure. Just out of curiosity, how come? Just easier to read?

My datasheets say that the 'HC11 is an AND with three inputs, Phi2 among them. The output goes to a 'HC574 that takes its data at the _rising_ edge of its CLK input. But that would be of the leading edge of the signal coming out of the AND.

You should use a NAND instead, that rises its output at the trailing edge of Phi2, where the actual data is on the bus. Or did I miss anything?
Or rather, use an OR with three inputs, so you only need to invert Phi2.

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

I think your logic seems reasonable, that I should really be triggering the latches on the falling edge, if I'm understanding the write cycle timing correctly.
But this makes little sense to me because I never had this problem before on the previous revision of the board which used the same circuit to drive the latches as well as the same address decoding.

EDIT: Reading from here: https://wilsonminesco.com/6502primer/addr_decoding.html It says "You must have a way to make sure RAM cannot be written to when phi2 is low!" Does this imply that writes _should_ be qualified by the rising edge of phi2?

EDIT2: I'm not an expert but it seems like qualifying on the rising edge of phi2 is right. "... its bus accesses (reading or writing) when phi2 is high."

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Thanks for clarifying this!

So, a theory: the latches are edge-triggered so they're latching in the data on the bus before it's valid? However, this doesn't seem to add up, again, because the exact same circuit worked just fine on rev1. And I still have little idea why speeding it up "fixes" it. Perhaps the faster speed prevents this problem by causing the data to be valid earlier? I don't know, doesn't really add up to me.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Please show a picture of your board. I'm interested in speed of your parts and power & ground distribution. If not a 4-layer board with power & ground planes, tack on a few short power & ground wires from CPU to memory to I/O can be helpful. Is your 12MHz clock physically different clock than others (1,2,4,8,10Mhz)? I'm wondering about symmetry, rise time of the clock as well as the high/low levels. I'm new to 6502, but the recent few weeks of experience have shown that W65C02 needs bypass and 10uF filter cap close to its power/ground pins.
Bill

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

See below...

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

I'm tracing through your long decoding path for the seven-segment displays; it starts from address [15..8] through 74HC30, through two cascaded 74hc137, then an inverter, then 74hc11. Finally the output of 74hc11 is used to clock 74hc574 latch on the rising edge of CLK. On paper this won't even work because data is not ready at the rising edge of CLK. Only reason it did kinda work is because the long propagation delay has caused several glitches after the rising edge of CLK that managed to clock in the real data. The fix is shorten the prop delay and latch data on the falling edge of CLK.
Bill

Thanks for all the comments so far. I totally agree about the schematic; this was the first one I'd worked on in a while, and the most complex one I'd ever worked on. Since then I've found myself wanting to clean it up and put it on one page, etc. Just haven't done so yet.

The long propagation delay being the reason it works in rev1 seems logical but doesn't necessarily explain why it doesn't work the same way in rev2. Still seems weird to me.

I'm actually working on building another system on a breadboard to be able to experiment more with things so I'll definitely try out the suggestions here. It confused me that I should latch data on the falling edge of CLK since it was stated that /WE should not be asserted while CLK is low, but it seems to make sense since the data should be valid at that falling edge and shortly after it.

I've attached a picture of the board layout in my CAD program as well as a picture of the board itself.