1. Forum
  2. Usenet
  3. COMP.EMULATORS.APPLE2

  • 6502 ROL Bug In AppleWin?

    From John Public@21:1/5 to All on Mon Apr 11 11:54:14 2022
    Not sure but I think I found a bug.
    Look at this table then at the 6502 and the results

    0 00 0000
    1 01 0001
    2 02 0010
    3 03 0011
    4 04 0100
    5 05 0101
    6 06 0110
    7 07 0111
    8 08 1000
    9 09 1001
    10 0A 1010
    11 0B 1011
    12 0C 1100
    13 0D 1101
    14 0E 1110
    15 0F 1111


    19 ROL become 32
    32 XOR 58 = 6A
    6A ROL become D4
    D4 XOR 79 = AD
    AD ROL SHOULD BE 5B but it's 5A

    Is this a bug in the CPU itself or AppleWin?

    If I take AD
    10101101

    rotate left

    01011011 = 5B

    The debugger shows 5A in the accumulator with the
    carry flag being set?









    32 EOR 58

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From I am Rob@21:1/5 to John Public on Mon Apr 11 13:28:16 2022
    On Monday, April 11, 2022 at 12:54:15 PM UTC-6, John Public wrote:
    Not sure but I think I found a bug.
    Look at this table then at the 6502 and the results

    0 00 0000
    1 01 0001
    2 02 0010
    3 03 0011
    4 04 0100
    5 05 0101
    6 06 0110
    7 07 0111
    8 08 1000
    9 09 1001
    10 0A 1010
    11 0B 1011
    12 0C 1100
    13 0D 1101
    14 0E 1110
    15 0F 1111


    19 ROL become 32
    32 XOR 58 = 6A
    6A ROL become D4
    D4 XOR 79 = AD
    AD ROL SHOULD BE 5B but it's 5A

    Is this a bug in the CPU itself or AppleWin?

    If I take AD
    10101101

    rotate left

    01011011 = 5B

    The debugger shows 5A in the accumulator with the
    carry flag being set?

    I think your logic might be incorrect.
    When you rotate 6A to become D4, the hi-bit of 6A is clear, which rotates into the carry.
    The XOR with 79 does not affect the carry so the carry is still clear.
    Lastly when AD is rotated, the hi-bit is set and goes into the carry and and the carry (which was preiously clear) goes into the lo-bit, so the result is 5A, which is correct and the carry should now be set.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From I am Rob@21:1/5 to John Public on Mon Apr 11 13:29:25 2022
    On Monday, April 11, 2022 at 12:54:15 PM UTC-6, John Public wrote:
    Not sure but I think I found a bug.
    Look at this table then at the 6502 and the results

    0 00 0000
    1 01 0001
    2 02 0010
    3 03 0011
    4 04 0100
    5 05 0101
    6 06 0110
    7 07 0111
    8 08 1000
    9 09 1001
    10 0A 1010
    11 0B 1011
    12 0C 1100
    13 0D 1101
    14 0E 1110
    15 0F 1111


    19 ROL become 32
    32 XOR 58 = 6A
    6A ROL become D4
    D4 XOR 79 = AD
    AD ROL SHOULD BE 5B but it's 5A

    Is this a bug in the CPU itself or AppleWin?

    If I take AD
    10101101

    rotate left

    01011011 = 5B

    The debugger shows 5A in the accumulator with the
    carry flag being set?

    think your logic might be incorrect.
    When you rotate 6A to become D4, the hi-bit of 6A is clear, which rotates into the carry.
    The XOR with 79 does not affect the carry so the carry is still clear.
    Lastly when AD is rotated, the hi-bit is set and goes into the carry and and the carry (which was previously clear) goes into the lo-bit, so the result is 5A, which is correct and the carry should now be set.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Public@21:1/5 to All on Mon Apr 11 15:39:20 2022
    Thank you Rob.
    I saw the difference as Windows Calculator was showing 5B.
    Your explanation makes perfect sense.
    I think my logic was OK based on the information I had at hand.
    I'd like to find a VB or C# function to show this process.
    Learned something ne. Thank you again.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)