Hi all,

I'm trying to write a cycle correct 6502 emulator. I compare my results to visual6502 so I can verify my work. However, I found that visual6502 simulates ANC in a different way than it's described in a lot of previous documents. This instruction is called stable, so I'd expect that visual6502 simulates it as described. However, it seems that A doesn't get updated at all (this seems to be incorrect, as ANC should behave almost like AND).

You can check it out with this 2-instruction (LDA #0xff ; ANC #0x00) program: http://www.visual6502.org/JSSim/expert.html?graphics=f&steps=16&a=0000&d=a9ff0b00&loglevel=5. Here, A remains 0xff, but it should change to 0x00, as far as I understand. And visual6502 doesn't update the flags either. Is this a known thing?

If I change ANC (0x0b) to AND (0x29), A is updated correctly.

Welcome! Although I might be one of the best-placed here to have an answer, I don't have one, sorry. You, or someone, would need to trace carefully through the datapath and the datapath control lines to see how the value written back to A is generated. I see the ALU performing an ADD for these ANC opcodes, which implies that the ALU output can't be involved.

BTW I suggest using operands like F0 and 3C, so you get to see all combinations of bit patterns.

Thank you for the response! Now I checked two other undocumented instructions (ALR - 0x4b, ARR - 0x6b), neither of these does the AND, but the shift is executed correctly.

I'm not familiar with the datapath/control lines (I've just learned how to read the circuit so I can reverse engineer the exact interrupt logic, as NMI during BRK can be messy: BRK sets two flags (node 1291 and 1431) during its run which determines whether NMIG is set or not), so I think I'll just accept the fact that visual6502 doesn't simulate these instructions correctly for now.

For myself, even if they are noted as 'stable', I wouldn't be surprised for them actually to depend on detailed electrical behaviour which the simple two-state model in visual6502 doesn't model.

It is a little odd though that this page implies perhaps more:
http://visual6502.org/wiki/index.php?ti ... 56_Opcodes

Hmm interesting, might it be a bug in visual6502? The c version is affected too.
According to the No More Secrets document the ANC opcodes are completely stable and will AND the accumulator with the operand.

No surprise that visual6502 and perfect6502 act the same: that's by design.

The thing to do, to track this down, is to see what the datapath is doing. I think I'm right in saying that the behaviour of the internal busses is the most likely place for divergence: an undriven bus, or two undrived busses then connected together, isn't a digital situation.

If you really feel diligent, find a way to modify the very simple net evaluation function which leaves everything else unchanged but changes this behaviour.

It looks like within a connected group of nets, a short to ground (Vss) overrides a short to Vcc, which both override a soft pull-up or pull-down - pull-down always overrides pull-up if there are no shorts to a rail. Any of those four being present results in a well-defined, actively driven logic level. But if none of the four are present in the group, the existing "values" of the individual nets are examined, and there a single "high" level overrides any number of "low" levels.

So we could have non-physical behaviour in the following case:

1: One net, disconnected from the others, gets pulled high; several others get pulled low.

2: In a subsequent step, the nets from the previous step are not pulled either way, but are connected to each other.

The sim will take the single high net and propagate its high value to all the low nets, no matter how numerous or large they are. But in reality, the small charge on the single net would dissipate across the parasitic capacitance of the many nets while not raising the voltage enough to leave the "low" state.

To fix this, I think we need to count the pull-ups and pull-downs against each other, and the passive highs and passive lows against each other, and take the majority rather than accepting a strict precedence.

I had to do something similar to get perfect6502 to correctly simulate the Z80:
https://github.com/hoglet67/perfect6502 ... 9ec43ac8dc

The same change is used in Visual6502 when simulating the Z80:
https://github.com/trebonian/visual6502 ... 039ca51cba

As a aside, the "secret" URL for VisualZ80 on the public site is:
http://www.visual6502.org/JSSim/expert-z80.html

It's not really "secret", it's just not been well advertised, and obviously can't be mentioned on this forum

I would be interested to see whether the 6502 even runs with this change, and whether it helps in this specific case.

Dave

I'd say that's definitely worth testing on the 6502. Also something of a relief that someone's already figured out how to implement it…

The commit doesn't apply to the latest code. Anyway I've tried your version and it still fail. The cbmbasic program works as expected though.

I've noticed the in the first half of cycle 4 both alua and alub are zeroed out but then in the second half they go back to ff, could this be a hint?

Edit: attached the test file