6502/6502bench
1
0
Fork 0
mirror of https://github.com/fadden/6502bench.git synced 2024-12-11 13:50:13 +00:00
Code Issues Projects Releases Wiki Activity
1ad9caa783
6502bench/SourceGen/SGTestData/Expected/2008-address-changes_cc65.S

125 lines
2.5 KiB
ArmAsm
Raw Normal View History

Initial file commit
2018-09-28 17:05:11 +00:00
.setcpu "65816"
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG000"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $1000
.a8
.i8
clc
xce
sep #$ff
jsr L1100
jsr L1107
jmp L2000
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG001"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $1100
L1100: bit L1100
L1103: lda #$11
ldx #$11
L1107: ldy #$11
per L1103
bra L1103
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG002"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $1100
L1100_0: bit L1100_0
lda #$22
L1105: ldx #$22
ldy #$22
per L1105
jmp L1105
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG003"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $1100
L1100_1: bit L1100_1
lda #$33
ldx #$33
L1107_0: ldy #$33
per L1107_0
bra L1107_0
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG004"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $2000
L2000: bit L2000
beq $2018
bra L2020
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG005"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $2020
L2020: bit L2020
beq offend+1
brl L2080
offend: nop
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG006"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $2080
L2080: bit L2080
lda offend
jsr offend
lda offend+1
jsr offend+1
lda $207f
jsr $207f
lda L2080
jsr L2080
lda $00
beq L2100
.byte $ad
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG007"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $2100
L2100: nop
nop
jmp L3000
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG008"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $2800
.byte $00
.byte $28
.res 14,$00
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG009"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $2820
.res 18,$00
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG010"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $3000
L3000: bit L3000
lda #$44
ldx #$44
ldy #$44
brl fwd
ulabel: .byte $00
.byte $01
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG011"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $3100
L3100: .byte $02
fwd: bit fwd
lda ulabel
lda ulabel+1
Add custom flag updaters for ROL/ROR There are some useful interactions between C/N and maybe Z. Added a quick test to 1003-flags-and-branches. Also, updated the 2008-address-changes tests. Change b37d3dba extended the nearby-target range of out-of-file symbols by one, so one line that didn't get an operand label now does.
2018-10-09 19:27:47 +00:00
lda ulabel+2
Initial file commit
2018-09-28 17:05:11 +00:00
lda $300f
lda L3100
beq L3182
.byte $ea
.byte $ea
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG012"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $3180
.byte $00
.byte $01
L3182: bit L3182
lda label1
lda label1+1
lda label1+112
bra L3200
label1: .byte $ea
.byte $ea
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39)
2018-11-18 22:36:03 +00:00
; .segment "SEG013"
Initial file commit
2018-09-28 17:05:11 +00:00
.org $3200
L3200: bit L3200
.byte $00
.byte $01
Reference in New Issue Copy Permalink