Test 6502 OpCode 0X95 (it seems that the incrementation of the X register was forgotten)

Quote from NeoDarwin on December 27, 2024, 10:52 pmI created this opcode list "a2 00 a9 42 95 00 e8 18 69 01 95 00 ea ea..." to be executed by the 6502; however, the "0x95 0x00" opcode didn't work correctly. In fact, it seems that the incrementation of the X register was forgotten.
After cloning the SimulIDE repository and installing the program, I debugged the code and this problem seems to be located into the "mcs65core.cpp" file at line 294 : case 5: m_aMode = aZEDX; break;
After the update that seems to fix the issue: case 5: m_aMode = aZEDX; m_aFlags = iX; break
With this update, the code at line 399 takes the X register into account.However, I made this update very quickly (1 hour) just to help ... let's me know how to fix it.
I created this opcode list "a2 00 a9 42 95 00 e8 18 69 01 95 00 ea ea..." to be executed by the 6502; however, the "0x95 0x00" opcode didn't work correctly. In fact, it seems that the incrementation of the X register was forgotten.
After cloning the SimulIDE repository and installing the program, I debugged the code and this problem seems to be located into the "mcs65core.cpp" file at line 294 : case 5: m_aMode = aZEDX; break;
After the update that seems to fix the issue: case 5: m_aMode = aZEDX; m_aFlags = iX; break
With this update, the code at line 399 takes the X register into account.
However, I made this update very quickly (1 hour) just to help ... let's me know how to fix it.

