Page 1 of 2

6502 + at28c256 always reading wrong data

Posted: Sun Mar 14, 2021 6:42 pm
by flyguybravo
I've been struggling with this problem for 3 weeks now and have run out of ideas on how to troubleshoot this. Hoping someone here might be able to point me in the right direction.

I've got a WDC 65c02 paired with an AT28C256 EEPROM that I've programmed entirely with $ea as a means of testing. I'm using a TL866ii+ and I've written/read from the 3 different EEPROMs using both the OEM Windows software and David Griffith's "minipro" software. The chips all check out ok - the reads and writes are successful.

The problem, however, is that once the EEPROM is in my circuit, the 6502 always reads $fffc as $00. Each of the three AT28C256's behave the same.
$fffd reads properly as $ea, thus my starting address is always $ea00 instead of $eaea.

The clock is manual right now and based on 555 timers - built following Ben Eater's project on YouTube.

Monitoring the address and data pins with an Arduino, the output below is consistent. I have disassembled and rebuilt the circuit 3 times, double/triple checking my wiring, components, continuity, and voltages.

Code: Select all

|-address pins-| |data pins|
1111111111111111   11101010   ffff  r ea
1111111111111111   11101010   ffff  r ea
1111111111111111   11101010   ffff  r ea
0000000000000000   11101010   0000  r ea
0000000100000000   11101010   0100  r ea
0000000111111111   11101010   01ff  r ea
0000000111111110   11101010   01fe  r ea
1111111111111100   00000000   fffc  r 00
1111111111111101   11101010   fffd  r ea
1110101000000000   00000000   ea00  r 00
1110101000000001   11101010   ea01  r ea
0000000111111101   11101010   01fd  W ea
0000000111111100   00000010   01fc  W 02
0000000111111011   00110100   01fb  W 34
1111111111111110   00000000   fffe  r 00
1111111111111111   11101010   ffff  r ea
r/W is output from pin 34 (RWB), last two characters is the data read in.

With the EEPROM programmed for all $ea ... I'm only expecting the 6502 to go to $eaea after initialization and proceed counting up from that address with a series of NOP instructions.
I've also replaced the 65c02 thinking perhaps my chip was the culprit - but same behavior on the other 65c02 as well.

Someone had suggested I try programming the EEPROMs with something other than $ea - and since it always wants to jump to $ea00, put the instructions there. I've done this, but unfortunately I'm still quite early in learning about the 6502 and I'm not able to make much sense of this.

I programmed one of the AT28C256's with the following:

Code: Select all

rom[0x6a00] = 0x08
rom[0x6a01] = 0x18
rom[0x6a02] = 0x28
rom[0x6a03] = 0x38
rom[0x6a04] = 0x48
rom[0x6a05] = 0x58
rom[0x6a06] = 0x68
rom[0x6a07] = 0x78
rom[0x6a08] = 0x88
rom[0x6a09] = 0x98
rom[0x6a0a] = 0xa8
rom[0x6a0b] = 0xb8
rom[0x6a0c] = 0xc8
rom[0x6a0d] = 0xd8
rom[0x6a0e] = 0xe8
rom[0x6a0f] = 0xf8

rom[0x6a10] = 0x20
rom[0x6a11] = 0x00
rom[0x6a12] = 0xea
When run in the circuit, this was the result:

Code: Select all

   11101010   0000  r ea
   11101010   0000  r ea
   11101010   0000  r ea
   11101010   0000  r ea
   11101010   0000  r ea
   11101010   0000  r ea
   00000000   0000  r 00  <- $fffc
   11101010   0000  r ea
   00001000   0000  r 08  <- $ea00 ($6a00 on the eeprom)
   00011000   0000  r 18  <- $ea01 ($6a01)
   00110100   0000  W 34
   00000000   0000  r 00
   00101000   0000  r 28  <- $ea02 ($6a02)
   11101010   0000  W ea
   00000011   0000  W 03
   00110100   0000  W 34
   00000000   0000  r 00
   11101010   0000  r ea
   00001000   0000  r 08  <- back to $ea00 and repeat
   00011000   0000  r 18
   00110100   0000  W 34
   00000000   0000  r 00
   00101000   0000  r 28
   11101010   0000  W ea
   00000011   0000  W 03
   00110100   0000  W 34
   00000000   0000  r 00
   11101010   0000  r ea
   00001000   0000  r 08  <- cycle starts again
   00011000   0000  r 18
   00110100   0000  W 34
   00000000   0000  r 00
   00101000   0000  r 28
   11101010   0000  W ea
   00000011   0000  W 03
   00110100   0000  W 34
   00000000   0000  r 00
   11101010   0000  r ea
