1. Forum
  2. USENET
  3. comp.emulators.apple2

  • 6502 ROL Bug In AppleWin?

    From John Public@deeplyshrouded@gmail.com to comp.emulators.apple2 on Mon Apr 11 11:54:14 2022
    From Newsgroup: comp.emulators.apple2

    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
    --- Synchronet 3.21b-Linux NewsLink 1.2
  • From I am Rob@gids.rs@sasktel.net to comp.emulators.apple2 on Mon Apr 11 13:28:16 2022
    From Newsgroup: comp.emulators.apple2

    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.
    --- Synchronet 3.21b-Linux NewsLink 1.2
  • From I am Rob@gids.rs@sasktel.net to comp.emulators.apple2 on Mon Apr 11 13:29:25 2022
    From Newsgroup: comp.emulators.apple2

    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.
    --- Synchronet 3.21b-Linux NewsLink 1.2
  • From John Public@deeplyshrouded@gmail.com to comp.emulators.apple2 on Mon Apr 11 15:39:20 2022
    From Newsgroup: comp.emulators.apple2

    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.

    --- Synchronet 3.21b-Linux NewsLink 1.2