6502.org

To be perfectly clear, my experience is exclusively with the Nintendo Entertainment System, and for all I know, these instructions might behave differently in a 2A03 for some reason. I don't currently think that's the case, which brings me to this post.

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. This sets A to $FF, but the ANC instruction should result in A being set to $5A, due to the bitwise AND with the operand. When running this in visual6502, the A register remains unchanged, and the carry flag is set.

Opcode $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:
Assuming 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.

I checked the first one, and indeed I see A is not modified from the FF value.

URL: http://visual6502.org/JSSim/expert.html ... a&steps=20

Visual6502 is a switch-level simulator, with modelling of charge storage, but no accurate model for charge-sharing. There will be situations where it doesn't do what (most) NMOS chips might do, but it's been extensively tested for the documented opcodes.

There are forks of visual6502 and some of them might have a tweaked model which is more accurate for these cases.

I note this remix of visual6502 offers more tools - an assembler, for one. I don't know if the simulation mechanics have been tweaked.
https://github.com/floooh/v6502r?tab=re ... ile#v6502r