6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Nov 23, 2024 2:34 pm

All times are UTC




Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Fri Feb 07, 2020 7:45 am 
Offline

Joined: Fri Feb 07, 2020 7:09 am
Posts: 3
Hi All, like a number of you guys, I am also playing along to Ben Eaters excellent series on the 6502. I have it created and working on a breadboard with the LCD displaying "Hello World!"... so far so good. So keen have I been to keep going, I have also added the SRAM chip and wired in accordance with his Schematic (hopefully attached below..), and have verified that ALL signals go to the right places and are wired correctly. BUT, with his new code to use a Subroutine to do the Reading and writing of the Data to the 6522 VIA, this code doesnt work. It would seem that Data ISNT being written to the SRAM... (I have "tested" the SRAM in the EEPROM Programmer, TL866 II Plus, and it reports no issues. This post is already getting too long, so currently I am trying to TRoubleshoot the signals are working in the right order and at the right time, BUT, when using my Scope to monitor the Chip Select signals and the OE signals, all works fine, but when using it to Monitor the R/W line, it is permanently LOW (According to the scope..) and doesnt change, apart from a few VERY short Spikes every now and then (Assuming its when the CPU is trying to Raise the line for a READ....) Its all VERY odd, as the code that drives the LCD is working fine when using Ben's LONG version of code (IE everything is done, In-line repeteively, no SUbroutine jumps), which I am assuming has to Read and write to the VIA chip.... Even disconnecting the R/W line from EVERYTHING, and letting the code simply run, I cant see the R/W line going up and down ?
Should I be able to see this line going up and down? If so, during a Write cycle, what sort of "pulse width" should I see? I am beggining the think I have a dead R/W line on the WDC 65C02 chip... but would welcome anyones comments and suggestions. I have a couple of new chips on order from Mouser, but its driving me crazy (although I am learning a HUGE ammount, so very heppy :D )
Forgot to mention, the Clock source shown in this schematic ISNT the one I'm using, I am using Ben's 555 based clock generator with the Single Step feature... AND, I have tried a 2nd CPU that I ordered from the same source, and that behaves in the same way... I have read all the stuff about dodgy chips etc etc....


Attachments:
File comment: Ben Eaters Schematic for the Project
6502.png
6502.png [ 447.01 KiB | Viewed 2275 times ]
Top
 Profile  
Reply with quote  
PostPosted: Fri Feb 07, 2020 8:27 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8545
Location: Southern California
Welcome.

I see lots of potential problem sources. Go through the 6502 primer at http://wilsonminesco.com/6502primer/ . It addresses all of them. (The 6502 primer is apparently where Ben got his address-decoding scheme; but he ignores a lot of the other things there.)

_________________
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?


Top
 Profile  
Reply with quote  
PostPosted: Fri Feb 07, 2020 6:03 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8509
Location: Midwestern USA
bellaf wrote:
Hi All, like a number of you guys, I am also playing along to Ben Eaters excellent series on the 6502...

First off, welcome to 6502-land.

I had a hard time reading your schematic due to it being in color, but did see what I thought are couple of things that could be giving you some grief. Can you please re-post the schematic in monochrome?

Also, it's helpful to break up your text into paragraphs to make it easier to read.

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Feb 07, 2020 7:32 pm 
Offline

Joined: Fri Feb 07, 2020 7:09 am
Posts: 3
Many thanks for the warm welcome words.

Have been a fan of this charming chip since I built (well, soldered together and couldn't get it to work...) one of the first Acorn System 1's back in the last millennium, so now I have decided to get back into this and really understand it! :-)

As luck would have it, the replacement CPU's I mentioned arrived today from Mouser. Plugged one in, and Bingo everything started to behave. So the chips I had (Which are, now I look at them, NOT the ones Ben suggested, more fool me ....) clearly were a little flaky and the R/W line got stuck LOW.... for completeness for others arriving at this CPU via Bens YouTube series, I had WDC branded 65C02S8P-10's, Ben's shopping list has them as: WDC 65C02S6TPG-14. I don't know what difference they are, but that's another avenue of investigation.

Its been a huge pleasure diving into this fault... learnt stuff I would never have learnt if it hadn't occurred... guess that's what its all about...

All is well..... I shall remain a member of this Forum, lots of lively chat about some cracking topics here......

Re-posting the Schematic in Mono as requested....


Attachments:
20191028-1.jpg
20191028-1.jpg [ 865.29 KiB | Viewed 2229 times ]
Top
 Profile  
Reply with quote  
PostPosted: Fri Feb 07, 2020 10:07 pm 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
Quote:
WDC branded 65C02S8P-10's

Can you post photos of the top and bottom of these, or at least tell us the date codes? It's likely that these are counterfeits, especially if you obtained them from China (most AliExpress and many eBay chip sources are there).

The "S8P" in the middle tells us that this should be a mid-life (circa early 2000s) WDC part manufactured on the TSMC .8µm process, in the DIP-40 package; "early" would be 1990s. However, with the .8µm process, WDC began specifying all of their basic CPU and interface parts as capable of 14MHz, ie. with a -14 suffix. So this is already suspicious. The date codes and any identifiable markings on the bottom should clear it up.


Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 08, 2020 12:04 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8509
Location: Midwestern USA
Chromatix wrote:
Quote:
WDC branded 65C02S8P-10's

Can you post photos of the top and bottom of these, or at least tell us the date codes? It's likely that these are counterfeits, especially if you obtained them from China (most AliExpress and many eBay chip sources are there).

The "S8P" in the middle tells us that this should be a mid-life (circa early 2000s) WDC part manufactured on the TSMC .8µm process, in the DIP-40 package; "early" would be 1990s. However, with the .8µm process, WDC began specifying all of their basic CPU and interface parts as capable of 14MHz, ie. with a -14 suffix. So this is already suspicious. The date codes and any identifiable markings on the bottom should clear it up.

Chromatix's assessment agrees with mine. By the time WDC switched to the .8µm geometry there was only one speed grade, which is 14 MHz. So your S8P-10 part number would be fake.

We've had discussion elsewhere on this forum about the hazards of buying electronic components through eBay sources, especially Chinese sources. That good deal is often not good, as the odds are very likely you will receive counterfeit parts if you choose that route. Only authorized distributors will have genuine WDC parts and while it will cost a little more to go through one of them, at least you will know you've got what you think you've gotten.

Also be wary of 65C02s with the Rockwell brand. While Rockwell did produce a huge number of 65C02s, that was mostly in the 1980s and early 1990s. Production shut down in 1999, which means a genuine Rockwell 65C02 will have a date code no later than 99xx. The majority of Rockwell 'C02s still in circulation are pulls, not NOS. So, again, caveat emptor.

Getting back to your circuit, you need to pull the MPU's BE and SO inputs up to Vcc—CMOS inputs, as a rule, should not be allowed to float. Also, change R2 from 1K to 3.3K. RDY on the WDC 65C02 is bidirectional—the MPU will attempt to drive it low if a WAI instruction (opcode) $CB) is executed, intentionally or otherwise. A higher resistor value will limit the amount of current drawn by RDY when driven low to a safe level, while not making the input too noise-sensitive.

Assuming you are using a W65C22S, your IRQ circuit is okay. If you are using the W65C22N you must pull IRQ up to Vcc, as the 'C22N has an open-drain IRQ output. 3.3K is a customary value for the pullup resistor.

Your hookup to the SRAM is not good. /CS should not be qualified by the Ø2 clock—the address bus becomes valid about midway through Ø2 low. However, the SRAM's /WE does need to be qualified by Ø2 to prevent a wild write during the time when the address bus is settling. For best results, /OE of both the SRAM and the EEPROM should also be qualified by Ø2 to avoid possible glitching as the MPU sets up the address bus and other signals.

You may run into some trouble with your reset circuit at power-on. Many can oscillators require tens of milliseconds to start oscillating and stabilize. The short time-constant of your reset circuit may cause the MPU to come out of reset before Vcc is fully settled and a stable Ø2 clock signal is available. Lacking a stable Ø2 signal after coming out of reset, the MPU will likely play possum. Although it adds a little cost to the circuit, a Maxim DS1813 reset controller (or something similar) will hold reset down for about 150ms after Vcc has stabilized.

You don't have enough bypass capacitors nor are you correctly using them. Bypass capacitors should be used at each active device, with the capacitor connections as short and direct as possible to the device being bypassed. Merely bypassing across the power supply rails will do little for you.

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


Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 08, 2020 3:08 pm 
Offline

Joined: Fri Feb 07, 2020 7:09 am
Posts: 3
Pics of the chips as requested, don't appear to be any date codes.....

hope this helps...


Attachments:
File comment: Top of Chip
IMG_3750.JPG
IMG_3750.JPG [ 2.2 MiB | Viewed 2167 times ]
File comment: Underside of chip, no markings of any kind
IMG_3748.JPG
IMG_3748.JPG [ 1.57 MiB | Viewed 2167 times ]
Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 08, 2020 3:30 pm 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
Okay, in the second line of text, the date code is 1034, which means the 34th week of 2010. This is obviously wrong for the part number. Sometimes these date codes correspond to the date the chip was reprinted by the recycler, but I find it hard to believe that it's been sitting around in China for a decade.

The printing itself is also suspect. Normally white silkscreen is used on PDIP packages, but this appears to be almost black, and might even be stamped or engraved rather than printed on the surface.

Here's a photo of a genuine WDC 10MHz part - note the date code from the 1990s, and the different orientation mouldings.


Attachments:
W65C02S-10.png
W65C02S-10.png [ 172.33 KiB | Viewed 2163 times ]
Top
 Profile  
Reply with quote  
PostPosted: Sat Feb 08, 2020 8:29 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8509
Location: Midwestern USA
bellaf wrote:
Pics of the chips as requested, don't appear to be any date codes.....

hope this helps...

Definitely a fake. If the date code were valid it would be a -14 part made to the .6µm process.

Also, as Chromatix noted, genuine WDC parts are white silkscreened. They've been that way since at least the latter 1980s.

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


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 23 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron