6502 not asserting R/W for long enough

[mdpye]

Hi everyone!

So, it's been a while since I looked at my 6502 project. I got distracted by cycling, but recently I dug everything out, simplified my requirements and tried to produce something simple but complete.

I have a 6502, an SRAM, an EEPROM and R65C52 dual ACIA, hooked up to an FTDI breakout board.

I can successfully write to my serial port, but the majority of what is written is garbage. In fact, it's 0xFF.

Looking with the logic probe, I can see that for the majority of write cycles, the R/W line (wired directly from the 6502 to both the SRAM /WE pin and ACIA R/W pin) is only asserted for the first part of the cycle (PHI2 low). My chip select lines only go low when PHI2 rises, and when it does, 70 or 80% of the time, R/W goes high with it, as do all of the data lines, which held the correct value to be written during the first half of the cycle. This happens when writing to either RAM or the ACIA, though it seems to be worse with the ACIA.

I realise a more detailed schematic will probably be required for full diagnosis, but I need to go back over it and check it against the reality of what I have soldered down before it's worth sharing, so I thought I'd describe the symptoms in case there are any avenues of investigation which can be suggested from that alone.

Any hints appreciated!

Mike

[BigEd]

R/W is a signal I usually write as RnW, and should go low to cause a write. To avoid writing to the wrong location, when the address lines and chip selects might still be holding the previous cycle's value, or be changing, it's normal to arrange the glue logic so that RnW can only go low when Phi2 is high.

Does it seem that your design is instead allowing RnW to go low only when Phi2 is low? That would be unexpected, and probably wrong.

[Dr Jefyll]

mdpye wrote:

Looking with the logic probe, I can see that for the majority of write cycles, the R/W line [...] is only asserted for the first part of the cycle (PHI2 low).

Uhh... this isn't quite making sense to me. A 6502 has a *minimum* operating frequency that's in the kilohertz range -- IOW, much to fast to be perceived by a human being watching the LED on a Logic Probe. Yet, you're using a Logic Probe for fractional-cycle observations?? Something doesn't add up. Just how slowly are you running the 6502?

Quote:

I realise a more detailed schematic will probably be required for full diagnosis, but I need to go back over it and check it against the reality of what I have soldered down before it's worth sharing

Withholding the schematic is a recipe for confusion and a lot of unnecessary question-and-answer dialog. Perhaps you haven't thought things through. More info means an easier job for those who would assist you. It's nicer if you make the job easy for us -- I'm just sayin'!

-- Jeff

[GARTHWILSON]

Dr Jefyll wrote:

A 6502 has a *minimum* operating frequency that's in the kilohertz range -- IOW, much to fast to be perceived by a human being watching the LED on a Logic Probe. Yet, you're using a Logic Probe for fractional-cycle observations?? Something doesn't add up. Just how slowly are you running the 6502?

He says elsewhere that he's using a WDC CMOS 6502, which of course can be brought down to 0Hz without malfunctioning.

[Dr Jefyll]

mdpye wrote:

R/W line (wired directly from the 6502 to both the SRAM /WE pin and ACIA R/W pin) is only asserted for the first part of the cycle (PHI2 low). My chip select lines only go low when PHI2 rises, and when it does, 70 or 80% of the time, R/W goes high with it, as do all of the data lines

It's extremely weird for R/W to change state midway through the cycle. It's as if the CPU had been reset. Maybe /RES goes low and/or the VCC supply experiences a brownout at this point -- as it may do when bus contention arises, or when the output of a logic gate (a decoder, perhaps?) tries to drive low into a line that is shorted high (or tries to drive high into a line that is shorted low). Can you monitor VCC with an oscilloscope?

[mdpye]

My apologies, I meant logic *analyser*. System clock is 2MHz, analyzer is sampling at 16, and has 16 channels showing me most of the control lines and all of the data bus at once.

To big ed: that's exactly what I am doing with my select lines, but R/W is wired directly to the relevant pins on the ram and io chips.

I'll follow up with a schematic tomorrow, but it is very close to one which was vetted here in a similar thread.

[mdpye]

Dr Jefyll wrote:

It's extremely weird for R/W to change state midway through the cycle. It's as if the CPU had been reset. Maybe /RES goes low and/or the VCC supply experiences a brownout at this point -- as it may do when bus contention arises, or when the output of a logic gate (a decoder, perhaps?) tries to drive low into a line that is shorted high (or tries to drive high into a line that is shorted low). Can you monitor VCC with an oscilloscope?

This sounds pretty plausible. I only have access to an old, rather beaten and uncalibrated analogue scope, but I will certainly see if I can discern anything on it. Thanks

[mdpye]

I got it under the scope. The signals look quite a lot cleaner than I was expecting. The clock looks great to me, and the ripples visible give me confidence in the fidelity of the scope, which, like I say, is pretty beaten.

The failure of R/W is clearly visible as it is pulled back towards 5V part way through a cycle.

Vcc looks pretty stable. Examining it at 10x X-axis zoom, and 50x Y-axis (relative to the other photos), I was able to look back and forth across the whole 10x magnified time range and the photo is of the portion showing the most variation. But at 50x zoom, it's showing a fluctuation of 100 to 150mV. Does that seems plausible to trigger brown-out?

I haven't had chance to do the schematic tonight. I'm semi-asking, semi-blogging my investigation here to get pointers, but also to help organise my thoughts. Thanks for listening.

Mike

[GaBuZoMeu]

The strange glitches on RWB looks as if there is a capacitive coupling from somewhere. Do you have a capmeter that can measure down to 100 pF? If, I would turn off power and measure RWB against any other signal. There ought to be no capacitive load anywhere but you may find an exception. Perhaps an ill placed blocking C.

[Dr Jefyll]

mdpye wrote:

The signals look quite a lot cleaner than I was expecting.

What's the bandwidth of the 'scope? If it's fairly low (say, 50 MHz or less) then the waveforms probably have some "dirt" which simply isn't displayed.

Quote:

The failure of R/W is clearly visible as it is pulled back towards 5V part way through a cycle.

Maybe the CPU can't reliably pull R/W low because it doesn't have a reliable connection to "low" ie, Ground. I admit it's kind of a goofy theory, but I do wonder if a bad connection may play a role here.

I suggest you use the scope to examine the waveforms on the Gnd and +5 pins of all your IC's -- be sure to probe the pin itself. This is to rule out the possibility of a poor connection from the IC pin to the Gn / +5 rails of the breadboard.

Along with a schematic, it might be helpful to see a recent photo of your project.

Cheers!

[BillO]

Dr Jefyll wrote:

mdpye wrote:

The signals look quite a lot cleaner than I was expecting.

What's the bandwidth of the 'scope? If it's fairly low (say, 50 MHz or less) then the waveforms probably have some "dirt" which simply isn't displayed.

Quote:

The failure of R/W is clearly visible as it is pulled back towards 5V part way through a cycle.

Maybe the CPU can't reliably pull R/W low because it doesn't have a reliable connection to "low" ie, Ground. I admit it's kind of a goofy theory, but I do wonder if a bad connection may play a role here.

I suggest you use the scope to examine the waveforms on the Gnd and +5 pins of all your IC's -- be sure to probe the pin itself. This is to rule out the possibility of a poor connection from the IC pin to the Gn / +5 rails of the breadboard.

Along with a schematic, it might be helpful to see a recent photo of your project.

Cheers!

+1 on everything Jeff said. Especially that note about the possible bad connections to power.

Although, I will say even a 5MHz scope is better than none ... but a dual trace 5MHz scope is more than 100% better.

We really need a schematic. It will add immeasurably to our understanding of what you are trying to do. Also, maybe a (well focused) picture of your prototype.

(Edit: I just noticed I pretty much repeated everything Jeff said. Rather than claiming a 'senior moment' I will just say his points were worth repeating...)

[mdpye]

Cool, I'll get on to those measurements.

The scope is 20Mhz, dual channel. Saying a dual channel is more than 2x better. Do you mean in general utility, or could I put the second channel to good use in this context? It also has an external trigger

Thanks,

Mike

[BillO]

mdpye wrote:

Cool, I'll get on to those measurements.

The scope is 20Mhz, dual channel. Saying a dual channel is more than 2x better. Do you mean in general utility, or could I put the second channel to good use in this context? It also has an external trigger

Thanks,

Mike

What I would normally do is put the phi2 signal on one channel and the R/W on the other and trigger off the Phi2. All bus operations on the 6502 depend on Phi2, so most timing measurements should be made WRT to it.

Also, if you needed to see the relationship between 2 signals, such as R/W and a chip select, you could scope them against each other. You could also feed Phi 2 into the external trigger and see how those 2 signals line up with Phi2.

2 channels are very handy - use 'em if you have 'em.

20 MHz is a bit slow to see all gremlins, but if your clocking at 2MHz, then you might not be producing many of them. A schematic and a picture of the prototype will be helpful. Are you using any 74AC or 74ACT logic? They produce fast leading edge signals which can create glitches a 20MHz scope will not find.

[Dr Jefyll]

Yes, it can be hugely helpful to see the relationship between 2 signals. I was going to mention this, but Bill beat me to it. And, as noted, by using the external trigger input you can even evaluate the relation between *three* signals.

20 MHz is indeed rather slow if you're observing fast logic families such as 74AC and 74ACT logic... or modern WDC cpu's. Like AC devices, they produce very abrupt output swings, and also they can respond to extremely brief input glitches.

[BigEd]

That RnW waveform is very odd indeed. It almost looks like there are two drivers fighting each other: RnW twice is driven positive, but not to the rail.

So, you need to review your design, and your implementation. Something isn't right.