troed wrote:... the code that follows (a "regular" trap #1 supervisor call) cannot execute since the trap #1 vector is not set up correctly. I'm not sure what the target hw does in that case actually
From the point of view of the 68000 hardware there is no such a thing as a non initialized exception vector. The CPU would read the exception vector and would attempt to fetch and execute at whatever address the vector points.
npomarede wrote:Yes, that's it. It seems that unlike "andi to sr" which allows to change SR and clear S bit, STOP will do a privilege violation exception (vector at addr $20) in case the requested value clear the S bit, which is the case with "#$777".
Yes, of course. A STOP that clears the S flags can trigger a privilege violation. It is clearly documented by Motorola. I am quite surprised this was not implemented by emulators and that it's the first time we found an example.
Yes, the stacked PC should be the one of the next instruction in case of the privilege exception ... It's not completely explicit in Motorola doc, but it still says that STOP increases PC then stop prefetching ...
Also, note that STOP can also be interrupted by a TRACE exception in case the T bit was set before the STOP. In that case, it could be interesting to check on real HW if the stacked PC is also pointing after the STOP.
It doesn't matter for this purpose what exactly STOP performs internally. All group 1 exceptions have the same behavior in this regard. In these two cases the PC in the exception frame should be the same, and also the same as the one in an interrupt exception. Only group 0 exceptions can interrupt an instruction at the middle and then can push a different PC.