2019-10-06 02:51:34 +00:00
|
|
|
.cpu "65816"
|
2019-10-07 21:21:26 +00:00
|
|
|
.enc sg_hiascii
|
|
|
|
.cdef $20,$7e,$a0
|
2019-10-06 02:51:34 +00:00
|
|
|
.enc sg_ascii
|
|
|
|
.cdef $20,$7e,$20
|
|
|
|
PrintInlineL1String = $011000
|
|
|
|
PrintInlineL2String = $012000
|
|
|
|
PrintInlineDciString = $013000
|
|
|
|
|
|
|
|
* = $1000
|
|
|
|
.as
|
|
|
|
.xs
|
|
|
|
clc
|
|
|
|
xce
|
|
|
|
sep #$30
|
|
|
|
jsr PrintInline8String
|
|
|
|
.text "01234567"
|
|
|
|
jsr PrintInlineRev8String
|
|
|
|
.text "76543210"
|
|
|
|
jsr PrintInlineNullString
|
|
|
|
.null "null-term string"
|
|
|
|
jsl PrintInlineL1String
|
|
|
|
.ptext "string with length/1"
|
|
|
|
jsl PrintInlineL2String
|
|
|
|
.text $14,$00,"string with length/2"
|
|
|
|
jsl PrintInlineDciString
|
|
|
|
.shift "DCI string"
|
2019-10-19 23:23:42 +00:00
|
|
|
jsr L10B5
|
2019-10-06 02:51:34 +00:00
|
|
|
jsr L110F
|
|
|
|
jsr L1108
|
Optionally treat BRKs as two-byte instructions
Early data sheets listed BRK as one byte, but RTI after a BRK skips
the following byte, effectively making BRK a 2-byte instruction.
Sometimes, such as when diassembling Apple /// SOS code, it's handy
to treat it that way explicitly.
This change makes two-byte BRKs optional, controlled by a checkbox
in the project settings. In the system definitions it defaults to
true for Apple ///, false for all others.
ACME doesn't allow BRK to have an arg, and cc65 only allows it for
65816 code (?), so it's emitted as a hex blob for those assemblers.
Anyone wishing to target those assemblers should stick to 1-byte mode.
Extension scripts have to switch between formatting one byte of
inline data and formatting an instruction with a one-byte operand.
A helper function has been added to the plugin Util class.
To get some regression test coverage, 2022-extension-scripts has
been configured to use two-byte BRK.
Also, added/corrected some SOS constants.
See also issue #44.
2019-10-09 21:55:56 +00:00
|
|
|
brk #$01
|
2019-10-07 21:21:26 +00:00
|
|
|
.word data01
|
Optionally treat BRKs as two-byte instructions
Early data sheets listed BRK as one byte, but RTI after a BRK skips
the following byte, effectively making BRK a 2-byte instruction.
Sometimes, such as when diassembling Apple /// SOS code, it's handy
to treat it that way explicitly.
This change makes two-byte BRKs optional, controlled by a checkbox
in the project settings. In the system definitions it defaults to
true for Apple ///, false for all others.
ACME doesn't allow BRK to have an arg, and cc65 only allows it for
65816 code (?), so it's emitted as a hex blob for those assemblers.
Anyone wishing to target those assemblers should stick to 1-byte mode.
Extension scripts have to switch between formatting one byte of
inline data and formatting an instruction with a one-byte operand.
A helper function has been added to the plugin Util class.
To get some regression test coverage, 2022-extension-scripts has
been configured to use two-byte BRK.
Also, added/corrected some SOS constants.
See also issue #44.
2019-10-09 21:55:56 +00:00
|
|
|
brk #$02
|
2019-10-07 21:21:26 +00:00
|
|
|
.word data02
|
2019-10-19 23:23:42 +00:00
|
|
|
nop
|
|
|
|
jsr L1085
|
|
|
|
.byte $24
|
|
|
|
L1085 .byte $a9
|
|
|
|
.byte $00
|
|
|
|
sta $ff
|
|
|
|
.byte $ea
|
2019-10-06 02:51:34 +00:00
|
|
|
rts
|
|
|
|
|
|
|
|
PrintInline8String rts
|
|
|
|
|
|
|
|
PrintInlineRev8String rts
|
|
|
|
|
|
|
|
PrintInlineNullString rts
|
|
|
|
|
2019-10-07 21:21:26 +00:00
|
|
|
data01 .word 4386
|
|
|
|
.byte $33,$44
|
|
|
|
.dword $88776655
|
|
|
|
.byte $99,$88,$77,$66
|
|
|
|
.byte 'f'
|
|
|
|
.byte 'F' | $80
|
|
|
|
.byte $40
|
|
|
|
.byte $c1
|
|
|
|
.byte $42
|
|
|
|
.byte $c3
|
|
|
|
.byte $44
|
|
|
|
.byte $c5
|
|
|
|
.byte $46
|
|
|
|
.byte $c7
|
|
|
|
.long PrintInlineL2String
|
|
|
|
.word data02
|
|
|
|
.byte $80
|
2019-11-17 01:15:03 +00:00
|
|
|
data02 .word _data03
|
2019-10-07 21:21:26 +00:00
|
|
|
.byte $80
|
|
|
|
.enc sg_hiascii
|
2019-11-17 01:15:03 +00:00
|
|
|
_data03 .text "AllEight"
|
2019-10-07 21:21:26 +00:00
|
|
|
|
2019-10-19 23:23:42 +00:00
|
|
|
L10B5 jsr PrintInlineNullString ;split across address change
|
|
|
|
per $802d
|
2019-10-06 02:51:34 +00:00
|
|
|
rtl
|
|
|
|
|
|
|
|
.byte $65
|
|
|
|
.byte $6e
|
|
|
|
.byte $20
|
|
|
|
.byte $01
|
|
|
|
.logical $1100
|
2019-10-07 21:21:26 +00:00
|
|
|
.enc sg_ascii
|
2019-10-06 02:51:34 +00:00
|
|
|
.text "string"
|
|
|
|
.byte $00
|
|
|
|
.byte $60
|
|
|
|
|
|
|
|
L1108 jsl PrintInlineL2String
|
|
|
|
asl a
|
Optionally treat BRKs as two-byte instructions
Early data sheets listed BRK as one byte, but RTI after a BRK skips
the following byte, effectively making BRK a 2-byte instruction.
Sometimes, such as when diassembling Apple /// SOS code, it's handy
to treat it that way explicitly.
This change makes two-byte BRKs optional, controlled by a checkbox
in the project settings. In the system definitions it defaults to
true for Apple ///, false for all others.
ACME doesn't allow BRK to have an arg, and cc65 only allows it for
65816 code (?), so it's emitted as a hex blob for those assemblers.
Anyone wishing to target those assemblers should stick to 1-byte mode.
Extension scripts have to switch between formatting one byte of
inline data and formatting an instruction with a one-byte operand.
A helper function has been added to the plugin Util class.
To get some regression test coverage, 2022-extension-scripts has
been configured to use two-byte BRK.
Also, added/corrected some SOS constants.
See also issue #44.
2019-10-09 21:55:56 +00:00
|
|
|
brk #$60
|
2019-10-06 02:51:34 +00:00
|
|
|
|
|
|
|
L110F jsr PrintInlineNullString
|
|
|
|
adc $6e
|
|
|
|
.byte $64
|
|
|
|
.here
|