Suggestion for internal core API: `bool` `IEmulator.IsHalted`

[YoshiRulz]

Would it be useful to have a standard mechanism for this, or is it enough that users can, for example, check disasm at PC for the halt instruction? My initial concept for this is for MainForm to check IsHalted after calling FrameAdvance, and if it becomes true, using the most recent framebuffer for all subsequent redraws (freezing the video output) and indicating a halt on the status bar. Basically the frontend behaves almost the same as is it were paused.

Another thing I'm not sure of is whether a simple boolean is sufficient. Is there a console with several distinct halt/crash states?

[CasualPokePlayer]

The GB/C has a halt instruction, which is its "low power mode" waiting for an interrupt. It also has a stop instruction ("ultra low power mode") which in practice is usually a crash or on the GBC used for speed switching. And it has the CPU jamming with any invalid opcode. Although Gambatte/SameBoy don't have a unique state for this, rather they just 0 the IE register and go into normal halt mode (0'ing that register prevents interrupts from occuring so the system is effectively jammed).

There's probably a lot of consoles too that have specific nuisances to their "halt" instructions or just their "halt" state, and they might not have such a state at all. This proposal though seems to be more for the system specifically jamming up and unrecoverable outside of a hard reset? There might still be quirks with video output in such a case still (say a jam makes whatever PPU output garbage data).

[YoshiRulz]

Hmm. It appears that the real world does not agree with my idea. FWIW my concept of "halt" was that the CPU stopped executing instructions—that is, infinite loops shouldn't count (mainly because I don't think detecting those is even possible). I was under the impression that the current convention is to throw an exception on halt, though I don't think that's even documented.