By this point I had detatched the Arduino from the address pins thinking maybe a problem with the Arduino could be causing timing issues. This is why all of the addresses show as "0000" in the output above. But notice how the execution never makes it all the way through my instructions - so I believe the problem is manifesting itself here as well.

Basically I'm completely stuck at the moment an unsure what to troubleshoot next. Any suggestions on something I can try?

Pic of my circuit can be found here: https://imgur.com/a/V4fHCDu

Re: 6502 + at28c256 always reading wrong data

Posted: Sun Mar 14, 2021 8:33 pm
by BigDumbDinosaur
This sounds like a glue logic error is at work.

flyguybravo wrote:
Pic of my circuit can be found here: https://imgur.com/a/V4fHCDu

Went to that location and only got a blank page. You can attach images to your posts here.

Re: 6502 + at28c256 always reading wrong data

Posted: Sun Mar 14, 2021 8:36 pm
by GARTHWILSON
For me it started doing the picture and then went all gray and there was nothing to see.

Re: 6502 + at28c256 always reading wrong data

Posted: Sun Mar 14, 2021 11:22 pm
by dourish
It's hard to see the details on that image, but I would make sure to ground all the unused inputs on the chip you're using for glue logic. When the inputs float, odd things can happen, and so your chip select signals might not be operating as you expect.

Re: 6502 + at28c256 always reading wrong data

Posted: Mon Mar 15, 2021 6:23 am
by Dr Jefyll
Yes, please post the image here.

