Dnia 00-07-27 Andrew Gale pisze: > My question is about the PC that gets written to the stack by > the z80 - clearly this is going to get written to RAM, exactly > where being determined by SP. This is fine assuming the program > being interrupted is using the SP sensibly - i.e. to implement > a stack -- but what if it is playing silly buggers with the SP > and some important section of memory gets overwritten? The easiest way to avoid this problem is to latch the NMI request from the button and then wait for the CPU to take opcode (/M1=0) dealing with the stack. The best are #C9 (RET) and %11xxx000 (conditional RET), assuming the code uses RETs at all. When you force NMI while #C9 RET, the new PC address is stacked back to the same location it was taken. In case of conditional RET two more bytes on stack can be used. (Also CALL opcode can be detected, what gives hunting for %11xxxx00 or %11001x01 opcodes.)
However this will not work in every situation - you won't stop the DI:HALT code. But you could use a switch to enable and disable "waiting till the opcode". Or use a monoflop to force NMI anyway after a time out. > I'm trying to decide whether or not to guard against this by > preventing the PC from being written to the SAM's RAM and > catching the values in some special latches instead... You probably won't be able to do it, as SAM doesn't allow to disable all memory access from expansion slot, untill you modify the SAM inside or use external CPU. In case when the SP points to ROM, you could latch address lines (A0..A15) with /M1=0. Then analyse the opcode at latched address. -- Yarek.
