I recently designed PCB (my first ever) for a project I've been working on. It is for a video game console based on the Atari 2600's video chip, basically an extension of the original hardware. Before I made the PCB I made a prototype by wiring together all the parts on a perf board which works well. Unfortunately there are issues with the PCB and it does not work at all. I'm going to check all the connections with my multimeter to see if they are correct, but I wanted to see if anyone had any tips for debugging this sort of thing. I have a suspicion that the traces on the board are too thin, they are something like 10 mills thick, and that is for all traces including power. It may be worth noting that I have a 2 channel scope.

Anyway, I appreciate any guidance you could provide!

Here is a picture of the board for kicks

A good place to start would be with a NOP generator.

BTW, is that tantalum the only bypass cap on your 5 volt supply? (I assume it's on the 5V supply.) If so, that could exacerbate any problem relating to the skinny power traces you mention. Ideally you want short, wide power traces, and, for each IC, a small (.1 or .01 uF) cap located physically close by. You might get by without one or the other, but it looks as if you're maybe missing both.

cheers,
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Looks pretty good overall. I see some solder smearing near the tantalum cap in the center of the board. Check to make that there are no shorts. Sometimes the solder mask is not as good as should be.

When I have this problem, I start with the bare minimum. Remove all socketed devices except the processor and the CPLD, which appears to be a Lattice part. I don't see a crystal oscillator on the w65c02s, first thing I would check are the voltages, and then the quality of the oscillator by checking Phi1O and Phi2O. I thought I read that the w65c02s requires a clock oscillator. Have you checked that it can work with a crystal or RC timing source?

Assuming that Phi1O and Phi2O are clean, and that the bus is not floating low, I would a BRA * program in location $FFFA and $FFFB, and then point the resetr vector to $FFFA. Then check the address lines to see if all but A2, A1, and A0 are high. The last three address lines should be changing state. You should be able to use A0 as a trigger, and use your other probe to check out the other address lines.

With this simple program, which you can extend, you've tested a significant number of the address lines, the CPLD decode logic, and the most of the data lines. It should stay in this program sequence forever. You can expand this little program to expand the number of address lines that you verify.

Finally, make sure the simple things like nNMI and nIRQ are not asserted. Also check, with the scope that nRST is going low and then high with a fast enough edge rate. nRST should be low for enough time to let the oscillator stabilized.

_________________
Michael A.

It's too late to do this on this one now, but before you get a board made, follow the checking method I describe at viewtopic.php?f=1&t=1888&p=17653#p17653.

Start with my debugging tips at http://wilsonminesco.com/6502primer/debug.html .


That's not a problem. I usually make them narrower. I have a six-layer .031"-thick bare board here for a credit-card-sized PCMCIA hard-disc drive (remember PCMCIA?) whose traces look like about .004".

Are there any bridges between those vias just to the right of pins 16 & 17 of the 6502?

The big green capacitors are fine for audio work, but not digital, because they have too much inductance. Use monolithic ceramic capacitors, and make the leads as short as possible. (That may not be your biggest problem keeping it from working at all though.)

What are all the capacitors in the upper-right corner for? If they're on the I/O, keep in mind that when output pins change state and have to suddenly charge or discharge those capacitors, it will put a huge jolt of current on the IC's power and ground pins, making the references for everything else jump. Not recommended.

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

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

Thanks for all the input, I'm starting to go through all the suggestions. I noticed today that when I probe ground pins on the ICs, there is some serious noise going on, in some cases +/- 150 mV. The VCCs all very flat and seem fine though.

The clock circuit etched into the board turned out to be incorrect so I made a separate circuit and wired it to the bottom. The clock output looks fine and I have used it in an old Atari 2600 with success. The solder mess on the top of the PCB is where the old clock circuit was and doesn't seem to have any shorts.

I also added a copper board connected to the grounds of the ICs. Just to see what would happen, I put a random capacitor I had laying around between the ground plate and +5 V. I'm still getting a ton of noise with these modifications. Perhaps I should try to power it with an external supply?

I'm sure the power supply circuit is horribly inadequate, I copied the simplest 7805 based circuit I could find (schematic here: http://i.stack.imgur.com/yeKoT.gif ). This whole project was rushed and limited by the free version of Eagle's restrictions, and of course my lack of knowledge of PCB design and Eagle cad. Once I got the autorouter to spit out a 100% completed layout, I went with it! I could post the schematic and board layout, but they are very very ugly. Rather than designing a new chip icon for each new library, I just copied a library with the same package type and re-purposed all the pins, so the ICs look a bit off. Also there are no wire connections between anything, only points I named and connected. There are no component values on the schematic either.

Attached is a picture of the bottom of the board, which probably looks hilarious to some of you guys It is a prototype after all

Anyway, thanks a lot for everything, hopefully we can get this thing working!

Note that the copper-clad board does not qualify at all for a ground plane, and will have no value when the connections to it are inch-long wires. The capacitor length and lead length will also have inductance that make it pretty useless. Be sure to read the sticky topic "Techniques for reliable high-speed digital circuits." Because of the small size of your board though, I expect it will work when the connections are right, even though it is not well designed for good high-frequency behavior.

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

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

I agree, it was dumb to not do it right the first time, I plead ignorance I'm a still a student and wanted to get this made before going back to school in the fall. I worked on it in the little free time I had while not at working at my real job.



So the crystal set up I have may be insufficent? It works in the other (soldered with wires) unit I have, though I suppose the combination of the iffy clock and poor layout would cause it to not work in this case? For what it's worth, when I probe pin 37 there is a squarish wave at the correct frequency/amplitude. I'll have to see if I can get a can oscillator locally. I suppose one like this would do the trick?

http://www.jameco.com/webapp/wcs/stores ... _325500_-1

For this type of clock, is a flip-flop absolutely necessary? How do you know if the output is symmetrical?

How's the rise time look at pin 37? And is the ringing bad enough to change states? (Make sure you're using the probe in the x10 position for anything like this.) What frequency are the 'scope and probes rated to?

The oscillator can you link to should be fine. If you're not nearly pushing the speed limits of the parts, a little asymmetry won't hurt anything because the high time and low time will still be plenty well above the minimum requirements.

I didn't catch the part about the autorouter before. I don't really recommend autorouters, but that by itself is probably not what's keeping the board from working. You can usually get better performance and density if you hand-route the traces while placing the parts. Optimization can be done better by humans too. There are too many possible valid tricks that the machine won't know about, like the first tip in my "Tip of the Day" column. (My work usually goes for the highest density practical, and we have critical things that won't necessarily work right just because they are schematically correct. Much attention must be paid to keeping digital and switching power supply noise out of analog lines, and to RF immunity, etc..)

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

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

Note that you can clock the 65C02 at pretty much any frequency starting at 0 Hz, so if you want to check if it's running (and if so, what it's running), you can take the crystal or clock generator off, and replace it with a flipflop that you set and reset with an SPDT type switch.

Pull reset down, generate 2 clock pulses by hand, pull reset up again, and generate another 6 clock pulses. Then check that the address bus is $FFFC, followed by $FFFD on the next clock. Check what it gets back from the ROM as reset vector, etc...

If you have a bunch of LEDs (and resistors) that you can connect to the address bus and/or data bus, you can easily trace through the entire reset sequence ("Altair style") and find out what parts are working and what isn't. You have an EPROM burner so you can easily write some simple assembler routines that can verify parts of the system.

===Jac

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