Writing in EEPROM and reading by 6502

[GARTHWILSON]

Whoops, Chromatix is right. I wrote too hastily. My apologies. Since NOP is one byte but takes two cycles, A0 will change at half the clock rate, not cycle at half the clock rate.

[BigEd]

Might be worth also trying a two-byte instruction - for example, tie the databus to A9 (10101001) and the address lines should all run at twice the rate.

[Chromatix]

There are three classes of instruction on the 65c02 which can show continuous incrementing of the PC every cycle:

1: the 1-byte 1-cycle NOPs ($x3 and $xB, plus $x7 and $xF on CPUs lacking the bit-instructions).
2: the 2-byte 2-cycle Immediate addressing mode instructions (such as $A9 $A9 which is LDA #$A9). There are quite a few of these.
3: the branch instructions IF the branch is not taken ($x0 with odd x).

It seems plausible to me that $EA is being transmuted to a 1-cycle NOP through corruption on the data bus. That case can be distinguished by observing SYNC high in every cycle, instead of alternating between high and low as it would for a 2-cycle instruction. I suggest switching the A7 sample line to observe SYNC.

We should be able to find out what's really on the bus by attempting to execute an absolute or zero-page instruction, which should cause the address bus to alternate between program and data addresses. I suggest $E5 $E5, which is SBC $E5 (zero page). SYNC should then be high in one cycle out of three, and the address bus should show $E5 in the cycle preceding SYNC, and incrementing program addresses in the other cycles. All of the $x5 opcodes are either zero-page or zero-page-indexed, the latter taking 4 cycles instead of 3, which would indicate D4 being stuck high.

[hitlp]

Chromatix wrote:

There are three classes of instruction on the 65c02 which can show continuous incrementing of the PC every cycle:

1: the 1-byte 1-cycle NOPs ($x3 and $xB, plus $x7 and $xF on CPUs lacking the bit-instructions).
2: the 2-byte 2-cycle Immediate addressing mode instructions (such as $A9 $A9 which is LDA #$A9). There are quite a few of these.
3: the branch instructions IF the branch is not taken ($x0 with odd x).

It seems plausible to me that $EA is being transmuted to a 1-cycle NOP through corruption on the data bus. That case can be distinguished by observing SYNC high in every cycle, instead of alternating between high and low as it would for a 2-cycle instruction. I suggest switching the A7 sample line to observe SYNC.

We should be able to find out what's really on the bus by attempting to execute an absolute or zero-page instruction, which should cause the address bus to alternate between program and data addresses. I suggest $E5 $E5, which is SBC $E5 (zero page). SYNC should then be high in one cycle out of three, and the address bus should show $E5 in the cycle preceding SYNC, and incrementing program addresses in the other cycles. All of the $x5 opcodes are either zero-page or zero-page-indexed, the latter taking 4 cycles instead of 3, which would indicate D4 being stuck high.

I just analyse the SYNC. In every address I have used ($ E5, $ EA) it is always high. What can this mean? Malfunction of the processor?

[Chromatix]

It means that your CPU is executing 1-cycle NOPs. The reason why, we have not yet determined - but an outright faulty CPU is not very likely.

It's much more likely that something is wrong with your data bus. I suggest checking not only for continuity between pins of the EEPROM and the corresponding pins of the CPU, but for shorts between adjacent wires. Especially between D0 and D1.

[hitlp]

Chromatix wrote:

It means that your CPU is executing 1-cycle NOPs. The reason why, we have not yet determined - but an outright faulty CPU is not very likely.

It's much more likely that something is wrong with your data bus. I suggest checking not only for continuity between pins of the EEPROM and the corresponding pins of the CPU, but for shorts between adjacent wires. Especially between D0 and D1.

I connected the data bus directly in the VCC (when 1) and VSS (when zero).

[Chromatix]

Okay, so let's make sure your bit numbering is right. For $E5 (SBC zp), you should have wired D7, D6, D5, D2, D0 to Vcc, and D4, D3, D1 to Vss. If you got those backwards, you would be executing $A7 (SMB2) instead, which depending on your precise CPU model, could be one of the 1-cycle NOPs.

[hitlp]

Chromatix wrote:

Okay, so let's make sure your bit numbering is right. For $E5 (SBC zp), you should have wired D7, D6, D5, D2, D0 to Vcc, and D4, D3, D1 to Vss. If you got those backwards, you would be executing $A7 (SMB2) instead, which depending on your precise CPU model, could be one of the 1-cycle NOPs.

I put the data analyzer to make sure the data bus is correct with $ E5 so it's all right. But when parsing the address bus, it continues the same way.

[BigEd]

If what's happened is that two data pins are swapped, or one is floating high, then you won't discover that until you try an opcode which exercises that fault. For example, to find a pin which is floating high, you'll need to have chosen and tried an opcode which places a zero on it.

[Dr Jefyll]

Can you post a photo of your project, please? Also, you haven't told us what sort of CPU you are using. Remember we can only help based on the information you provide! Please try to tell us as much as possible.

hitlp wrote:

I just analyse the SYNC. In every address I have used ($ E5, $ EA) it is always high. What can this mean?

There are several possibilities. For example, it's possible your observation is incorrect, and SYNC is *not* always high. This can be the result of a misunderstanding with your instruments -- which is something that can happen to anyone. Maybe you can use a different method or a different instrument to verify the SYNC observation -- that's what I would do if it happened to me.

-- Jeff

[hitlp]

Well, I'm going to put all the documentation I've done so far about my project. The first component is the clock running the 1 MHz frequency through the Kyocera KO-43B. The analysis of the wave in the oscillator is correct generating the desired frequency.

After the clock, I have a timer circuit with reset button. When the button is pressed, it takes a few seconds to return to normal. I use the NE555 as shown in the diagram.

Finally I turn on the 6502 clock, reset and VCC. For the RDY, IRQ, NMI and SO pins I connected directly to the VCC with 3k3 resistor.

I started using EEPROM, but I took a few steps back to ensure that simple code execution is correct. But the NOP does not consume the two clock cycles as it should.

Did I do something wrong? If you need more information, I can put it.

Thank you so much guys.

Transparency: I use the grappendorf website as a source of information.

[Chromatix]

Okay, so in that photo you have a Rockwell CPU (looks like R6502AP, which is an NMOS device, not a CMOS one) wired up for $EA NOPs, and your logic analyser attached to the low-order address lines. You have an oscillator and a reset controller. RDY, /NMI and /IRQ are pulled high.

Concerns:

1: You appear to have hardwired A15 to Vcc, just "south" of the eight data pins. A15 is an *output* from the CPU and should never be directly connected to a power bus.

2: I don't see any power bypass capacitors anywhere. Prototype boards need them even more than PCBs do. Without them, expect ground bounce to induce spurious transitions on critical inputs such as the clock.

[hitlp]

Chromatix wrote:

Okay, so in that photo you have a Rockwell CPU (looks like R6502AP, which is an NMOS device, not a CMOS one) wired up for $EA NOPs, and your logic analyser attached to the low-order address lines. You have an oscillator and a reset controller. RDY, /NMI and /IRQ are pulled high.

Concerns:

1: You appear to have hardwired A15 to Vcc, just "south" of the eight data pins. A15 is an *output* from the CPU and should never be directly connected to a power bus.

2: I don't see any power bypass capacitors anywhere. Prototype boards need them even more than PCBs do. Without them, expect ground bounce to induce spurious transitions on critical inputs such as the clock.

Hi Chromatix,

I turned off the entire circuit and called again to make sure nothing was wrong. I put the capacitors, I believe in the right places. But the behavior remains the same. The A0 remains with 500 KHz cycle. I do not know what this problem can be anymore.

[leepivonka]

Is the reset circuit working? If you hold reset low, the 6502 will have some bus activity, but it won't be executing instructions.

On bypass capacitors: At high frequencies the disc ceramic ones around 100nF work better than the rolled film ones. But any capacitor is better than no capacitor!

[GARTHWILSON]

leepivonka wrote:

On bypass capacitors: At high frequencies the disc ceramic ones around 100nF work better than the rolled film ones.

Good catch. Yes, use ceramic discs, or better, monolithic ceramic capacitors. Also, make their connections to the ICs' ground and VDD pins as short as you can, which might require forming a capacitor's leads to go over the top of an IC, rather than using those long hoops of wire connections. Lead length adds inductance, and the way you have it there, those capacitors, along with the long connections to them, present an impedance that's actually inductive rather than capacitive at the frequencies of concern, which are determined not by the clock rate but by the rise and fall times.