6502bench/SourceGen/SGTestData/Expected/2011-hinting_cc65.S

         .setcpu "6502"
;         .segment "SEG000"
         .org    $1000
         .byte   $03
         .byte   $02

L1002:   bit     L1002
         .byte   $2c
         lda     #$11
         nop
         .byte   $2c
L100A:   ldx     #$ff
         nop
         jsr     L100A
         nop
         .byte   $2c
L1012:   ldx     #$ff
         nop
         jsr     L1012
         jsr     $2456
L101B:   .dword  $22a211a9
         jsr     L101B
         jsr     L1028
         jsr     $2456
L1028:   .dword  $44a233a9
         jsr     L103A
         jsr     L103D
         nop
         lda     $2456
         jsr     L1045
         rts

L103A:   jsr     $2456
L103D:   lda     #$55
         ldx     #$66
         rts

         .byte   $81
         .byte   $82
         .byte   $83

L1045:   lda     #$99
         rts
Initial file commit 2018-09-28 17:05:11 +00:00			`.setcpu "6502"`
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`
			`.byte $03`
			`.byte $02`

			`L1002: bit L1002`
			`.byte $2c`
			`lda #$11`
			`nop`
			`.byte $2c`
			`L100A: ldx #$ff`
			`nop`
			`jsr L100A`
			`nop`
			`.byte $2c`
			`L1012: ldx #$ff`
			`nop`
			`jsr L1012`
			`jsr $2456`
			`L101B: .dword $22a211a9`
			`jsr L101B`
			`jsr L1028`
			`jsr $2456`
			`L1028: .dword $44a233a9`
			`jsr L103A`
Fix handling of data formatting that overlaps with code If you play games with code hints you can create a data operand that overlaps with code. This causes problems (see issue #45). We now check for that situation and ignore overlapping data descriptors. Added a regression test to 2011-hinting. 2019-09-14 18:40:32 +00:00			`jsr L103D`
Initial file commit 2018-09-28 17:05:11 +00:00			`nop`
			`lda $2456`
Fix handling of data formatting that overlaps with code If you play games with code hints you can create a data operand that overlaps with code. This causes problems (see issue #45). We now check for that situation and ignore overlapping data descriptors. Added a regression test to 2011-hinting. 2019-09-14 18:40:32 +00:00			`jsr L1045`
Initial file commit 2018-09-28 17:05:11 +00:00			`rts`

Fix handling of data formatting that overlaps with code If you play games with code hints you can create a data operand that overlaps with code. This causes problems (see issue #45). We now check for that situation and ignore overlapping data descriptors. Added a regression test to 2011-hinting. 2019-09-14 18:40:32 +00:00			`L103A: jsr $2456`
			`L103D: lda #$55`
Initial file commit 2018-09-28 17:05:11 +00:00			`ldx #$66`
			`rts`

Fix handling of data formatting that overlaps with code If you play games with code hints you can create a data operand that overlaps with code. This causes problems (see issue #45). We now check for that situation and ignore overlapping data descriptors. Added a regression test to 2011-hinting. 2019-09-14 18:40:32 +00:00			`.byte $81`
			`.byte $82`
			`.byte $83`

			`L1045: lda #$99`
			`rts`