6502.org

Yes, thanks for mentioning it. I'm using a spare NAND like this. Yes, it's the ribbons carrying power to the CPU, which is configured to receive "Host Power" through the CPU pins. Currently it's jumpers making the connection from the breadboard to the ribbons and then also between the CPU Cards. I agree that seems a little dodgy. The CPU will graduate to the test SBC shortly (I hope), and therefore to more robust power connections. I just might solder some wires directly to the boards as you suggest in the meantime. Thanks Jeff! I'm really enjoying the process.

Nice one - a Canadian classic

Several Gordon Lightfoot LPs are front-and-center in my collection. I've been listening to him since the late 1960s when he was hardly known in the States. I purchased his "Endless Wire" LP in a record shop in Thunder Bay in late 1978 and still have it right next to his "Sundown" LP, purchased in 1974. Due to my meticulous nature in handling LPs and the turntables on which they are played, they sound as good as the CD re-releases. Although most everyone went goo-gah over "Sundown" the tune, I always felt this one was the best one on the "Sundown" album and a prime example of his greatness as a troubadour.

I can't think of a more appropriate time/place to have made that purchase, except maybe Orillia!. And amazing the LPs are still in great condition. Nicely done!

(Incidentally, my wife wondered why I was humming "The Wreck Of The Edmund Fitzgerald" all yesterday afternoon ... )

I've never been up Orillia way. Did get up to Timmins once...many, many years ago. Most of my roaming around Ontario has been further south, especially around Belleville (home town of the "Golden Jet"), Gananoque and Kingston. To date I've visited six provinces: Nova Scotia, Quebec, Ontario, Manitoba, Alberta and B.C. I passed through Saskatchewan riding shotgun on a CP Rail freight train, but didn't actually set foot on the ground, so SK doesn't count. The furthest north I've been in Canada is Churchill, MB, during the winter of 1981-82, working on projects with the Canadian National and CP Rail. It was kind of chilly. The polar bears didn't look like the cold was bothering them much.
I've always handled my LPs with kid gloves, plus was careful about not using a stylus to a point where it would start scraping the grooves. The oldest LP I have was purchased in 1959 and still sounds pretty good.
Could that have anything to do with your not-so-little mess 'o wires?

After all the checking and re-checking, it's hard to believe this got through the QA process: S->PCH (a 74CBT3245 buffer) carries the result of the 16-bit Incrementer to the high-byte of the PC register, and all eight data lines were going to the wrong pins ... argh! This little mishap had the effect of inverting the bit-order of the high-byte of PC every cycle.

Good thing I picked up some practice patching the SBC. Here is what the afflicted area looked like after some head-scratching and careful rework:The output pins of S->PCH are lifted off the board, jumpers are soldered to each and then run to the correct pads below the raised pins. I used some silicone to cover the pads after the jumpers were soldered on, and amazingly there were no shorts once the job was complete. The multimeter confirmed all the data line connections are now correct and sound.

With that fix in place, I'm thrilled to report that the CPU passed it's first significant test! It ran a complete reset sequence and then went on to execute NOPs in succession beginning at address $EAEA, two cycles per NOP. Wow, this means that the basic piping is working: reading the data bus, latching into IR, stepping through microcode, incrementing PC. Hurray!

Next step is to run systematically through microcode and exercise the circuitry. The microcode is composed of about 190 unique micro-instructions, with many being only slight variations of fundamental operations. It's worth spending a little time optimizing the testing to run through a minimum set of basic operations before moving on to full opcodes and test suites. Here's hoping the inevitable problems that arise may be patched rather than requiring new PCBs! Gonna be a lot of fun.

Cheers for now,
Drass

So? Just put a footnote in the datasheet. Any programmer who can't be bothered throwing together a software workaround for a minor glitch like this is obviously lazy or incompetent!

Seriously, nice work on the patch. Did you consider placing four jumpers on each side of that IC, instead of all eight on one side? It might've been slightly less crowded if the swaps of D0<->D7 and D2<->D5 were on one side and the swaps for D1<->D6 and D3<->D4 were on the other.
Yes, hurray!
I'm impressed with your restraint! Surely you must be tempted to temporarily skip the detailed tests and immediately try some real code, just to see what happens!

