I'm a little confused by the output of Visual 6502.



The 6502 Hardware Manual states that the Phase One clock pulse is the positive pulse during which the address lines change, and a Phase Two clock pulse is the positive pulse during which the data is transferred. This is also depicted in a timing diagram later on.

But looking at the example above, e.g. during the LDA abs opcode fetch, ab is set to $0003 in Phase One and we immediately also see the result on db in the same phase. I would've expected to see a lag of a half-cycle for the result, going by the CPU operation. Can anyone explain how to interpret the Visual 6502 results?

For a memory read, the data bus is driven by the memory, so the delay between the addresses stabilising and the new value being driven is a function of the memory speed (as well as the circuit designer's choice as to how to control the Output Enable.)

In the case of visual6502, it looks like we're simulating a very fast memory, without any special OE control, so the data appears on the bus immediately. (In fact, visual6502 isn't trying at all hard to model the external circuit: this is just the simplest choice that works.)

But to compare this with a 6502 datasheet, from that point of view what matters is when the 6502 is sensitive to the updated value on the databus. In particular, a designer wants to know what's the latest that their memory system can deliver data and still have the 6502 accept it and use it in that cycle.

So a typical timing diagram will usually show the data arriving late, towards the end of the clock cycle, with the constraint being annotated as to how late it can arrive.

Hopefully, there's no conflict between those two points of view: the visual6502 runs with a very fast memory, and the timing diagrams will usually show a very slow memory.

See this thread for more: Timing Diagrams. Visualizing 65xx Timing.


(The particular wording you give from the hardware manual seems potentially confusing to me: that's no great surprise, because it's difficult to describe this area succinctly and accurately.)

Edit: Further to the right in your trace capture, we see the 'pd' value does indeed change in phi2 - that's the predecode value, just before the new instruction gets captured in the IR. The predecode value is where a BRK can be jammed in in the case of an interrupt being taken. I wrote more about that here: Notes on the 6502 "predecode" block

Thanks Ed, yes that makes sense. I hadn't considered that Visual 6502 was modelling memory with essentially instantaneous memory.

That thread about the predecode value is interesting because it relates to an observation of mine, that somehow the 6502 seems to 'know' a 2 cycle instruction is about to be executed seemingly before it's even been fully decoded.

This simulation shows the exact half cycle that an IRQ is checked so that it's taken directly following a 2 cycle instruction.


(compare with this one, which shows the exact half cycle for a 3 cycle instruction.)

If we consider an instruction to end with T0, T1 (where T1 is the fetch for the next opcode), the rule seems to be that IRQs are checked in Phase 2 of the cycle preceding T0. In the case of a two cycle instruction, this is the cycle that the opcode itself is being fetched! The opcode hasn't even made it into IR yet, so I don't know how PLA access works at this very early stage. In any case, it's a surprising result.

There's certainly some decoding logic beside, and ahead of, the PLA. I haven't fully understood it!

But I've just realised: TZPRE in Donald Hanson's diagram could mean "Timing State Final - Predecoded" - that is, TZ is the end state of the timing. This symbol doesn't seem to appear in the 6502 schematics, although something like it must exist.

What special cases are there for two cycle instructions that would need special handling at predecode (via the TWOCYCLE signal)? The IRQ check certainly seems to be one of them. Another oddity is the T0+T2 thing which I've never really understood. It seems to me as if the IRQ check for 2 cycle instructions seems to be an additional bit of logic.

That said, I haven't yet figured where instruction cycle lengths come from either. I assumed it would be encoded in the PLA, but I didn't see any evidence of that last time I looked - there doesn't seem to be an output which sets the T state to T0, to indicate the pending end of instruction. Obviously the instruction length and the IRQ check T state are closely related. Are you hypothesising that TZPRE is somehow related to that?

I'm not sure at all, but we have all the information in front of us! It's just a big puzzle.

Looking at this sim we can note a couple of things:
- T1 is always the SYNC state, needs to be set up in the previous cycle
- T0 is true in the state prior to T1, needs to be set up in the previous cycle
- So we need a way to set up T0 in the same cycle as the fetch of a two-cycle instruction
- Hence the predecode

(Note that in visual6502, "clock1" is not-T0 and "clock2" is not-T1.)

I guess TZPRE is either the signal on node 792 generated from the predecoder for literals (except Push/Pull) and two cycle instructions or node 732.

See last two columns:

http://www.visual6502.org/JSSim/expert. ... 15,792,732

TZPRE always always asserts T0 and PRECEDES the next instruction fetch.

After all it's still just guessing?!

732 seems a closer match to showing the cycle before SYNC:
http://www.visual6502.org/JSSim/expert. ... re=792,732

Now I'm sure that TZPRE is the signal on node 792 and PRE is abbreviation for predecoder, hence:

TZERO PREDECODER

I came to this conclusion when looking at this document:

http://www.witwright.com/DonPub/DSH_650 ... erArch.pdf

Herein Hanson's name for the signal #METAL (1357 latched from 1528 at PHI1) is "TZERO" (see page 7 top) and he
describes it's usage in the T2-T5 shift register: "... TZERO is a clear signal ..."

This signal is OR'ed with signal from node 792 (#TZPRE) which perfectly explains it's usage:

If either TZERO (aka. #METAL) or #TZPRE is asserted the next state is T0 or T0+T2.

Good detective work!

Thanks!

My thanks too, for determining TZPRE. I was also wondering what it mapped to in visual6502.

I have an additional 2 cents about its naming. In visual6502, node 792 has a name of ~TWOCYCLE.phi1 in the nodenames section. This also supports the conclusion of it being the TZPRE signal, as it has its origin inside the predecode complex (the node named ~TWOCYCLE), and it plugs into controlling the clock.

Continuing to narrate its effect upon the clock (thinking out loud):

So... TZPRE is low for the two-cycle instructions, and that disconnects node 732 from being (indirectly) grounded by node 1528. Background for thoroughness: 732 ungrounded results in the T0 clock node becoming active (low). The disconnection feature allows the T0 and T2 clock bits (nodes) to the PLA to coexist in their active states (explaining that clock state), and giving us T0 earlier than normal. Ordinarily we would have T2 by itself and T0 in the next cycle.

For the two cycle instructions, the normal initiation of clock reset to T0 by the PLA is insufficient: the earliest opportunity by PLA is at T2. To compress operations down to one cycle between fetch cycles, the signal initiation has to be done one cycle earlier than T2, during the fetch cycle. Thus predecode originates it.

For non-two-cycle instructions, TZPRE is high. The clock can only be set to its T0 state by node 1528 itself being grounded (by another signal), allowing 732 to be ungrounded that way.

End of thinking aloud.

So now we understand this in terms of what originates clock reset to T0: predecode for 2 cycle instructions, and PLA for all others. The former initiates T0 without disturbing the rest of the clock state in progress.

Thanks again, and thanks for inspiring this romp.

An afterthought: the mention of TZPRE in Dr. Hanson's diagram really needs a horizontal negation bar over it to indicate active low.