And pin 1 of the WDC 65c02 is VPB (not GND/Vss as with other 65c02's). Please check that pin 1 is "no connect" in your project -- has nothing attached to it. Just a hunch...

Welcome!

-- Jeff

Re: 6502 + at28c256 always reading wrong data

Posted: Mon Mar 15, 2021 7:29 am
by 1024MAK
Hello and welcome :D

Are you absolutely sure that none of the EEPROM input pins is floating? That is, are all the input pins connected to either the correct relevant pin on the processor, or connected to the relevant supply rail.

A open circuit input on a CMOS chip will float and will vary depending on the electric field caused by nearby circuitry. Even if all the EEPROM locations are programmed with the exact same value, the floating input may well cause invalid data to be output occasionally by the EEPROM when it is read by the processor.

It’s similar for the inputs on any CMOS 74 series logic used as glue logic (that provides chip select/enable or output enable) and for the input pins on CMOS processors.

It would also help us if you had a schematic circuit diagram. Generally speaking, life is easier for both you and others if you produce a schematic circuit diagram first, then wire up your breadboard circuit to the schematic circuit diagram. The means you can mark each connection as you wire up your breadboard, thus making it less likely that any connections get missed.

Mark

Re: 6502 + at28c256 always reading wrong data

Posted: Mon Mar 15, 2021 8:57 am
by cjs
What happens if you pull the ROM chip and instead use pull-up/pull-down resistors (any value between about 470 and 2k ohms should do) to connect the points where the data pins were to Vcc/GND?

Re: 6502 + at28c256 always reading wrong data

Posted: Mon Mar 15, 2021 12:15 pm
by flyguybravo
Lot of great replies, thank you!! Sorry for the image - I've attached an embedded image toward the bottom of this reply.

@dourish - I believe all any unused inputs are resolved. On my EEPROM, WE is tied high, OE low, CE is connected to a NAND gate output where both inputs are tied to the 65c02's A15. On the 65c02, pins 2 (RDY), 4 (IRQB), 6 (NMIB), 8 (VDD) are tied to 5v. 36 (BE) and 38 (SOB) are also tied to 5v. Pins 1 (VPB), 3 (PHI1O), 5 (MLB), 7 (SYNC), 35 (NC), 39 (PHI2O) are not connected to anything. All of the address and data pins are connected to the EEPROM and I'm confident that I have continuity from pin to pin.

@Dr Jefyll - correct, VPB is "no connect".

@1024MAK - Yes, I have quadruple checked to ensure none of the EEPROM pins are floating. The schematic I'm working toward is tacked on to the bottom of this reply. I've not made it all the way through this yet as I'm trying to check and troubleshoot as I go. The only components I have on the board at present are the 65c02, EEPROM, and NAND gate. I've printed this schematic 4 times and tick-and-tied my connections on each as I work my way through the circuit.

@cjs - My first test before introducing the EEPROM was using 1k resistors on the data pins to hard-code instruction $eaea (11101010). The 65c02 behaved entirely as expected - consistent $ea reads at each clock cycle.

Seriously, thank you all for your responses. This has strangely been both a fun and stressful project thus far and I learn something new about the 65c02 and electronics in general every day I experiment with it.

I do also want to note: since my clock is in manual mode and I'm stepping through each tick manually, I stopped the clock yesterday just before the $fffc read (where I normally get the erroneous $00) to take measurements throughout the circuit. The clock was in the LOW position. I had a consistent and stable 5.1765v throughout the circuit. I measured from pin-to-pin between each of the EEPROM and 65c02's pins individually, then measured chip-to-chip between the two. The results were confounding. On my address pins, A0 and A1 were low, A2 through A15 were high -- good, this is the address I'm looking for! But the data pins were 0v flat. Every one - both at the EEPROM and the 65c02. I took these measurements on two different EEPROMs. I again took both EEPROMs back to the programmer to read the chips and, indeed, at address $7ffc they are each programmed as $ea. ($7ffc because in my circuit I have the NAND to flip the read location on the EEPROM... 65c02 is requesting $fffc but reading from location $7ffc on my EEPROM). I've read the chips from three different computers, each indicate a good read on the chip.

Image

Image

Re: 6502 + at28c256 always reading wrong data

Posted: Mon Mar 15, 2021 1:30 pm
by nbrok
Hi,

Reading your schematic diagram I found two mistakes. The OE pins of your RAM and ROM must be tied to the inverted R/!W of the 6502 nanded with the phi2 clock.

Code: Select all


               _________               _________
               |      1|               |      &|
   R/!W -------|       |O--------------|       |
               |_______|               |       |O-------- !RD
                                       |       |
   PHI2 -------------------------------|       |
                                       ---------
The Write signal could also better synced with PHI2

Code: Select all

                                       _________
                                       |      &|
   R/!W -------------------------------|       |
                                       |       |O-------- !WR
                                       |       |
   PHI2 -------------------------------|       |
                                       ---------

I hope this will help you any further.

Re: 6502 + at28c256 always reading wrong data

Posted: Mon Mar 15, 2021 8:56 pm
by 1024MAK
Okay, so having had a quick glance at the breadboard, I do notice that there is a lack of decoupling/by-pass capacitors.

Normally it’s recommended to have one 100nF ceramic capacitor connected as close as practical to the +5V/VCC/VDD and 0V/GND pins of each chip. That’s one capacitor per chip.

It’s also a good idea to have a 10uF to 100uF electrolytic capacitor (bulk decoupling) on the board where the power supply connects to the board. On large boards, you would have a number of these distributed across the board.

You say that you are using a 555 timer for the clock. This chip, or at least, the bipolar version, alone needs a 47uF to 100uF electrolytic capacitor near it to counter the supply noise it generates when it switches it’s output and it’s discharge pin.

The NAND gate, it has unused input pins that are floating (not connected). This is not recommended. ALL unused inputs, even if the gate is not being used, should be connected to a known voltage. Either tied to 0V/GND or to +5V/VCC/VDD either directly or via a suitable resistor (depends on the logic family).

The reset circuit (65C02 pin 40) looks incomplete. I can’t see a capacitor there. The capacitor helps denounce the switch contacts. And where is the 0V/GND connection for the push switch?

Mark

Re: 6502 + at28c256 always reading wrong data

Posted: Mon Mar 15, 2021 9:58 pm
by BigDumbDinosaur
The schematic is difficult to read because it's in color and is coming across as a gigantic image. However, I was able to note that SOB on the MPU is floating. That, like all CMOS inputs, must be positively driven to Vcc or ground, Vcc in this case.

Also, the 555 is a lousy clock generator. The output rise and fall times are much too slow. you should be using at the minimum a clock oscillator with CMOS output.

Re: 6502 + at28c256 always reading wrong data

Posted: Mon Mar 15, 2021 10:07 pm
by cjs
flyguybravo wrote:
My first test before introducing the EEPROM was using 1k resistors on the data pins to hard-code instruction $eaea (11101010). The 65c02 behaved entirely as expected - consistent $ea reads at each clock cycle.
Yes, given that you seem to be following along with the Ben Eater thing, I had actually already guessed that you had probably done that with resistors directly on the CPU's data pins. But now that the ROM is wired in, pulling it off the board and using resistors where the ROM's pins were connected to the board will also test the new wiring for the ROM, and any other changes to the system that you might have made (on purpose or inadvertantly).

Re: 6502 + at28c256 always reading wrong data

Posted: Tue Mar 16, 2021 12:35 am
by 1024MAK
BigDumbDinosaur wrote:
The schematic is difficult to read because it's in color and is coming across as a gigantic image. However, I was able to note that SOB on the MPU is floating. That, like all CMOS inputs, must be positively driven to Vcc or ground, Vcc in this case.

Also, the 555 is a lousy clock generator. The output rise and fall times are much too slow. you should be using at the minimum a clock oscillator with CMOS output.
Looking at the photo of the breadboard, SOB looks to be connected to VCC.

I agree that a 555 is far from ideal, but from what the poster says, it’s only being used for slow speed and single stepping. Still if the NAND gate chip is a 74HC00 type, the output of the 555 could be cleaned up by using a couple of the spare NAND gates.

Mark

Re: 6502 + at28c256 always reading wrong data

Posted: Tue Mar 16, 2021 12:45 am
by GARTHWILSON
1024MAK wrote:
I agree that a 555 is far from ideal, but from what the poster says, it’s only being used for slow speed and single-stepping.

Regardless of frequency, the slew rate is much too slow to meet WDC's supposed requirement. This is covered in the clock-generation page of the 6502 primer which I strongly recommend you go through, flyguybravo.

Quote:
Still if the NAND gate chip is a 74HC00 type, the output of the 555 could be cleaned up by using a couple of the spare NAND gates.

That should do it.

Another thing the could cause problems if it has not already is the lack of a proper reset circuit. This is covered in the Reset page of the 6502 primer.

Re: 6502 + at28c256 always reading wrong data

Posted: Sun Mar 21, 2021 7:12 pm
by flyguybravo
First - I want to apologize for the tardiness of my reply back to this thread. It's been an incredibly busy week but I should have posted back sooner to acknowledge all of the great feedback I received from everyone. Thank you! You even pointed out a few issues I didn't realize I had yet!

Second - I picked up an oscope this week to dive a little deeper into whats going on, and it's been enlightening to say the least.

@1024MAK - The decoupling capacitors are what solved the issue and I'm ashamed at myself for taking THIS long to actually put them on the board. I have them on my clock module, which is providing power to the board with the 6502 circuit, but clearly they need to be widely distributed. Thank you!

@GARTHWILSON - Being new to the 6502, these links to the primer are especially helpful. There is a wealth of valuable information here and I still have a lot more to go through. Thanks for the link and the effort put into this!