How do YOU validate your new (breadboard) builds?

[DRG]

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

[GARTHWILSON]

The 6502 primer's debugging page is at http://wilsonminesco.com/6502primer/debug.html .  It's all I have ever done.

[BigEd]

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.

[J64C]

DRG wrote:

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.

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.

[Dr Jefyll]

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!

[J64C]

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.

[BigDumbDinosaur]

J64C wrote:

To give you an idea. My latest W65C02 "work in progress" is currently running flawlessly at 16 MHz in it's current state.

Not sure that I’d trust that in my airplane’s flight control computer. 

[GARTHWILSON]

Yeah, I've come to understand, over the years, that "It's working perfectly!" just means that the problems have not shown up yet under the current working conditions.

[L0uis.m]

Testing shows the presence, not the absence of bugs.

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

[BigDumbDinosaur]

L0uis.m wrote:

Testing shows the presence, not the absence of bugs.

Ain’t that the truth!  Outside the realm of software, the saddest example of that aphorism was likely the Lockheed L-188 Electra airliner, which was arguably the most-tested large aircraft design of the 1950s, and was considered to be exceptionally robust by the standards of the time.

What testing didn’t uncover was a propensity for an aerodynamic phenomenon referred to as “whirl-mode” flutter, which ultimately led to two in-flight airframe breakups.  Whirl-mode, which is best described as an oscillatory motion similar to the precession of a child’s top as it slows down, would only occur under specific flying conditions involving a combination of airspeed, engine power output, propeller pitch and turbulence.

Although the whirl-mode phenomenon was known at the time of the Electra’s genesis, the radial engines in common use on large airliners had sufficient mass to suppress oscillation.  The Electra’s turbine engines had a much-higher power to weight ratio, giving them less mass, so they couldn’t be effective as dampers.  Complicating matters, the Electa’s huge, paddle-blade propellers (over 13 feet in diameter) generated very strong gyroscopic forces when flying through turbulent air, which caused considerable localized stressing of the engine mounts and wings.  With the right conditions, whirl mode would progress to a point where the natural resonant frequency of the Electra’s short and stiff wing would be excited, and metal fatigue did the rest.

It was also noted during the investigation of the crash of Northwest Flight 710 that it had been subjected to a “very hard” landing at Chicago’s Midway Airport immediately before the flight that resulted in its breakup and crash.  Examination of the plane while it was at Midway didn’t reveal any visible structural damage, but there was unseen engine mount damage that, it was surmised, exacerbated the effects of whirl mode.

In all of the exhaustive wind tunnel testing done on the Electra’s airframe during development, that one particular combination of circumstances was never simulated, as the primitive computer modeling done at the time had not indicated any such possibility, and whirl-mode simply had not been an issue with large, piston-powered airliners.  Hence there was an “undiscovered bug” in the Electra’s design that tragically resulted in loss of life.

I should note that despite the crashes and the Electra’s loss of reputation, the design went on to be long-lived once Lockheed had corrected the problem.  The military version, the P3 Orion, is still in use around the world, and the civilian version is likewise still flying.

[L0uis.m]

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.

[J64C]

GARTHWILSON wrote:

Yeah, I've come to understand, over the years, that "It's working perfectly!" just means that the problems have not shown up yet under the current working conditions.

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.

[GARTHWILSON]

J64C wrote:

GARTHWILSON wrote:

Yeah, I've come to understand, over the years, that "It's working perfectly!" just means that the problems have not shown up yet under the current working conditions.

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.

[barnacle]

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