halt is an instruction that pauses the CPU (during which less power is
consumed) when executed. The CPU wakes up as soon as an interrupt is pending,
that is, when the bitwise AND of
IF is non-zero.
IME is not set, there are two distinct cases, depending on whether an
interrupt is pending as the
halt instruction is first executed.
- If no interrupt is pending,
haltexecutes as normal, and the CPU resumes regular execution as soon as an interrupt becomes pending. However, since
IME=0, the interrupt is not handled.
- If an interrupt is pending,
haltimmediately exits, as expected, however the “
haltbug”, explained below, is triggered.
halt instruction is executed with
IME = 0 and
[IE] & [IF] != 0, the
halt instruction ends immediately, but
pc fails to be normally incremented.
Under most circumstances, this causes the byte after the
halt to be read a second time (and this behaviour can repeat if said byte executes another
But, if the
halt is immediately followed by a jump to elsewhere, then the behaviour will be slightly different; this is possible in only one of two ways:
haltcomes immediately after a
eiinstruction (whose effect is typically delayed by one instruction, hence
IMEstill being zero for the
halt): the interrupt is serviced and the handler called, but the interrupt returns to the
halt, which is executed again, and thus waits for another interrupt. (Source)
haltis immediately followed by a
rstinstruction’s return address will point at the
rstitself, instead of the byte after it. Notably, a
retwould return to the
rstan execute it again.
If the bugged
halt is preceded by a
ei and followed by a
rst, the former “wins”.