It begins! (Wren Prototype build log)

[Dr Jefyll]

BigEd wrote:

causality

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

[BigDumbDinosaur]

AndrewP wrote:

Yup, that’s exactly it:

6502Timings.png

Sigh!  Can’t read your attachment due to color.  Parts of it are invisible.

Quote:

Just a reminder that you control when PHI2 rises and falls (by selecting a clock frequency) so if your clock is too fast the address lines will not yet be valid when PHI2 rises.  That only starts becoming a problem around 40MHz* so probably not a worry.

In other words, overclock at your own risk.

At any given set of operating conditions, i.e., voltage and temperature  there is a maximum Ø2 where the MPU’s internal propagation times cause a loss of synchronicity, for lack of a better term, in the MPU’s circuits.  When that threshold is reached, either no bus activity will be seen or bus activity will be nonsensical.

Further affecting the Ø2 “ceiling” is bus reactance.  Excessive bus reactance, specifically parasitic capacitance, will cause edge rounding, which will be seen by devices as excessively-slow input transitions.  Also possible is signal skew, which may introduce obdurate timing problems in some cases.

Quote:

That also means you can start doing address decoding as soon as PHI2 falls and it should have settled by the time you use it (when PHI2 rises or later).

Implied by that is address decoding logic should not be qualified by Ø2, with rare exceptions.  One such exception would be using a 28L92 DUART in Motorola bus-compatibility mode.

[BigDumbDinosaur]

BigEd wrote:

I think I'd say that the address lines are generally, usually, probably, valid at the time phi2 rises.

The address bus and control signals (RWB, VPB, etc.) are always valid before the rise of the clock.  Such behavior is required by 65xx peripheral devices, which explains why qualifying 65xx device chip selects with Ø2 will fail.

It’s important to note, as Jeff shows above, that all 65xx timing starts with the fall of the clock, not the rise.  Understanding this characteristic of the 65xx bus cycle is especially important with the 65C816 when considering the latching of the bank bits.

Speaking of the Ø2 clock, clock signal quality with the WDC devices is paramount.  WDC’s specs require the clock transition rate be no slower than 5ns peak-to-peak, and the signal must swing to a minimum of 80 percent rail-to-rail.  Clock symmetry can also get you if your machine is running sufficiently fast.  If you are running into stability issues at high Ø2 rates, be sure to scope your clock signal.  You might be in for an unpleasant surprise.

[allisonlastname]

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.

[BigEd]

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.

[barnacle]

Hear hear!

Neil

[allisonlastname]

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.

[allisonlastname]

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.

[AndrewP]

allisonlastname wrote:

Further progress! I now have single-instruction stepping...

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

[allisonlastname]

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!

[gfoot]

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

[barnacle]

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

Neil

[allisonlastname]

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).

[Dr Jefyll]

Quote:

"65 02" in hex

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

(Little Endian! )

-- Jeff

[BigDumbDinosaur]

Dr Jefyll wrote:

Quote:

"65 02" in hex

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

(Little Endian! )

-- Jeff

...or perhaps ᄅ0ϛ9.