J

"What's he talking about, footnote? ... what? ... oh, I see, hahahaha!" This had me laughing out loud.
Hmm, nice idea ... might have been easier. Still, getting at the pads below alternate pins without touching their neighbours would also be tricky.
Nooooooo! Way too scary!

Seriously, it's not restraint. The CPU won't get very far with "real" code. It's going to be faster to be more methodical:

• Can it write to every register?
  Can it read from every register?
  Can it set/reset flags?
  Can it pass data through the ALU?
  Can it use SP, DP and T for addressing?

These are all pretty fundamental functions. It won't take long to work through them, and any bugs which arise thereafter will be so much easier to track down!

Wow: _that_ bug really would be a nice feature for preventing your 6502 machine code from being disassembled and reverse_engineered.

Nice work on the patch. //I'm just happy that we don't have much signal traces on the inner layers of the PCB.


Back in 2002 (15 years ago), when I did build my first TTL CPU, I think there were to test suites,
there wasn't much info about building and debugging TTL CPUs in the internet, and I had not been a forum member.
Just peeling most of the bugs out of the microcode took me about three months.

I remember, that I had started debugging with LEDs and DIP switches on the bus.
The next step was writing a crude monitor program while deliberately and intentionally avoiding the use
of a lot of the 6502 instructions and addressing modes.

When I tried to get the C64 Kernal + Basic up and running, it displayed odd stuff for the amount of free memory.
It turned out, that something in the flag evaluation went wrong: CMP had affected the V flag,
what had confused them floating point math routines pretty much.


Drass, don't worry: sooner or later (February 2018 maybe) I think you are through with debugging that TTL CPU.
Hey, if it would be easy, and if it wouldn't be quite labor intensive, a lot more hobbyists would be building TTL CPUs...

It's not that the CPU intentionally refuses to come to life.

Thanks Dieter. As it turns out, there was lots of progress this weekend ...

Running the circuitry through it’s basic operations revealed more assembly problems, these almost entirely due to poor soldering. I suspect it’s the result of not allowing the iron to linger long enough at each pin during drag-soldering, or perhaps not enough solder applied in the first place. Whatever the cause, the pins in question would only make contact with the board when pressed down against the pads - this despite looking very much as if they were bonded to the pads below. Anyway, re-soldering fixed these problems in every case I could find.

Then it was time to hook up the TTL CPU to the SBC. I used extra jumpers to tie the diagnostic LEDs on the SBC to the appropriate CPU-internal signals. This would display both the current opcode and current cycle being executed on the SBC - very handy for debugging. In the pic below, the CPU is retrieving the high-byte of the reset vector at $FFFD during cycle 5 of the reset sequence (Opcode = 0, Q Reg = 5, Databus = $C0 - the start of ROM on the SBC is at $C000). Note the empty IC socket bottom-left on the SBC - that’s where the WDC 65C02 would normally go!My wife made the wonderful wooden switch-boxes shown; the toggle-switch on the left is a NAND-debounced step clock while the red push-button above the SBC is a convenient power switch for the whole setup. The on-board push-button for the step-clock on the SBC itself proved a bit dodgy, so it was necessary to pull the main-clock oscillator out entirely and wire-up the external manual clock to the oscillator IC socket (yellow-lead in the pic).

And with that done, things were ready to go. I sparked up the Kowalski assembler and coded up this little sequence:I gotta say, it’s absolutely amazing to see the TTL CPU step it’s way through this code. I’m thrilled to report the little contraption performed admirably! Register loads, memory writes and address calculations (including inserting an extra cycle into the microcode pipeline to adjust the high-byte of addresses) all worked correctly. Even the JSR and BCC backwards branch at the end worked perfectly. So exciting!

The next step is to try some I/O on the VIA, and if that works, perhaps wire-up a 555 timer and let the thing loose on Klaus’ test suite (which I will edit to report it’s progress to a VIA port). Lots of testing remains, so it will be some time yet before the CPU can be said to be working ... still, a lot is already happening. Can’t wait to see what happens from here!

