Interrupt pins and short pulses

[ulfalizer]

org wrote:

Here you go

Thanks for that!

Looking at that circuit diagram and in the simulator, it seems like the intended function of the circuit nearest to the pin might be to works as follows:

1. During phase 2, the value on the pin directly sets the latch.
2. During the following phase 1, the value is held and sampled (cclk severs the connection to ground on both sides, so the value on the pin no longer has any effect on the latch).

In the simulator, the value on the pin during phase 1 directly sets the output value though; see http://visual6502.org/JSSim/expert.html ... =6&steps=7. irq goes to zero during phase 1, and on the same half-cycle IRQP changes. Is this a timing glitch in the simulator, or am I missing something?

[BigEd]

Perhaps we should consider the irq input (and similar inputs) as misrepresented in visual6502 - actually being one phase earlier than they are shown.
Sorry about that
Ed

[ulfalizer]

BigEd wrote:

Perhaps we should consider the irq input (and similar inputs) as misrepresented in visual6502 - actually being one phase earlier than they are shown.
Sorry about that
Ed

What inputs does this problem apply to? It seems to be consistent at least, with the pin both being un-highlighted and the log showing it's low, so it's not just the log.

[BigEd]

Could probably figure this out by studying the source (but it's the middle of the night and I should go back to bed.) It seems like an ordering problem: everything happens at the clock edges, but whether it happens just before or just after is down to the structure of the code. Similarly whether it's displayed as just before or just after.
I should note that all the transistor (switch) simulation is not in doubt: the causal effects are modelled by repeated evaluation. It's just the I/Os which might be affected.
Cheers
Ed

[ulfalizer]

I looked quickly at the source, and I think the problem spots are here (in macros.js):

Code: Select all

// simulate a single clock phase with no update to graphics or trace
function halfStep(){
	var clk = isNodeHigh(nodenames['clk0']);
	eval(clockTriggers[cycle]);
	if (clk) {setLow('clk0'); handleBusRead(); } 
	else {setHigh('clk0'); handleBusWrite();}
}

Code: Select all

// simulate a single clock phase, updating trace and highlighting layout
function step(){
	var s=stateString();
	var m=getMem();
	trace[cycle]= {chip: s, mem: m};
	if(goldenChecksum != undefined)
		traceChecksum=adler32(traceChecksum+s+m.slice(0,511).toString(16));
	halfStep();
	if(animateChipLayout)
		refresh();
	cycle++;
	chipStatus();
}

In halfStep() the irq signal changes (as part of the clockTriggers for that cycle), and then the clock is flipped. In step(), the log (and maybe the visual display too) is updated in chipStatus(). Together this means that the change in the input signal will be logged as part of the next cycle after it changes.

Rearranging things so that you first do the clockTriggers, then log, and finally flip the clock would be a fix I think, if that wouldn't be too messy.

[BigEd]

Thanks for the investigation. I have distinctly mixed feelings about making a change, because it would change the reported results for existing published URLs. Note that there's no difficulty at all in the case that the interrupt input is constant over phi2 then phi1 - which has the look of a pulse which sits over the falling edge of phi2.
http://visual6502.org/JSSim/expert.html ... 6&steps=24

[ulfalizer]

BigEd wrote:

Thanks for the investigation. I have distinctly mixed feelings about making a change, because it would change the reported results for existing published URLs. Note that there's no difficulty at all in the case that the interrupt input is constant over phi2 then phi1 - which has the look of a pulse which sits over the falling edge of phi2.
http://visual6502.org/JSSim/expert.html ... 6&steps=24

It gets pretty confusing/counterintuitive if you shorten the interval and do http://visual6502.org/JSSim/expert.html ... 6&steps=24 though.

Perhaps a warning could be added if the behavior is changed. If it isn't changed, there should probably be a clearly visible note in the user's manual at least.

[BigEd]

Indeed, that is confusing. I may well add a warning. Or perhaps a mode accessible by URL - tacky, but backward-compatible.

[ulfalizer]

Any progress?

[BigEd]

Would this be the correct and expected display? This is for the same URL. IRQP is not shown, but is active in cycle 3, which is I think what we expect. It's a one-line change which isn't too hacky.

Code: Select all

cycle ab	 db	rw Fetch	pc	  a	 x	 y	 s	p	    Execute irq nmi
 0	0000	58	1	CLI	0000	aa	00	00	fd	nv‑BdIZc	BRK	1	1
 0	0000	58	1	CLI	0000	aa	00	00	fd	nv‑BdIZc	BRK	1	1
 1	0001	a9	1		   0001	aa	00	00	fd	nv‑BdIZc	CLI	1	1
 1	0001	a9	1		   0001	aa	00	00	fd	nv‑BdIZc	CLI	1	1
 2	0001	a9	1	LDA # 0001	aa	00	00	fd	nv‑BdiZc	CLI	1	1
 2	0001	a9	1	LDA # 0001	aa	00	00	fd	nv‑BdiZc	CLI	0	1
 3	0002	ff	1		   0002	aa	00	00	fd	nv‑BdiZc	LDA # 1	1
 3	0002	ff	1		   0002	aa	00	00	fd	nv‑bdiZc	LDA # 1	1
 4	0003	18	1	CLC	0003	ff	00	00	fd	Nv‑bdizc	LDA # 1	1
 4	0003	18	1	CLC	0003	ff	00	00	fd	Nv‑bdizc	LDA # 1	1
 5	0003	18	1		   0003	ff	00	00	fd	Nv‑bdizc	BRK	1	1
 5	0003	18	1		   0003	ff	00	00	fd	Nv‑bdizc	BRK	1	1
 6	01fd	18	0		   0003	ff	00	00	fd	Nv‑bdizc	BRK	1	1
 6	01fd	00	0		   0003	ff	00	00	fd	Nv‑bdizc	BRK	1	1
 7	01fc	18	0		   0003	ff	00	00	fd	Nv‑bdizc	BRK	1	1
 7	01fc	03	0		   0003	ff	00	00	fd	Nv‑bdizc	BRK	1	1
 8	01fb	18	0		   0003	ff	00	00	fd	Nv‑bdizc	BRK	1	1
 8	01fb	a0	0		   0003	ff	00	00	fd	Nv‑bdizc	BRK	1	1
 9	fffe	00	1		   0003	ff	00	00	fa	Nv‑bdizc	BRK	1	1
 9	fffe	00	1		   0003	ff	00	00	fa	Nv‑Bdizc	BRK	1	1
10	ffff	00	1		   0003	ff	00	00	fa	Nv‑BdIzc	BRK	1	1
10	ffff	00	1		   0003	ff	00	00	fa	Nv‑BdIzc	BRK	1	1
11	0000	58	1	CLI	0000	ff	00	00	fa	Nv‑BdIzc	BRK	1	1
11	0000	58	1	CLI	0000	ff	00	00	fa	Nv‑BdIzc	BRK	1	1
12	0001	a9	1		   0001	ff	00	00	fa	Nv‑BdIzc	CLI	1	1
12	0001	a9	1		   0001	ff	00	00	fa	Nv‑BdIzc	CLI	1	1

[BigEd]

Committed to github (thanks Barry) and pushed to the web:
http://visual6502.org/JSSim/expert.html ... 6&steps=20
now shows the correct timing behaviour. The URL is unchanged from before, and all the chip behaviour is unchanged, but shifting the display of the input signals has made everything appear correct too.

By convention, synchronous signals are shown as having a value for a full cycle, but this generally represents a new value which appears at some point after the falling edge of phi2, and which remains valid until the next falling edge, or possibly very slightly beyond. Usually signals are produced by flops and appear after the clock-to-Q time and some subsequent propagation delay, and will be captured by other flops and must therefore be valid prior to the falling edge (by a setup time) and remain valid afterwards (for a hold time.) In the case of inputs, we might try to show them becoming valid at the last possible moment, but a tabulation doesn't allow for that.

Cheers
Ed

[ulfalizer]

Hmm, that still doesn't match what I'd expect, but maybe I'm missing something.

My understanding what that the IRQ line would get sampled during the final cycle of the LDA, before the CLC fetch, but now it looks like it's being sampled during the LDA fetch cycle. Was the display shifted in the wrong direction?

[BigEd]

I do vaguely recall that IRQP has its effect during a T0 cycle, except for branches. See for example
here (t0)
http://visual6502.org/JSSim/expert.html ... 6&steps=30
but not here (t1)
http://visual6502.org/JSSim/expert.html ... 8&steps=30
and again here (t0)
http://visual6502.org/JSSim/expert.html ... 0&steps=30

[ulfalizer]

The log seems consistent with the logic around the pin now at least, so it's probably correct.

I remember reading in some places that IRQ is (usually) polled during the last cycle of the instruction, but it seems more accurate to say that it is polled at the end of the second-to-last cycle then.

Edit: Haven't traced very far, but looks like nodes nnT2BR (prolly "T2 of branch") and 646 (some kind of "sampling points" signal for #IRQP perhaps) might influence where the IRQ is seen. 646 seems to go high during T0 cycles for those examples at least.

Edit 2: Yeah, 646 seems to be "in T0". So maybe it's polled during T0 + T2 of branches...