Quote from arcachofo on December 28, 2024, 12:30 pmHi. Thanks for reporting.
Your solution can work, but I think there is a better solution:
As I understand it, this addressing mode always use Register X, there is no case when it uses Register Y.
So we don't need to use m_aFlags = iX and just add the content of RX to the operand.
Then we can remove: else if( m_aFlags & iY ) m_u8Tmp0 += m_rY; and leave it like this: (at line 399)case 3:{ // Discard reading m_opAddr = m_u8Tmp0 + m_rX; readMem( m_opAddr ); }break;
What do you think?
Hi. Thanks for reporting.
Your solution can work, but I think there is a better solution:
As I understand it, this addressing mode always use Register X, there is no case when it uses Register Y.
So we don't need to use m_aFlags = iX and just add the content of RX to the operand.
Then we can remove: else if( m_aFlags & iY ) m_u8Tmp0 += m_rY; and leave it like this: (at line 399)
case 3:{ // Discard reading
m_opAddr = m_u8Tmp0 + m_rX;
readMem( m_opAddr );
}break;
What do you think?

Quote from NeoDarwin on December 28, 2024, 5:28 pmHi, thank you for your response! 😊
I'll work on it right away.
I took some time to understand how the system works, and I found a solution to fix it and to test it.
When using the zero-page addressing mode, the X or Y register is not applied as an offset by default.For example: In the case of the instruction `STY $00,X`, the value of the Y register is not stored with the offset in the default zero page. (same case for Y)
After to read the code about the
mcs65core.cpp
program. I identifie that code uses theabc
pattern for instruction decoding. The issue seems to originate from the handling of type5
. To address this, I added support for selecting either the X accumulator or Y accumulator based on the group or opcode being processed. This ensures proper functionality for instructions likeSTX
andLDX
in zero-page addressing mode with offsets. (the sun means that I tested it after)
This table is from the website : https://www.masswerk.at/6502/6502_instruction_set.html
I investegated to fix a type 5 with this code :
After that, I created this script to test this update :
opcode :
A2 00 ; LDX #$00 A0 00 ; LDY #$00 A9 00 ; LDA #$00 ; STY zpg,X A2 10 ; LDX #$10 A0 42 ; LDY #$42 94 20 ; STY $20,X A5 30 ; LDA $30 C9 42 ; CMP #$42 D0 1C ; BNE ERROR (relative jump of 28 bytes) ; LDA zpg,X A2 05 ; LDX #$05 A9 37 ; LDA #$37 95 50 ; STA $50,X A5 55 ; LDA $55 C9 37 ; CMP #$37 D0 14 ; BNE ERROR (relative jump of 20 bytes) ; CMP zpg,X A2 03 ; LDX #$03 A9 80 ; LDA #$80 95 70 ; STA $70,X C5 73 ; CMP $73 D0 0C ; BNE ERROR (relative jump of 12 bytes) ; DEC zpg,X A2 02 ; LDX #$02 A9 10 ; LDA #$10 95 90 ; STA $90,X D6 90 ; DEC $90,X A5 92 ; LDA $92 C9 0F ; CMP #$0F D0 04 ; BNE ERROR (relative jump of 4 bytes) ; SBC zpg,X 38 ; SEC A2 01 ; LDX #$01 A9 20 ; LDA #$20 95 A0 ; STA $A0,X F5 A0 ; SBC $A0,X C9 00 ; CMP #$00 D0 1C ; BNE ERROR (relative jump of 28 bytes) 4C 38 08 ; JMP SUCCESS ; ERROR 00 ; BRK ; SUCCESS A9 00 ; LDA #$00 8D FF 00 ; STA $FF 00 ; BRK
To buld the binary file : I created this script :
# Python file to build the binary file to import to simulIDE # opCode to test hex_data = [ 0xA2, 0x00, 0xA0, 0x00, 0xA9, 0x00, 0xA2, 0x10, 0xA0, 0x42, 0x94, 0x20, 0xA5, 0x30, 0xC9, 0x42, 0xD0, 0x1C, 0xA2, 0x05, 0xA9, 0x37, 0x95, 0x50, 0xA5, 0x55, 0xC9, 0x37, 0xD0, 0x14, 0xA2, 0x03, 0xA9, 0x80, 0x95, 0x70, 0xC5, 0x73, 0xD0, 0x0C, 0xA2, 0x02, 0xA9, 0x10, 0x95, 0x90, 0xD6, 0x90, 0xA5, 0x92, 0xC9, 0x0F, 0xD0, 0x04, 0x38, 0xA2, 0x01, 0xA9, 0x20, 0x95, 0xA0, 0xF5, 0xA0, 0xC9, 0x00, 0xD0, 0x1C, 0x4C, 0x38, 0x08, 0x00, 0xA9, 0x00, 0x8D, 0xFF, 0x00, 0x00 ] # outcome output_file = "program.bin" # binary file with open(output_file, "wb") as bin_file: bin_file.write(bytearray(hex_data)) print(f"Fichier binaire '{output_file}' créé avec succès.")
However, I’m also going to investigate further based on your answer.
Hi, thank you for your response! 😊
I'll work on it right away.
I took some time to understand how the system works, and I found a solution to fix it and to test it.
When using the zero-page addressing mode, the X or Y register is not applied as an offset by default.For example: In the case of the instruction `STY $00,X`, the value of the Y register is not stored with the offset in the default zero page. (same case for Y)
After to read the code about the mcs65core.cpp
program. I identifie that code uses the abc
pattern for instruction decoding. The issue seems to originate from the handling of type 5
. To address this, I added support for selecting either the X accumulator or Y accumulator based on the group or opcode being processed. This ensures proper functionality for instructions like STX
and LDX
in zero-page addressing mode with offsets. (the sun means that I tested it after)
This table is from the website : https://www.masswerk.at/6502/6502_instruction_set.html
I investegated to fix a type 5 with this code :
After that, I created this script to test this update :
opcode :
A2 00 ; LDX #$00
A0 00 ; LDY #$00
A9 00 ; LDA #$00
; STY zpg,X
A2 10 ; LDX #$10
A0 42 ; LDY #$42
94 20 ; STY $20,X
A5 30 ; LDA $30
C9 42 ; CMP #$42
D0 1C ; BNE ERROR (relative jump of 28 bytes)
; LDA zpg,X
A2 05 ; LDX #$05
A9 37 ; LDA #$37
95 50 ; STA $50,X
A5 55 ; LDA $55
C9 37 ; CMP #$37
D0 14 ; BNE ERROR (relative jump of 20 bytes)
; CMP zpg,X
A2 03 ; LDX #$03
A9 80 ; LDA #$80
95 70 ; STA $70,X
C5 73 ; CMP $73
D0 0C ; BNE ERROR (relative jump of 12 bytes)
; DEC zpg,X
A2 02 ; LDX #$02
A9 10 ; LDA #$10
95 90 ; STA $90,X
D6 90 ; DEC $90,X
A5 92 ; LDA $92
C9 0F ; CMP #$0F
D0 04 ; BNE ERROR (relative jump of 4 bytes)
; SBC zpg,X
38 ; SEC
A2 01 ; LDX #$01
A9 20 ; LDA #$20
95 A0 ; STA $A0,X
F5 A0 ; SBC $A0,X
C9 00 ; CMP #$00
D0 1C ; BNE ERROR (relative jump of 28 bytes)
4C 38 08 ; JMP SUCCESS
; ERROR
00 ; BRK
; SUCCESS
A9 00 ; LDA #$00
8D FF 00 ; STA $FF
00 ; BRK
To buld the binary file : I created this script :
# Python file to build the binary file to import to simulIDE
# opCode to test
hex_data = [
0xA2, 0x00, 0xA0, 0x00, 0xA9, 0x00, 0xA2, 0x10, 0xA0, 0x42, 0x94, 0x20, 0xA5, 0x30, 0xC9, 0x42,
0xD0, 0x1C, 0xA2, 0x05, 0xA9, 0x37, 0x95, 0x50, 0xA5, 0x55, 0xC9, 0x37, 0xD0, 0x14, 0xA2, 0x03,
0xA9, 0x80, 0x95, 0x70, 0xC5, 0x73, 0xD0, 0x0C, 0xA2, 0x02, 0xA9, 0x10, 0x95, 0x90, 0xD6, 0x90,
0xA5, 0x92, 0xC9, 0x0F, 0xD0, 0x04, 0x38, 0xA2, 0x01, 0xA9, 0x20, 0x95, 0xA0, 0xF5, 0xA0, 0xC9,
0x00, 0xD0, 0x1C, 0x4C, 0x38, 0x08, 0x00, 0xA9, 0x00, 0x8D, 0xFF, 0x00, 0x00
]
# outcome
output_file = "program.bin"
# binary file
with open(output_file, "wb") as bin_file:
bin_file.write(bytearray(hex_data))
print(f"Fichier binaire '{output_file}' créé avec succès.")
However, I’m also going to investigate further based on your answer.

Quote from arcachofo on December 28, 2024, 7:13 pmYou are absolutely right.
It doesn't make any sense to use Reg X for STX or LDX.And ignore my previous answer. It was based in a wrong asumption (group 5 only uses zegopage,X).
Based in this website:
Btw: can you share the link to the webpage where you got that a-b-c table.
You are absolutely right.
It doesn't make any sense to use Reg X for STX or LDX.
And ignore my previous answer. It was based in a wrong asumption (group 5 only uses zegopage,X).
Based in this website:
Btw: can you share the link to the webpage where you got that a-b-c table.