From: john/lori (lgnjh_at_earthlink.net)
Date: 2005-04-26 22:52:57
Jim Brain wrote:
>
> You'd have to let it lag by 2 bytes, as some instructions are 3 bytes long.
>
> But that's a great idea. Use 2 byte FIFO scheme (2 74ls374 or so), and
> ignore all writes during normal operation. Tie IRQ to both CPUs.
>
> The only issue I see is when you IRQ the second CPU, it may itelf be
> finishing the next to last instruction, pulling data from the FIFO. How
> do you know when to pull it off the FIFO and onto something else that
> will allow one to get .A.X.Y and SP.?
>
> Jim
>
Like I said the devil is in the details
Can't say I've thought it through, but I think it would get hairier
than that.
I imagine getting the internal stuff via an ISR meaning you'd need to
generate that IRQ in such away that the slave had finished the last good
instruction, but the bad instruction hasn't done any damage.
Last good instruction might take 6 (7?) cycles before it updated the
internals.
And you won't know if the current instruction is good until it's done.
So you not only have to feed it the 2 or 3 bytes of the instruction,
you have to feed it the result and you'd have to wait for that result,
ie you'd have to lag by 6 or 7 cycles and the IRQ has to lag.
Then there's the little problem of possible garbage accesses ie mid
instruction reads that occur while the indexing and stuff is going on
but have no effect, which you'd (presumably) want your mmu to ignore.
So your hardware would have to know not only when the actual instruction
access occures but how long it takes, accounting for varying numbers of
cycles, so you know what to ignore.
hmm
Two slaves? one lagged and one in real time? :)
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.