6502.org

I would also suggest using CoolTerm, it is really easy to use and has some nice features.
Beside the Ophis assembler (be sure to check the "handbook) I'm using the py65mon for local debugging. You can write your assembler code and test it with this 6502/65C02/65Org16 emulator. It's perfect for debugging including breakpoints, step by step execution, etc.)
If you like a gui "emulator" then try "symon". It has similar features and emulates a 6850 ACIA or a 6545 CRT chip. The latest alpha version supports now also the 65C02 opcodes (at least the Rockwell ones).

For my MOUSE project these tools helped me a lot to get the software side done. Converting other assembler programs to the ophis syntax is painful sometimes, but you automatically get a deeper look into the software you convert. I've done this for the assembler/disassembler from Jeff Tranter, the VTL02 language from Mike and the famous microchess from Peter Jennings.

And this forum is always a place to ask for help or just get a shoulder to cry on

Mario.

I have managed to get the LED's blinking!

After reset the 65c02 chooses the follwing addresses:

FFFF
A9bb
01E5
01E4
01E3
FFFC
FFFD
A9A9
A9AA
A9AB ...

Does this make sense?

Not sure how to explain the first two lines, but otherwise, yes.

So after the initialising routine he (or her or it) jumps to FFFC
"Finds" the 8-bit OP A9 (LDA #)
This OP tells him that he should fetch the operant with next PC
PS up to FFFD
"Finds" Operant A9

But then I would expect that the PC increments to FFFE.

You can see the sequence in visual6502 here.

Now I got it.
He looks in FFFC & FFFD for the starting address.
Finds in FFFC A9 and in FFFD A9
Then je jumps to address A9A9 ---> PC A9A9
there he finds the opcode A9
Then he fetches the 8bit operant ----> PCA9AA
Then moves to next Instruction -----> PCA9AB
Then ....

Before I go to bed I need your help!
I connected the EEPROM 28C64.
Programmed

EEPROMprintContents
0600; a9 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
1ff0; ff ff ff ff ff ff ff ff ff ff ff ff 00 06 ff ff

After reset the 65C02 goes after some other strange addresses always to 1FFC (FFFC) and 1FFD (FFFD)
He reads the values $00 and $06

But than he doesn't jump to address $0600.
He jumps to zero.

Verify that the data values read from locations FFFC & FFFD are actually making it onto the CPU data bus pins at appropriate voltage levels.

What does your schematic look like?
Dwight

Thank you! The Mistake was (as you have certainly assumed) I have connected LEDs to the data bus without current limiting resistors. So the LED was showing the data, but the 65c02 got only 1,9V.

Now I am one step forward. Next step - next obstacle:
I have "coded"

0600:LDA
0601:
0603:BRK

0600; a9 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff

I have expected that the 65c02 stops at BRK ($00) moment and ignores the clock.
But the PC goes to 0604 and after this to 01ee and loops in a cycle of always the same addresses.

So I will study the manuals and tutorials. I guess this is a BRK-Routine.

Anyway - Thanks so much for your help. I hoped when I wake up a solution will come from heaven. And it didnt come from heaven but from USA.

BRK doesn't mean stop, it means to take a software interrupt. You should see the 6502 writing three bytes to page one, then fetching two bytes of vector from high memory (FFFE and FFFF), and then proceeding from that address.

BTW interesting problem with the LEDs - I would have guessed a timing problem.

I connected RAM, ROM, NAND to the 65C02.
Made it on one single breadboard. Wow! A lot of wires!
After everything was finished I realised during testing that I have an 64 KBit EEPROM with only 13 address lines. Since I don't want to change the address decoding logic (took it from the primer) I now will order an 256 KBit EEPROM. - So evaluation paused here

Question 1)
Buy the way: Which FTDI Serial to USB converter PDIP to you recommend?
It should the one which is easy to understand and easy to support by this forum.

Question 2)
Since I want to have LED's on address lines and data lines I wonder whether it makes sense to built in an bus driver (like LS245) for this LEDs so that the lines are not so burdened. Good Idea?

It is always a good idea to buffer heavy loads.
You also don't need to run LEDs at 20ma. They work
fine from 5 to 10 ma someplace.
Dwight

You could use 244's to drive the LEDs only (so the LEDs are not directly on the buses). Otherwise, know that LS cannot pull up anywhere near as hard as WDC's microprocessors can. Remember LEDs are diodes, and they will have a diode curve. If you can supply enough current to get a red LED up to 3.5V (70% of 5V for a CMOS logic '1'), the LED will probably let the smoke out. A red LED's working voltage is about 1.6V for very low currents to 1.9V for very high current; so with modern LEDs being plenty bright at say 2mA, let's say you want to operate at 4V for logic 1 and the LED takes 1.9V, that's 2.1V difference, and 2.1V/2mA is a little over 1K. Put a 1K or 1.2K in series with the LED. Something I have not measured is the LED's capacitance; but I'm sure you wouldn't want it on the buses when trying to run at full speed; so the resistor in series is all the more helpful since it will isolate that capacitance. If you really want to use a '245 to increase the drive, you'll have to use at least a 74AC(T)245. Not LS. 74HC can pull up much better than 74LS can, but it's still not as strong as the WDC processors' pin drivers.