Though I'm still convinced it's just me, myself and/or I (it always has, so it's got to be this time, too!), I thought I'd seek professional help before I involuntarily zero out, you know, the zero page.
Consider this bit of SNES-65816, native-mode code (Accu is 8 bits, X/Y are 16 bits):
Code: Select all
CardCheckError: lda CARDSTATUS ; get card status, check for general error sta errorCode and #%00000001 cmp #%00000001 beq CardError rts CardError: ClearLine 21 ClearLine 22 ClearLine 23 SetCursorPos 21, 1 ldy #errorCode PrintString "Error $%x - CF card status"
Those who know me might recognize this as a code snippet from my unofficial SNES PowerPak firmware. What you might not know is that I'm currently working on v3.01, which will feature a lot of improvements over v3.00.
So, here's the deal: As CardCheckError gets called very often (i. e., more than every 512 bytes of data transferred to or from the CF card), I thought it would be a good idea to optimize this subroutine a tiny little bit.
Just like so:
Code: Select all
CardCheckError: lda CARDSTATUS ; get card status, check for general error sta errorCode and #%00000001 bne CardError rts
We-heh-heh-hell. Yes it is.
The routine being shortened like this, the PowerPak would give me a card error message right upon power-up.
Strange? Yes, but wait 'til you hear this ...
It would even laugh me in the face by telling me
Can you believe it? Bit 0 of errorCode is clear/zero, as it apparently has been all the time, and still, the branch was taken regardless whenever I went from AND #1/CMP #1/BEQ SOMEWHERE to AND #1/BNE SOMEWHERE.Error $50 - CF card status
WTF's happening here??
I spent 3+ hours googling for a 65X(X)X AND quirk, but didn't come up with anything.
Please help me, as I'm beginning to lose my sanity over this (but luckily not my mane, which is hairdcoded).