Yes, I agree this needs to be stressed. For example, the address changes as a result of Phi2 falling. (And the data sheet refers to the associated delay as tADS.)

I believe AndrewP understands this, but his wording is perhaps ambiguous when he says the address "should have settled by the time you use it (when PHI2 rises or later)." Better to say, the rise of Phi2 should be -- needs to be -- sufficiently delayed after the fall of Phi2.

If it's true that we have delayed the rise of Phi2 sufficiently after the fall of Phi2, then tADS will have have elapsed before we bring Phi2 high.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yeah, clocking the CPU too fast won't be an issue for me - I was more asking to make sure the code on the AVR can talk to the bus properly. I'll have the AVR control the clock, so I can step it as fast or slow as I like (at least, as fast as I can toggle a GPIO pin), as well as get single-cycle and single-instruction operation without the need for extra stuff on the board.

It feels a little like cheating to use an AVR, but I don't really have anything else that can do the same job.

_________________
probably the youngest person on this forum

Sounds good to me. Using a microcontroller in this way is a perfectly valid and interesting project. There's more than one type of retro project.

Hear hear!

Neil

Progress! I have a basic monitor system set up, with two commands: "reset" and "cycle the clock". Every cycle it prints 1) the number of cycles since reset, 2) whether the bus operation that cycle was a read, write or instruction fetch, and 3) the value of the data bus.

_________________
probably the youngest person on this forum

Further progress! I now have single-instruction stepping and a somewhat dodgy fake UART. The current monitor interface is pretty clunky for actually talking to the computer, but the theory is solid.

The AVR has a buffer in memory which can be added to with commands. It also has a GPIO line connected to a pin of the VIA, which it sets high when there's data in the buffer, and a GPIO line connected to one of the IO select lines from the address decoding. If the select line goes low it either reads the data bus as usual but also notifies me that a serial write has occurred, or it takes a byte from the buffer and sends it to the data bus, depending on the state of R/W.

_________________
probably the youngest person on this forum

Excellent!

Yup, I know using micro-controllers feels like cheating but I'm fine with that. I've got Raspberry PI Picos littered all over my project

I'm feeling very proud of myself right now. I have successfully written a program that takes a byte from the serial input and then prints its value in hex to the serial output. From here it's a long but fairly clear road to a "proper" ROM monitor!

_________________
probably the youngest person on this forum

Sounds like good progress, these are important software building blocks to put in place and good practice at writing 6502 code.

I feel it's not far from 'Hellorld!'...

Neil

Just finished writing a hex dump routine, and came across a curious coincidence: my code, when assembled, contains the sequence "65 02" in hex.

I'm now working on monitor commands (dump page, read/write memory locations etc).

_________________
probably the youngest person on this forum

Hm, but shouldn't it be "02 65"?

(Little Endian! )

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!