Page 2 of 2
Re: Interrupt pins and short pulses
Posted: Tue Jun 11, 2013 10:02 pm
by ulfalizer
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:
- During phase 2, the value on the pin directly sets the latch.
- 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?
Re: Interrupt pins and short pulses
Posted: Wed Jun 12, 2013 2:57 am
by 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
Re: Interrupt pins and short pulses
Posted: Wed Jun 12, 2013 3:19 am
by ulfalizer
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.
Re: Interrupt pins and short pulses
Posted: Wed Jun 12, 2013 3:28 am
by 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
Re: Interrupt pins and short pulses
Posted: Thu Jun 13, 2013 3:57 am
by 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.
Re: Interrupt pins and short pulses
Posted: Thu Jun 13, 2013 4:37 am
by 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
Re: Interrupt pins and short pulses
Posted: Thu Jun 13, 2013 4:56 am
by ulfalizer
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.
Re: Interrupt pins and short pulses
Posted: Thu Jun 13, 2013 5:02 am
by BigEd
Indeed, that is confusing. I may well add a warning. Or perhaps a mode accessible by URL - tacky, but backward-compatible.
Re: Interrupt pins and short pulses
Posted: Tue Jun 18, 2013 12:49 pm
by ulfalizer
Any progress?
Re: Interrupt pins and short pulses
Posted: Mon Jun 24, 2013 4:51 pm
by 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
Re: Interrupt pins and short pulses
Posted: Thu Jun 27, 2013 8:37 pm
by 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
Re: Interrupt pins and short pulses
Posted: Sun Jun 30, 2013 4:43 pm
by 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?
Re: Interrupt pins and short pulses
Posted: Sun Jun 30, 2013 7:37 pm
by BigEd
Re: Interrupt pins and short pulses
Posted: Wed Jul 03, 2013 3:24 pm
by 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...