Let's begin with opcode $0B, an unofficial instruction some call ANC Immediate. This instruction performs a bitwise AND between the accumulator and the operand, while setting the carry flag if the result is negative. To test this in Visual6502, I set up RAM with the following bytes: A9 FF 0B 5A.
Code: Select all
LDA #$FF
ANC #$5AOpcode $2B appears to be the same as opcode $0B. The result in Visual6502 is the same as opcode $0B, where the value of A is not affected.
Opcode $4B is sometimes called ASR. It runs is bitwise AND between A and the operand, then shifts A to the right. Like before, the bitwise AND between A and the operand appears to be missing in visual6502. Using the same set up as before, you would expect the resulting value of A to be $2D, but instead the result in Visual6502 is $7F.
Opcode $6B is sometimes called ARR. It runs a bitwise AND between A and the operand, then rotates A to the right. Like the others, the bitwise AND isn't happening in Visual6502.
Opcode $BB is a more interesting story. Sometimes called LAS or LAE, this instruction performs a bitwise AND between the stack pointer and the value read from a Y indexed Absolute Address. The resulting Stack Pointer value is then transferred to both the A and the X registers. I'm testing this in Visual6502 using the bytes A0 00 A2 FF 9A A2 5A BB 00 00, running:
Code: Select all
LDY #0
LDX #$00
TXS
LDX #$5A
LAE $0000, YAssuming the LDY #0 was located at address $0000, this should result in the stack pointer being changed to $A0, and this value being transferred to A and X. Visual6502 does appear to correctly do this, but then one half-cycle later the Stack Pointer, A register, and X register are all changed to new values. In this test, A is set to $B1 (I have no idea where this value is coming from), and both the X register and the Stack pointer are set to $FF. Edit: The resulting X register and Stack Pointer appear to be the initial value of the stack pointer before running the instruction.
Is this an issue with Visual6502, or are there 6502 CPUs known to behave this way?
I've seen some CPUs perform unexpected things with some unofficial instructions, ($83, $87, $8F, $97), but I've only seen the opcodes mentioned in this post behaving in one consistent way.
Anyway, I was going to make some baseless claim that the bitwise AND between A and the operand during the first four opcodes mentioned might have something to do with analog behavior, as it is mentioned in the Visual6502 FAQ that there is no analog behavior being simulated. I've never seen any "magic numbers" with those instructions, and I'll admit that I'm not really an expert at this level of the hardware, so I'm not sure if there's the possibility of analog behavior or not.
I'm mostly making this post to ask if this is known, or if it is in-fact not an issue at all in case some real CPUs match this behavior.
