6502.org

Hi guys

I've built my first prototype 6502 and am trying to debug it. Currently it has no I/O, but is simply a 65C02 (2MHz), RAM, EEPROM and glue logic.
The debugging process is somewhat long winded as I'm doing it by hand using an oscilloscope to probe each bit of the address bus, data bus, and decoder lines. So each cycle means that I have to read 24+ points.
As this is more than a little tedious, I've settled on the idea of purchasing a logic analyser.
Now the question... does any one have any recommendations? I know that generally speaking the more probes the better. I was thinking of getting one with up to 30+ probes. Money-wise I can afford £60-£70 when I next get paid.

Any ideas/recommendations?

Ok, I found this: http://www.ebay.co.uk/gds/Logic-Analyze ... 214/g.html

Does anyone have any views on using a computer based digital analyser?

Be sure to check out the debugging page of the 6502 primer first, at http://wilsonminesco.com/6502primer/debug.html.

Have you published the latest version of your schematic?

After reading Garth's debugging page on his site, you may want to rethink spending your hard-earned money on a logic analyzer. I don't have one and have managed without one for years. I could easily afford to buy one, but haven't seen a need.

When I built POC V1.0 and powered it for the first time, it "sorta worked" but didn't produce any visible output on the console, which turned out to be a missing connection. I tracked down the problem using nothing more than my trusty B&K logic probe, my ancient Beckman 'scope (now in 'scope heaven, or wherever 'scopes go when they die) and a clear understanding of how the circuit should be behave. Later on, when I ran into a logic bug that was tripping up the DUART, I again figured it out with just the logic probe and 'scope.

24+ LEDs, with resistors to ground would be the simple method, surely? Set them up on separate boards in batches of 8 (for a data bus) or 16 (for an address bus) and you'll have a simple debugging tool that you can easily re-use, and costs far, far less than a logic analyzer that can handle that many inputs... Or even one of the cheapo USB analyzers that can barely handle eight signals.

There are problems with this approach as you start to ramp up the speed, but if it's running slowly enough that you have time to manually move a probe from point to point each cycle it's running slowly enough for this.

For something cheap and cheerful, consider the $50 Open Bench Logic Sniffer
http://dangerousprototypes.com/docs/Ope ... ic_Sniffer

I'll have a look at the open bench sniffer when IO get home from work - looks interesting.
Regarding the LED solution - you'd have to use darlington pair diode arrays for that surely? I.e. the LEDs would load the buses far too much even with limiting the current to, say, 5mA.

As for the latest diagram, it hasn't changed apart from:
- the addition of the manual clocking push button circuit
- replaced the entire 4MHz clock circuit (4MHz oscillator can+D type flip-flop) with just a 2MHz oscillator can
- To keep debugging simple the VIA hasn't been connected up yet

You would need some kind of a buffer to drive LEDs. However, there is no need to use darlington drivers or anything like that, 74HC logic can drive an LED through a suitable resistor - say 560 ohms to give about 5mA at 5V. Three 74HC541s can be used to drive 24 LEDs to display the data bus and the address bus. I've built such devices on plug-in breadboard when testing a system that wasn't behaving.

In your application, that should be fine. The flop becomes handy at high clock rates where the most rapid rise and fall time possible is needed. Anecdotally speaking, the W65C02S and W65C816S want to see the transition time under 5ns, which some TTL can oscillators don't always do.
You should post your schematics directly to 6502.org. You can attach JPEGs, PDFs and some other file types directly to your messages, which means they'll always be there, even if your website goes down for any reason. Also, if you move the website copy you may break links in your older messages.

As an aside, schematics might be easier to read in monochrome than color, especially for we old folks who are partially colorblind. I've been trying to follow your schematics but am having a tough time with the colors because they don't have much contrast.

Oh, one other thing. The value for R10 appears to be too low—470 ohms might be a better choice, as there's no point in beating on the power LED.

Paul's suggestion sounds good to me. Don't make it complicated. And if the 74HC output seems too weak, 74AC produces up to 24ma of drive.

I don't see any problem with the schematic itself.

Regarding LEDs for showing logic state: The CMOS outputs should be plenty strong as long as you're not trying to get too much brightness from the LEDs. You can get very efficient LEDs today, unlike the situation 30 years ago when NMOS processors, I/O, and memory reigned and LEDs were dim. In the breadboard for a commercial product I'm working on, I put an LED beside the shift key of the keypad to show the shift status and I only put 5mA though it and it's too bright for comfort. If you get high-brightness difused ones and use them just for debugging, even 1mA should be fine, if it's not for a super-low duty cycle that makes it appear much dimmer. In my experiments, I've had the WDC drivers even pull up to 4.2V with a 19mA load; so for 1mA through a red LED you could probably use a 2.7K resistor. (The LED takes about 2.2V IIRC.)
This schematic type is common, so I suspect it's from popular software and the user has no control over the colors. I've had intermittent slight fogging in one eye for the last 15 months (I can often get it to go away for a couple of seconds by rubbing it) and the gray letters on white background really slows down my reading. Young-eyed programmers and web developers think it's cool to soften the look, so this problem is rampant. It's everywhere! They say the monitor has higher contrast than black ink on white paper; but the fact is I never have the problem on the paper.

I suspect those of us with older eyes need to adjust our set (metaphorically speaking) - the world isn't likely to change for us. Fortunately we have computers - if the browser can't make the changes we need, certainly we can find software which will.

BTW, on the subject of images, it's best to attach the image to a post, rather than to link to an external one, as that provides both a mirror and suitable scaling.

Cheers
Ed

Thank you all for you suggestions. Driving 1mA through LEDs sounds like the easiest way to do this so excellent suggestion there. I've got a large bag full of red 5mm 1.9V LEDs. Not sure I have enough resistors as this is my second electronics project and so I haven't built up tons of components. Time to do some ebaying!

Regarding the schematic: I normally use the free version of Eagle from CADsoft (hence the colour scheme), but there's nothing stopping me converting it to black and white or grey scale. Which would you prefer/is easiest on the eyes for you? The "soft" look of the schematic I think is because it's a JPEG which is a lossy format. I could be wrong, though. However, if it can take a lossless format (I think PNG should be ok?) then I'll use that.
I've also edited my post above and attached the schematic to the post.

The power LED is rated at 20mA (max) @ 1.9V so thought 15mA would be ok. I'll reduce this to 10mA thus requiring a 310R. I'd normally go lower with amber/yellow LEDs and some other colours as they seem to quite bright, but the red ones I have are relatively dim in comparison.

PNG is okay, but GIF may be better with monochrome. I post my schematics in monochrome as GIF files, which are lossless for all practical purposes. Also, the resulting file is small and fast-loading. Some of the default colors in Eagle are too light a contrast for me to clearly see. Fiddling with the monitor, as Ed suggested, won't help because the light colors are on a white background.

BTW, when I post an image of a PCB layout, I do it on a black background with high contrast colors.

png and gif are the same for these purposes!