6502.org

I'm guessing there will be a few ways you can do this. With the 6502 having been around for some 50 years now, I would think there have been a lot of clever people coming up with lots of clever ways to validate new builds. What do I mean by "validate"? Well, check it is working and, if not, attempt to find out where the fault (likely) lies. As most of you who have seen my posts will know, I'm pretty green when it comes to electronics and the art of 6502 builds. Notwithstanding, I have an old 10MHz 'scope and recently bought a cheap 8-channel USB logic analyser I can press into action when needed as well as an Arduino Mega 2560.

There is the obvious extreme of "build it in it's entirety, then switch it on to see if it works" approach. With a CPU, reset circuit, address decoding, RAM, ROM (with code or at least a monitor in there), VIA (1, 2 - or more!) and output (serial or, say, VGA), a beginner like me would have a slim to zero chance of this working with all that wiring and lines of code. Working first time? Really!? Not for me, no.

Then there is the the opposite approach or "build a little, test a little". For good or for bad, this is how I've always written my software, so I adopted this approach for validating my previous 6502 builds too. This is also a consequence of following Ben Eater's videos where he first uses resistors on the data bus to form a NOP command followed later by plugging in an Arduino Mega to monitor clock, R/W, address and data lines. I have also copied this approach. However, it requires a couple of constraints: a slow(ish) clock so you can see what is happening as the system resets and enough physical room on the breadboard to be able to get all the headers in. And getting them in and taking them out repeatedly is a right faff! I also program the ROM with code that contains some JSRs so I can ensure that RAM is working (the stack).
However, I'm attempting to construct my current build in a more compact fashion than the last one, thereby minimising wire lengths and maximising the chances of getting to 8MHz. With a 600mil PDIP package (6502, RAM and ROM), that only allows for 2 rows of strips to one side and 3 rows to the other.

But, I'd be interested to hear of other strategies or test equipment. Maybe you also have some test 6502 code you always use?

Thanks.

Dave

I’d separate logical correctness from speed. Running slow you can check your address decoding and glue logic. Once you know that’s right, you can explore the behaviour at speed.

Even running slow you might have signal integrity problems, or hold violations.

Even on breadboards, you’ve gotta stuff something up badly to not hit a stable 8 MHz. Some of my fastest tests still managed 30MHz easily on a W65C02, with lengthy wires on a breadboard.

Build it, then worry about cleaning it up.

Stating the obvious, perhaps, but make sure all the input pins on every device* are driven by something. It's too easy to accidentally leave a pin unconnected, and sometimes it will obligingly drift to a logic state that allows your circuit to function for days or even weeks. But then when the phase of the moon changes the pin may drift to the opposite state, or even start waffling back and forth. It's the result of an error that happened long ago, but you'll drive yourself crazy trying to associate the problem with something you did recently.

-- Jeff

* - with TTL and LSTTL families an unconnected input will kinda-sorta tend to pull itself high, but no such luck for MOS and CMOS!

To give you an idea. My latest W65C02 "work in progress" is currently running flawlessly at 16 MHz in it's current state.
As I said. The W65C02 is extremely forgiving. You really have to go out of your way to upset it. In my experience anyway.

Testing shows the presence, not the absence of bugs.

- Edsger Wybe Dijkstra; 11 May 1930 – 6 August 2002

I am pleasantly surprised that a simple quote I published, triggered a reply like the above.
That being said, all credit goes to E. W. Dijkstra.

Working as intended, then.

Things might behave differently at the bottom of a Volcano or something. Then yeah, I'd expect there to be a minor glitch or two.

There was a British maker of home computers—I don't remember the name—that sold a model that worked fine in their offices, but when customers got it into warmer temperatures, it failed.  I can imagine kids whose bedrooms got hot like mine did in the summer.

My first task with the company I've been working for until recently was to re-design a "smart" power supply.  It sensed changes in the load to determine when the user had put the product down and forgotten to turn it off (since usage made the load current keep changing), and it was supposed to turn itself off to save the battery.  The problem was that in hot weather, it wouldn't stay up.  My first step was to examine the original design.  I could see where the designer was going with it, but I could see that he didn't take into account the effects of temperature on a PN junction's voltage drop for a given amount of current, if I remember correctly.  I re-designed it, taking an entirely different approach.

Then of course there are software bugs that only show up when there's a combination of inputs that the programmer hadn't anticipated.

The debugging page of the 6502 primer is at http://wilsonminesco.com/6502primer/debug.html, telling of various aspects, hardware and software, for getting a basic computer going.

In a previous job, I had to design and build hardware that would operate at both ends of a drill string: -60C on the top in the arctic, and +175C at the bottom of the hole. Electronics gets interesting at the extremes...

Neil