From: Jim Brain (brain_at_jbrain.com)
Date: 2005-04-23 23:31:07
john/lori wrote:
> Jim Brain wrote:
>
>> It gets worse. The opcode in question could have updated an internal
>> register:
>>
>> $67ff and #$10
>>
>> 67ff (and) gets pulled.
>>
>> $6800 is page fault, so force 0. Uh oh, as now .A is corrupt, and
>> there is no way to reset it.
>>
>> The only real way to do this is not allow such things to occur. Scan
>> incoming code at page boundaries to insert BRK opcodes to handle such
>> issues before you step into them. Or, ensure code that runs in your
>> system does not create such issues.
>>
>> Jim
>
>
> There have been schemes (or so I've read) that run a slave processor in
> parallel to make internal stuff available that would not otherwise be
> available
>
> How about running a slave processor but let it lag by one
> instruction and take the internal stuff from it when your hardware
> throws an exception?
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
--
Jim Brain, Brain Innovations
brain@jbrain.com http://www.jbrain.com
Dabbling in WWW, Embedded Systems, Old CBM computers, and Good Times!
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.