Cheers for now,
Drass

Nice progress! I know the feeling

Axel.

Nice progress, and the debugging goes faster than I had expected so far.
Would suggest to focus on the UART as soon as possible and to try to get a monitor program up and running which makes use of that UART.
With a monitor program, you could get test code from the PC into the computer without burning it into the EEPROM,
what would make debugging a lot more fun.

Back in 2002, I only had EPROMs in ceramic package with a window, but not EEPROMs.
So I always had at least 5 EPROMs on the desk when trying out some test code, and I made sure that three of them always were in the UV eraser...

Go, Drass, go !

Thanks Axel. I really enjoyed following your build, and it gave me some good ideas about how I could connect the boards together for a debug setup. Very timely to sort that out! Yes, it was faster than I was expecting too - a nice surprise. I agree uploading code would be way more fun. That said, using an EEPROM works quite well also. It only takes a moment to burn one and it's on to the next test. I'm quite spoiled for tools really: Logisim modeling, Kowalski assembler, EEPROM burner, single step clock and diagnostic LEDs on the SBC. If necessary, I can even plug in an actual 65C02 into the SBC to verify the code "in situ" before trying it on the TTL CPU. It all makes for a great environment.

Btw, I did manage to confirm writing to the VIA by running a tight INC loop on the VIA ports: This bit of code revealed yet another "face-palm" mistake on the PCB where I mixed up the wiring; this time on the inputs to the "T" internal register. (I mean, honestly, ... ). Thankfully, these errors are easy enough to patch. It was nice to see the upper bits of port B blinking nicely once everything was fixed.

Oh, and the whole thing also worked with a 6MHz clock. That's surprising given all the crazy jumpers in this setup. Not quite the 20MHz target, but it's a start .

I'm looking forward to further shaking down these boards this weekend.

I started a run of Klaus' test suite, and things went wrong straight away - no surprise there. After all, it would have been a miracle if it worked first time. Examining the debris, I found the CPU was stuck on the BRK trap in the test suite. A run-away PC register, I thought. It didn't take long to find the last bit of code the CPU had executed before getting lost, but it was not what I expected: Yup, nothing there, just pushing and pulling from the stack. Stepping through, I found something surprising: the PHP at the end of the sequence was somehow resetting IR! The logic probe confirmed that the control signal used to clear IR (in order to trigger an interrupt) was not in fact firing during the offending cycle. And unlike previous errors, there seemed to be no flaky solder joints in the signal path. But, I reasoned, something must be pulsing the signal somehow. IR is a 74AC273, so even a momentary pulse on its /CLR input would be enough to inflict the critical damage.

Well, it turns out that the IR-Reset signal is generated in Card B but the IR itself is on Card A, and that implies a treacherous journey across the boards for this sensitive signal. Still, figuring out what was happening was going to be a challenge. Thankfully, just when I thought the inevitable oscilloscope purchase was finally upon me, dr Jefyll suggested a cheaper (and frankly much more sensible) way forward: "I'd give some attention to the VCC and GND connections." In actual fact, I had yet to follow the earlier pointer regarding more robust VCC and GND connections, let alone connecting the many GND lines on the inter-card connectors. My bad!

Lesson learned: after making many more jumpers and wiring everything up (including GND lines to the SBC), the rogue behaviour vanished! Amazing. Hunting this problem down has been just so interesting, and the solution seems like a bit of black magic. It's one thing to read about low-impedance paths, and quite another to witness their effects! I’m surmising that in addition to providing a good return path for signals, the GND lines here also serve to connect the ground planes on each board together to provide a common reference. Is it plausible that absent these connections, an IC generating a “high” voltage on Card B might be seen as a “low” voltage on Card A, enough to accidentally trigger a /CLR signal like IR-Reset?

Either way, it’s been an amazing learning experience and a very satisfying fix to make. And to top it all off, the CPU then ran the full NMOS 6502 test suite to completion. Double hurray!!!

Man, what a day

Ran the full NMOS 6502 test suite to completion?? Double hurray, indeed! Congratulations!! Break out the root beer!