[anyfoo]

No, almost all invocations of system calls are implicitly telling the kernel that you now wish to sleep, and want to be waken up once the system call completes. It's abstracted away from you by mostly looking like a regular function call, but it's there. It's more explicitly apparent if you e.g. wait on a semaphore, but the principle is the same.

Just type "ps ax" into your shell, most processes will be in state "S", sleeping because of a system call.

My point is, you kind of have to go out of your way to spin CPU without actually having any work in front of you.

[tom_]

It's the opposite on 8-bit stuff, because there's nothing else running, and CPUs on such systems typically never stop working anyway - so if your game has nothing to do, it still has to do something.

So it's normal to just enter a little loop in your code, often one that waits for a flag that's set by an interrupt routine that runs in response to vertical blank or a timer or something. So your loop is literally just waiting for time to pass. Load flag, is flag zero, repeat loop if zero, that sort of thing, over and over again.

But with the gameboy's halt functionality, you can add a halt in there, I guess: halt, load flag, is flag zero, repeat loop if zero. Then the CPU can go dormant until the next interrupt, rather than spending its time running that loop. (It might wake up needlessly, if some other interrupt occurs, but it'll still be no more expensive than the loop.)

[anyfoo]

So the only difference really is whether you have a HALT at the end of your main loop or not, I guess. (Well, and that you sometimes had to poll, because there isn't an interrupt for everything you're waiting for.)