Posted By
TLC
on 2007-01-09
06:16:26
|  Re: Plus/4 Expansion port...
I've been playing with ideas about this freezer-thing for a while...
For an approach where hw IRQ' is exploited (where it's important that the currently running software uses interrupts), the current problem is that we don't know, exactly when would the execution of the interrupt request finally taken into account. Until the mechanism would start, we can't safely pull A9 low to hijack the read from $fffe/$ffff. But... what if we modified this method a little bit?...
What if we didn't care about the IRQ line, but rather based the start of the freezing on the CPU reading the IRQ' vector?... At first, sensing the addressing of $fffe by the CPU is a good sign of the IRQ' mechanism to be currently executed. By hijacking the IRQ' vector at this minute, the freezer could be made perfect. ...Or maybe not. Maybe, it's too late at this minute, to turn on the external ROM + asserting A9, for the CPU to read from $fdfe.
...What if we waited until a read was executed from $ffff (this alone, signs that an IRQ is currently being started to be served), then -- for the next CPU cycle -- forced all databus bits to 0, and _then_ turned the ROM / A9 trick on. This would result in executing a BRK, effectively starting yet another IRQ' process, but now we would know what is going on and could have the IRQ' vector hijacked way before it's actually read. (I'm not sure if all this is actually neccessary).
A slightly more complicated approach could be not to rely upon hardware interrupts at all, but force executing a BRK instead. Putting something to the databus, regardless to the value given by the motherboard RAM is possible somehow (those memory expansions for the C16 work exactly like this). The hard part is to figure out, if a particular fetch from memory would be an instruction byte fetch or not. A simple work-around could be based on the fact that simple write opcodes (those with only one single write cycle ) would always execute a memory write as their last cycle; thus, the next cycle would always be an opcode fetch (which could be hijacked by forcing a BRK, ie. 0). After successfully completing this, the known ROM / A9 trick could be activated... the fact that executing a BRK doesn't depend on the I bit would make sure that the interrupt request mechanism is executed immediately (ie. it's actually safe to pull A9 low by then). It could also freeze programs disabling interrupts completely or enabling no hardware interrupt sources.
|
