6502.org

I'm going to truly show my ignorance here with this question, but here goes.

I have my PWA project narrowed down to 4 IC's: 65C02 @1.25MHz, RAM, EEPROM, and FPGA. Also a 640x480 display. The code in the EEPROM just inits the display, no zero page registers, or stack is used. I'm trying to negate all variables at this point, down to eliminating RAM. Do I still need RAM for zero-page and stack for it to run?

I guess the question boils down to, can the WDC65C02 run without RAM, if it is just addressing I/O?

Yes it can run without RAM but only by ruling out many actions which you may (too) easily take for granted -- such as JSR and RTS (which require the stack) and (Ind) and (Ind),Y address modes (which require Z-Pg.)

Your approach of trying to simplify, and to eliminate extraneous variables, is sound. If you're unsuccessful in initializing the display, I'd suggest you simplify even further. Eg: let your RESET vector point straight to a one-instruction loop. The loop is simply a JMP or BRA to itself.

Then check to see whether your system is running the loop. SYNC and all lines on the address and data buses should exhibit a repetitive, 3-cycle pattern (as seen on your oscilloscope) because 3 cycles is how long a JMP or BRA takes. Some lines will appear always high, or always low, but that qualifies as a repetitive, 3-cycle pattern. SYNC should be high for 1 cycle and low for 2 cycles.

-- Jeff
ps: did you resolve the voltage issue with your crystal oscillator?

Since I posted this, I've been reading the original MOS hardware manual. I couldn't find any clues to help me. So I wiki'd 6502 a few minutes ago, and there too they say JSR, RTS opcodes use the stack. What part of the stack (just curious)? Where is this stated in the documentation?

Thanks for the help! I am having extreme tunnel vision right now.

I am addressing $8000, $8001, and using LDA, STA, and JMP. opcodes only (looping the init display).

I'll check the SYNC.

SYNC, A0, display _CS ($8000), all active (oscillating). I am starting to think I have a dud display.

I didn't think to check the SYNC line to make sure the code was running (tunnel vision).

I think it's time I asked for an exchange on the display.

The fact it's "active (oscillating)" proves little; even after crashing the machine will continue to do that. You need the system to behave coherently. If you don't observe critically you won't know whether or not it's gone intop the weeds.

OK, I'll try JMP $8000.

I see D0,D1,D2,D4,D5,D6,D7 go high for about 450+nS, cycle is ~5uS. D1 is staying high just abit longer. No activity on D3.

Now is a good time to slow down and absorb what it is you're doing with the scope. I'd concentrate on the SYNC line, 'cause it's simple.

We think (hope!) the system is executing JMP $8000 again & again. If so, there'll be 3 cycles in the pattern: an opcode fetch of $4C (during which SYNC is high) then the fetch of the $00 byte then the fetch of the $80.

From this we see SYNC has a 1/3 duty cycle. Can you observe this? Also I'd encourage you to think in terms of Bus Cycles, not ns per se. Try using both scope channels so you can observe SYNC and Phase2 simultaneously. Get a feel for what's going on. The processor is quite regular & predictable in its behavior, but it's always the Clock Cycle that's the basic unit to bear in mind.

No, SYNC is an ongoing repetitive oscillation, no pattern.... Ah, Duty cycle! sec... It is closer to 1/5th duty cycle. Should be 3 cycles for 4C 00 C0. Why am I seeing 1/5 SYNC do you think?

My fault, Code is: JMP $C000. this is what I burned to the EEPROM, mistyped it as $8000 earlier.

I need a timeout! let my grey matter absorb. Thank you for your help Jeff! 1hr please.

Not 100% clear, but you seem to be saying there's a consistent, exactly repeating pattern of 5 clock cycles. NOT what we expected.

Are you using Wait States? Or anything else that'd cause deviation from predicatable timing? To further simplify, you could take the clock mux out of the programmable logic; just run at the slow speed only. Or observe Phase2 and SYNC simultaneously as I suggested, to verify you have 5 equal clocks (on Ph2) per SYNC.

This is a perfect occasion to stretch your muscles re use of the scope. Don't be in a hurry.

After letting it cool down since last post, I started it up and reprogrammed the FPGA. After resetting, SYNC is 1/3 duty cycle. Now reading 800nS high time, 2.4uS cycle. Not sure why I was reading 1/5th cycle before...


Not using any Phase 2 speed switching logic now, RAM totally disabled...

2 factors I am looking at now: the 5V regulator runs very hot although steady @4.95V. and the 80MHz oscillator is still pumping 5V into the FPGA, although the Spartan 2 is 5V input tolerant. I'll rewire the osc. VCC to 3.3V

The 1/5 SYNC signal was from improper resetting after programming the FPGA I think...

Once again seeing the 1/3 duty cycle SYNC.

5V oscillator now out of the variable list. Now EVERYTHING @3.3V.

I get that you're eager to keep moving. But the oscilloscope topic is one worth reviewing in better detail, so I've created a separate topic here.

-- Jeff

I decided to further post here to keep the new topic clean. It needs to be clean. I may repeat my question on there "where is the info on zero page/stack usage by certain opcodes?"

I have kept the earlier iteration of my project fully intact. The one using the 320x240 NHD display...

I am at the point where I am going to rewire the FFC connector, originally wired for the 640x480 display, so it will accomodate the older 320x200 display.

I am really expecting another problem from this company's display(this isn't the first time), and since they have refused to answer a very simple question on their forum from me, if it does prove to be a display problem which has put more people than me to task, I will **** all over them!

You've made some good progress, so I wouldn't be too hasty about rewiring that display connector just yet. Is there a valid chip-select to the display? Using the dumbed-down loop idea, you could check it: This should be a 7-cycle loop. The chip-select should be active for 1 cycle. If not, find out why not. If it's OK, check whatever else the display needs. (Might the display previously have gotten damaged by receiving a 5V clock?)

Edit: I changed LDA to STA. Your display may be write-only; in any case, it'll be handy to have the R/W line go low to help you identify (with your 'scope) which cycle is the one that ought to activate the display Select line. Use 2 channels; one on R/W, the other on Select.
Edit 2: 7-cycle loop, not 6 -- sorry! STA will be Absolute mode.

-- Jeff