Closed SonoSooS closed 1 year ago
Can be previewed at https://sonosoos.github.io/gb-opcodes/optables/.
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 specifyingA
explicitly.Thus for example
ADD A,B
has the alternative mnemonicADD B
Well since the page has to render static, it could only be done by either
ClassicOctalHexShortaluMcycle
(capitalized first letters for easier readability, in the URL it's all lowercase)),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 mnemonicADD B
, andCP A, $F
has the alternative mnemonicCP $F
.
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 sideA
omitted.Thus for example
ADD A, A
has the alternative mnemonicADD A
, andCP A, $F
has the alternative mnemonicCP $F
.
That sounds good to me. Should I add it to the footnotes before merge?
Please do!
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.
Yeah, I also think that a cleanup (making it context-friendly as well in the process) should be a separate issue to deal with.
Actually, the use of <kbd>
is correct as per the HTML standard, it's just that everyone misuses it. Fun fun fun!
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.