This is a spin-off from ElEctric_EyE's topic here.

The goal is to determine whether your new, untested system is executing your loop at $C000.... or executing garbage at who-knows-where! To make things as simple as possible and eliminate extraneous variables, the loop is simply one instruction: JMP $C000 -- ie, jump to itself. The RESET vector goes straight here. Your loop should show the following pattern (assuming regular, periodic clocks and no Wait States etc):

What we expect on the data bus is $4C $00 $C0 (endless repetitions of your JMP $C000 instruction), with SYNC high on the $4C. Your scope shows you only 1 bit at a time, though -- not the entire byte. Luckily, it's no great trick to read the columns vertically, which shows, in time, what each line is doing, cycle by cycle. ie: d7 is 0 0 1. d6 is 1 0 1. d5 is 0 0 0. [etc] SYNC is 1 0 0.

One challenge is that, for example, d7 may appear as 0 0 1 or as 0 1 0 or as 1 0 0 -- which is really just the same pattern, but viewed from different perspectives, timing-wise. So, having a consistent timing reference is gonna cut through a lot of confusion, obviously.

A useful reference in this case is SYNC, which we expect to be true only on the opcode fetch: the "first" cycle of our loop. So, hook one probe on SYNC and leave it there. Set your scope to synchronize to that signal. Be sure you have a stable display. THEN use the OTHER probe to go poking around and checking individual signals against the chart! Because you have your reference, there's no confusion over which cycle is which. Having the reference (by using two channels) is what makes this powerful technique possible. I call it the poor man's Logic Analyzer.

Address lines tend to have cleaner signals than data lines, so maybe I should've mentioned them first. (Data lines usually have crap on them except near the end of each cycle -- so that is what you need to observe.) OK, here's my chart again but showing some address lines. The same "read the columns vertically" method applies:

I haven't shown all the address lines, but you get the idea I'm sure. What the address lines tell you is where the cpu is fetching code from. If it's not fetching from $C000 then it's executing garbage (which it will willingly do -- cpu's is dum)

-- Jeff

So I can be 99% sure, IF everything running correct based on the example, that D0, D1, D4 & D5 should never change. The SYNC signal should spike once and A15 should always be high (I have observed that).

Not at the point of using 2 probes yet...

Much obliged for your help!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

What we're dealing with is the cycle-by-cycle behavior of the 65xx cpu -- a topic which ideally should be second nature if you're forced to wrangle at the nethermost hardware levels. For reference material on this I suggest the MOS MCS6500 Family Hardware Manual, Appendix A. Another good source is the 65C816 Data Sheet; see Table 5-7.
Correct. Specifically, they'd be low.

Do you have a mini-clip or jumper that'll attach to a point and allow you to let go of one of the probes? That niggly little nuisance is about the only difficulty you'll encounter...

-- Jeff

Got up this morning for a fresh start. So I jumped right in! I have 4hrs before work...

Observing the address/data lines are good if you have a logic analyzer I guess since they're always changing. We'll keep it simple like you said and forget about the data lines. I focused on the SYNC signal only.

With JMP $C000 (loop to itself) as the only code running, I see SYNC go high (~800nS) for 1/3 of the cycle(~2.4uS). Also I checked the display TFT/CS, nothing happening there yet which is good.

Next I reprogrammed the EEPROM: LDA $8000, JMP $C000. I saw 2 unique cycles. The first is 1/3, the second is 1/4 (with a slightly longer cycle, I guess for the PC to go back to $C000). The TFT/CS line is going low too.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

This technique of looping and checking SYNC will be my new SOP.

Next on my list:

1) Ramp up speed of current 1.25MHz WDC65C02 to 2.5MHz, using EEPROM only.
2) Try EEPROM to SRAM Copy and run WDC65C02 @5 or 10MHz, with loop at the end to identify SYNC

Dang, is this OT?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

LDA $8000 is the one that takes 4. It takes one for the op code, one for each address byte, and one for the actual fetch from 8000. JMP takes 3.

Well, the topic is troubleshooting using a 'scope, so I'd say this a good example as long as we speak in general terms.

It's worth looking at what has taken place. You've been able to rule out a great many variables, thus putting you closer to the truth of what's going on. Divide and conquer is the essence of troubleshooting.

The new display -- your system's main IO device -- is suspect. But, more basic than that, even, is whether the system is even running your code at all! (For example due to an EEPROM decode issue.)

The scope revealed a problem running your code; then, after you got the 3-cycle loop running correctly, you were able to expand the scope (so to speak) of your investigation, and now you're verifying the decoding and chip-select logic in the PLD (and verifying correct wiring as well).

Even though you have no IO (or at least only suspect, untested IO), the 'scope is acting as your IO. Output, I guess I mean. Anyway that's the beauty: the scope provides output capability even when nothing else in the system is working.

When you're ready, the next step will open your eyes even further.

-- Jeff

Tips #35, 36, and 37 in my "Tip of the Day" column address debugging from the basics. Getting started is addressed here.

I tried to jump ahead and do the EEPROM to SRAM copy @1.25MHz and run the system @5MHz. SYNC went dead after the SRAM was enabled and the CPU reset meaning either: 1) I am not giving the software enough time to copy $C000-$FFFF from EEPROM to SRAM, (unlikely) or 2) There is a problem with the bank switching hardware controlling addresses to the SRAM. Since I am using zero page for indirect indexed to copy 16K, the bank hardware is constantly flipping from upper 16K, where the copy program resides, to the lower 16K where zero page is...

Before I do tackle this problem however, I think I should focus back onto initializing the display, which is just LDA/STA, running from the EEPROM @1.25MHz.

Garth I used to use a '374 as a test port as well for an initial test to make sure everything was wired correctly etc. on my first iteration of the PWA. I actually did think of trying to put it inside the FPGA, but never got around to it... Testing SYNC seems to be an even more "bare bones" approach to initial startup, because you're testing right at the CPU itself.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I've been thinking...

After I try initializing the TFT display, and that fails again (I expect), I would like to analyze those "undefined" NOP's. $42 & $C2 if I remember correct.

Its an undefined NOP so I can Jump back to it and analyze it.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Good man! -- you're catching on to the possibilities! The "Poor Man's Logic Analyzer" -- a 'scope and a loop -- is how I gleaned all that Undefined-Opcode info in the first place! (in the 1980's).

It's the same one-bit-at-a-time technique. But (unlike our example above) I didn't know what I should expect to find. Writing the loop was easy enough. Then, starting with a blank chart, I scoped around in order to pencil in one column (ie, address, data or control line) at a time. When I had all the bits filled in, THEN I could look at the complete hex values and get a sense of what it all meant.

Nowadays (and even back then, I suppose) that info is available from other sources.

-- Jeff
ps: I replied to your PWA comments but in the PWA topic.