65C02 in PLCC - pinout differences with Rockwell vs WDC

[BigEd]

A useful learning experience reported in the steckschwein project: Rockwell's 65C02 in PLCC has a slightly different pinout from WDC's offering.

In this case, the Rockwell parts were relabelled as WDC, and sold as WDC, which is the sort of thing we discuss often enough, as a risk when buying from marketplaces.

[GARTHWILSON]

Wow! That (the difference in pinout) is a whole lot more serious than the situation with the DIPs!

[BigDumbDinosaur]

Well, that sucks! Fortunately, it seems likely nothing else on the board was damaged.

Once again, I must remind everyone that the only safe sources for genuine WDC product are their authorized distributors. With a few exceptions, that does not include eBay sellers.

[ArnoldLayne]

BigEd wrote:

A useful learning experience reported in the steckschwein project: Rockwell's 65C02 in PLCC has a slightly different pinout from WDC's offering.

In this case, the Rockwell parts were relabelled as WDC, and sold as WDC, which is the sort of thing we discuss often enough, as a risk when buying from marketplaces.

Wow, cool, always nice to see that our site is actually being read!
And yes, that one hit very hard after hours of debugging. Also, debugging is still in progress as the wrong CPU is not the only problem with the new board.. a long way indeed.

[BigDumbDinosaur]

ArnoldLayne wrote:

BigEd wrote:

A useful learning experience reported in the steckschwein project: Rockwell's 65C02 in PLCC has a slightly different pinout from WDC's offering.

In this case, the Rockwell parts were relabelled as WDC, and sold as WDC, which is the sort of thing we discuss often enough, as a risk when buying from marketplaces.

Wow, cool, always nice to see that our site is actually being read!

I went to revisit that page to refresh my memory on what happened and instead got a 404.

[hoglet]

BigDumbDinosaur wrote:

I went to revisit that page to refresh my memory on what happened and instead got a 404.

https://www.steckschwein.de/post/its-a- ... emory-top/

[ArnoldLayne]

hoglet wrote:

BigDumbDinosaur wrote:

I went to revisit that page to refresh my memory on what happened and instead got a 404.

https://www.steckschwein.de/post/its-a- ... emory-top/

Yep, thanks. We redid our Site recently.

[BigDumbDinosaur]

ArnoldLayne wrote:

And yes, that one hit very hard after hours of debugging. Also, debugging is still in progress as the wrong CPU is not the only problem with the new board.. a long way indeed.

That’s why the good Lord gave us logic probes, oscilloscopes and coffee (sorry, tea just doesn't cut it).

[ArnoldLayne]

BigDumbDinosaur wrote:

ArnoldLayne wrote:

And yes, that one hit very hard after hours of debugging. Also, debugging is still in progress as the wrong CPU is not the only problem with the new board.. a long way indeed.

That’s why the good Lord gave us logic probes, oscilloscopes and coffee (sorry, tea just doesn't cut it).

We got logic probes, we got oscilloscopes, we got coffee. What we (I) need is time and patience. I was really hoping for the CPU pinout to be the only problem.
Fortunately, we are already a little bit further as we discovered the /OE signal is somehow off. Which is the reason the CPU is reading garbage from the EEPROM.
/OE is generated by the CPLD, so at least this shoud be fixable without making a new board..

[BigEd]

(If you haven't yet looked into @hoglet's 6502 protocol decoder, I recommend you do so. For some kinds of bugs, it's just the thing.)

[BigDumbDinosaur]

ArnoldLayne wrote:

Fortunately, we are already a little bit further as we discovered the /OE signal is somehow off. Which is the reason the CPU is reading garbage from the EEPROM.

In what way is /OE “off?” Is this a timing issue?

[ArnoldLayne]

BigDumbDinosaur wrote:

ArnoldLayne wrote:

Fortunately, we are already a little bit further as we discovered the /OE signal is somehow off. Which is the reason the CPU is reading garbage from the EEPROM.

In what way is /OE “off?” Is this a timing issue?

We haven't quite pinpointed what exactly is wrong, and if /OE is the only problem (since that was my first attempt at anything in VHDL, anything could be wrong). For the time being, "timing problem" is what we are suspecting. Also, maybe a 7ns XC9572 is just too much faster than the 74HCTxxx and GAL stuff we used before.

[ArnoldLayne]

BigEd wrote:

(If you haven't yet looked into @hoglet's 6502 protocol decoder, I recommend you do so. For some kinds of bugs, it's just the thing.)

As it seems to support the Saleae Logic 16 Logic analyzers we use, this seems exactly what we need. Thanks for the hint!

[ArnoldLayne]

BigDumbDinosaur wrote:

ArnoldLayne wrote:

Fortunately, we are already a little bit further as we discovered the /OE signal is somehow off. Which is the reason the CPU is reading garbage from the EEPROM.

In what way is /OE “off?” Is this a timing issue?

To wrap this up - we found the culprit. As a first, we listened to advice and added 74HCT245 buffers between the CPU Board components and the rest of the system...
And that's where I screwed up. The experienced viewer will notice that I tied the /CE pin for the data bus buffer to ground, having it drive the bus when r/w is high.
That's what you get for skipping the breadboarding part.

[BigDumbDinosaur]

A little bump.  I periodically look at the Steckschwein project to see how it’s coming along.  Only thing is reading the schematics is tough with all that color.