Change STOP byte count to 1

[SonoSooS]

It doesn't make sense to have a 2-byte instruction which takes 1 M-cycle, as that's impossible to actually achieve on the CPU in any way (yes, that even includes ADD HL, r16, as it does ALU operation on both M-cycles, lower half first, then upper half in the second cycle).

There are two ways to solve this issue:

• make it 1B 1M, as that's what it actually is
• keep it as 2B, but make it 32769M (execution of STOP takes a single M-cycle, and wakeup from STOP mode fetches the next instruction on the 32768th cycle)

And yes, STOP is actually a single byte opcode, which can be observed when STOP fails to stop due to a button being held. The short explaination of why STOP consumes two bytes can be summarized in these points:

• PC is always one byte ahead of the currently executed instruction
• if STOP enters stop mode, it fetches the next opcode, incrementing PC (PC points to STOP +2)
• the fetched opcode is discarded, and replaced with NOP
• on wakeup, the NOP fetches the instruction at STOP +2, and executes it in the next cycle More details can be found here.

The reason HALT does not consume two bytes is because PC is not incremented when HALT fetches the next opcode, but otherwise works similar to STOP. More details here.

[ISSOtm]

I think we'd want to not give a cycle count for it, like we (probably?) already do for halt. And add an asterisk (or tooltip or whatever) listing the more complete explanation, or alternatively a link to it (in Pan Docs?).

[SonoSooS]

Yeah, HALT and STOP are quite complex, so I'd agree with the idea of removing both cycle and byte count from HALT and STOP, especially considering that HALT is listed as 1B, even though we also pad it with NOP to avoid HALT bug, while STOP is listed as 2B, even though it's an 1B instruction just like HALT is.

We'd just need to make both a terse and a detailed explaination we could link to. The terse part is really important, as I think it's a bad idea to collapse too much information onto someone who just wants to know if HALT or STOP are 1B or 2B, and also why we can't just say 1M as cycle count.

[ISSOtm]

Maybe the full explanation can be added to Pan Docs instead?

[SonoSooS]

It is possible, although I have encountered two issues:

• Pan Docs is a bit more simplified, and I'm not sure if it's possible to simplify the STOP nonsense even further (there is already a flowchart, but it doesn't explain the inner workings of this issue)
• I don't see which page could fit this info in a way where it won't be too obtrusive and confusion-generating (perhaps just plop it below the STOP flowchart?)

[ISSOtm]

Pan Docs can get away with a simplified explanation (isn't the flowchart sufficient?), and link to a separate document for more details, I think.

[nitro2k01]

The answer to all of the above is: "it depends" or "it comes down to semantics". Just like with some previous discussions I've engaged with regarding the documentation (like the APU frequency/wavelength/whatever discussion) I've argued for sometimes leading the text with what's useful for the reader, and then nitty gritty technical details can be explained further down.

How many bytes is stop? Yes, it's technically 1 byte, but externally it behaves like 2 bytes. You can prove it is technically 1 byte by specifically doing everything Nintendo warned you not to do (button activated and held, and interrupt pending) but this is more of a curiosity.

How many cycles does stop use? The simple answer is of course that it varies, but this depends on semantics. You could for example argue that stop itself takes 1 M whereas, the side effects of stop may take a varying number of cycles, for example 32768 M.

My recommendation would be to specify stop as 2 bytes, since that's how it appears externally in all reasonable use cases, and specify the cycles as something like 1+x M or 1+? M. The latter would apply to halt as well btw.

[SonoSooS]

Yeah, that's fair about unnecessary complexity. I guess there could be a separate page with more detail for emulator devs, as opposed to programmers who only need to know to encode STOP as $10 $00 if they really need to use it, and it takes either 1 or 2 bytes, and 1+variable cycles.

There could be a middle-ish ground: specify STOP as 1/2 bytes, and cycle count as 1+x, that sounds terse enough if you only need a quick lookup, but also encourages people to dig further if they really need to know more about this fandango of specifying two possibilities instead of just a fix one.

HALT should also receive the 1+x M-cycle treatment as well, although I'm not sure about the byte count, as it could be 1 or 0, but I guess that's way too pedantic, and it should stay as 1 with an asterisk to encode HALT as $76 $00 to avoid the HALT bug at all cost.

[ISSOtm]

The halt bug is well documented elsewhere, I don't think that last asterisk is necessary. Similarly, I'd only document STOP as "1/2"-byte, and have the asterisk say "the byte following STOP is usually ignored, see this document for details".

Agreed about the special cycle notation.