Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BRK instruction in MEGA65 Memory/Machine Inspection interface disassembles to 2 bytes #179

Closed
pchnl opened this issue Oct 26, 2024 · 2 comments
Labels
new New report, not classified yet

Comments

@pchnl
Copy link

pchnl commented Oct 26, 2024

  • Platform: MEGA65, r6
  • Matrix Monitor 0.96.20240224.00.3c10488
  • Related tickets: "brk should be two bytes?"

When assembling the BRK instruction, it is assembled to 1 byte ($00) and I believe that to be correct (despite the stack manipulation done by the interrupt handling).

When attempting to step through some code with the MEGA65 Memory/Machine Inspection interface (Mega + Tab) I got confused because it shows the original code (00 EE 20 D0 00) which is:
BRK
INC $D020
BRK

as:
BRK $EE <== looks wrong to me
JSR $00D0

By the way, the MEGA65 monitor (MONITOR) displays:
00 BRK
EE 20 D0 INC $D020
00 BRK

Which I think is correct.

@dansanderson
Copy link
Collaborator

Relocating this to mega65-core. (Matrix Mode is not powered by the ROM.) MEGA65/mega65-core#843

@SvOlli
Copy link

SvOlli commented Oct 27, 2024

Two bytes for BRK is correct. Here is little hack to show this. It runs on my Sorbus Computer with a 65CE02 (but it's the same with all other 6502 variants).

 35:1000 r a9    :9:$1000: A9 FF       LDA  #$FF
 34:1001 r ff    :0:
 33:1002 r 8d    :9:$1002: 8D FE FF    STA  $FFFE
 32:1003 r fe    :0:
 31:1004 r ff    :0:
 30:fffe w ff    :0:
 29:1005 r a9    :9:$1005: A9 0F       LDA  #$0F
 28:1006 r 0f    :0:
 27:1007 r 8d    :9:$1007: 8D FF FF    STA  $FFFF
 26:1008 r ff    :0:
 25:1009 r ff    :0:
 24:ffff w 0f    :0:
 23:100a r a2    :9:$100A: A2 00       LDX  #$00
 22:100b r 00    :0:
 21:100c r 8e    :9:$100C: 8E 00 DF    STX  $DF00
 20:100d r 00    :0:
 19:100e r df    :0:
 18:df00 w 00    :0:
 17:100f r 00    :9:$100F: 00 EA       BRK  #$EA
 16:1010 r ea    :0:
 15:01fd w 10    :0:
 14:01fc w 11    :0:
 13:01fb w 33    :0:
 12:fffe r ff    :0:
 11:ffff r 0f    :0:
 10:0fff r 40    :9:$0FFF: 40          RTI
  9:1000 r a9    :0:
  8:01fb r 33    :0:
  7:01fc r 11    :0:
  6:01fd r 10    :0:
  5:1011 r ea    :9:$1011: EA          NOP
  4:1012 r 8d    :9:$1012: 8D 01 DF    STA  $DF01
  3:1013 r 01    :0:
  2:1014 r df    :0:
  1:df01 w 0f    :0:

See how at line 17 the BRK is triggered at $100f, but after the RTI the CPU is returning to $1011 at line 5?

This happens with all 6502 variants. So BRK $EE in your example is correct.

It's just that almost every monitor written for the 6502 adjusts the stack afterwards. This is since the 6530-004 (TIM), the companion chip sold with the very first 6502s.

(My kernel uses the BRK for triggering kernel functions, thus eliminating a bigger jump table.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new New report, not classified yet
Projects
None yet
Development

No branches or pull requests

3 participants