Make ALU ops consistent (explicit A)

[SonoSooS]

As per #11 and discussions about this, it has been concluded that even though adding the explicit A parameter reduces the readability of the opcodes in the $80-$BF and o3x6 opcode range, it's for the better to have the parameters consistent, and we'll deal separately with the readability issues (there are other readability issues to solve anyway).

Fixes #11.

[ISSOtm]

Can be previewed at https://sonosoos.github.io/gb-opcodes/optables/.

[nitro2k01]

Consistency is desirable, and this is better than the previous mess. However, while we're at it, how feasible would it be to special-case these instructions with something like an "ALU" attribute and leave it to the renderer whether to include A,?

At the very least, the bottom section which lists alternative mnemonics should explain that ALU opcodes can have a different mnemonic. For example:

ALU instructions (ADD,ADC,CP,AND,OR,SB,SUB,XOR) are often written without specifying A explicitly.

Thus for example ADD A,B has the alternative mnemonic ADD B

[SonoSooS]

Well since the page has to render static, it could only be done by either

• creating a brand new page (which would lead to hilariously long URLs if combined with other planned additions, like ClassicOctalHexShortaluMcycle (capitalized first letters for easier readability, in the URL it's all lowercase)),
• or it could be Javascript (which is not ideal, as it requires maintaining two renderers at once, let alone compatibility issues),
• or CSS (can't be made persistent config via cookies or something).

Although this should be a separate issue from this, as other requested representation ideas also depend on solving this issue about configurability.

I think that solving the implicit A problem is a separate issue, however I can include your text in the PR if you want. I had a different idea for what text to include at the bottom of the page, but yours speaks more in less, so I want to go with it. Although I would include a 2nd example with an immediate value instead of an r8 value, so it's even more descriptive. Something like:

Thus for example ADD A, B has the alternative mnemonic ADD B, and CP A, $F has the alternative mnemonic CP $F.

[ISSOtm]

I'd rather this be merged as-is, considering the configuration issues are documented in #27.

As for the text at the bottom of the page, what about this:

ALU instructions (ADD,ADC,CP,AND,OR,SB,SUB,XOR) can be written with the left-hand side A omitted.

Thus for example ADD A, A has the alternative mnemonic ADD A, and CP A, $F has the alternative mnemonic CP $F.

[SonoSooS]

That sounds good to me. Should I add it to the footnotes before merge?

[ISSOtm]

Please do!

[SonoSooS]

It looks really good here in the comments, but when deployed to the page it looks like garbage :/

Sadly I'm no designer, so I have no idea how to make it look more pleasant to look at, and less like alphabet soup.

[SonoSooS]

Yeah, I also think that a cleanup (making it context-friendly as well in the process) should be a separate issue to deal with.

[ISSOtm]

Actually, the use of <kbd> is correct as per the HTML standard, it's just that everyone misuses it. Fun fun fun!