BigDumbDinosaur wrote:
I wonder if it's some sort of clock-stretching thing...
phillhs wrote:
I think it's to do with what's mapped where....
I think Ed's post leads us to the answer; did you overlook that? I haven't yet fully digested the info myself. We need to carefully read what's at
the link he posted.
BigDumbDinosaur wrote:
to indicate to the machine that a fetch is the start of an instruction and not an interrupt, you'd need hardware logic that would say OPCODE_FETCH = VDA & VPA & ABORTB & IRQB & NMIB.
That approach presents challenges. Even qualified by SYNC or by VPA and VDA, a low on an interrupt input doesn't equate to interrupt recognition. The interrupt signals pass through on-chip flipflops as a form of input conditioning, resulting in latency prior to recognition. More daunting to predict is the
variable latency due to branches taken, as mentioned
here. Also you'd need to accommodate the fact that IRQB is internally maskable, again affecting recognition. These problems are solvable perhaps but there's a tidy alternative solution: just look for
the missing increment of the PC that occurs when the interrupt
does get recognized. As shown below, flipflops and an XNOR gate can detect the increment (or lack of same). If the RDY input is in use (ie; wait states exist), use a '377 type flipflop with its data Enable input also driven by whatever drives RDY.
cheers,
Jeff
Edit: XNOR, not XOR
Attachment:
Interrupt-recognition detector.gif [ 4.86 KiB | Viewed 1861 times ]
_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html