Unnamed no-ops $22 and $5C are handled incorrectly in c65

[SamCoVT]

@patricksurry I've added you as "Patrick Surry" as an author on several files you've heavily modified. If that's not correct or you'd like to be mentioned differently, let me know.

I merged your compromise loop speedup and c65 PRs.

Just FYI, c65 does fail two of Klaus Dormann's tests for the 65C02 for opcodes $22 and $5C, but these are unnamed no-ops (they fail because $22 is supposed to be a 2-byte no-op (so the byte after it should be ignored) and $5C should be a 3-byte no-op (the next two bytes should be ignored), but c65 does not ignore the following bytes. Because these are unnamed no-ops and will never be found in Tali, I'm comfortable using c65 for the testing.

I also modified to Makefile to build c65 when you run make ctests and then use your talitest_c65.py script to run the tests. I've left the other testing methods alone, but I will probably get rid of the ptests target and shell scripts as that was my "faster" test setup and c65 blows it out of the water for speed. I would like to get a feel for how c65 behaves during a Tali crash and verify that detection happens properly before fully switching over.

[patricksurry]

That all sounds good to me

[patricksurry]

is it worth leaving an open issue for those two opcodes? I imagine it wouldn't be hard to fix that if we do switch over.

[SamCoVT]

I'll leave this issue open as a reminder - I've changed the title of the issue. I agree that it should be pretty simple to change and there are only two to deal with. It also has no urgency whatsoever, as Tali will not contain and will not generate those opcodes.

[patricksurry]

do you have example code that replicates the failure? looks easy enough to fix but don't have an immediate way of testing

[SamCoVT]

Sure - here is some forth code modeled off of how the Klaus Dorman test suite found these two issues. It puts 3 into A and runs the opcode followed by two dea (dec.a in Tali's assembler) instructions. The opcode is a no-op, but it is supposed to use one or two additional bytes as if it had an 8-bit or 16-bit argument, so one or both of the dec.as should be skipped if it's working properly.

assembler-wordlist >order

\ Test opcode $22 (bytes used including opcode - should be 2)
: testopcode22
  [
  3 lda.# \ Start with three bytes used
  $22 c,  \ Compile the opcode under test
  dec.a dec.a \ compile two dea instructions to reduce count if run
  push-a  \ put result on stack
  ]
  . ." bytes used including opcode (should be 2)" cr \ print results
;

\ Test opcode $5C (bytes used including opcode - should be 3)
: testopcode5C
  [
  3 lda.# \ Start with three bytes used
  $5C c,  \ Compile the opcode under test
  dec.a dec.a \ compile two dea instructions to reduce count if run
  push-a  \ put result on stack
  ]
  . ." bytes used including opcode (should be 3)" cr \ print results
;

You can see how many bytes are supposed to be used (total, including the opcode) in the table at: http://www.6502.org/tutorials/65c02opcodes.html#9

This also shows how many cycles they should take and some have odd side effects (like $5C reads from somewhere in the 64K address space - but using no known addressing mode, so the actual location is difficult to determine)