6502bench/SourceGen/SGTestData/Expected/10022-embedded-instructions_cc65.S

         .setcpu "65816"
;         .segment "SEG000"
         .org    $1000
         .a8
         .i8
         jsr     L1006
         jmp     L1020

L1006:   sep     #$30
         lda     $00
         beq     @L100F
         lda     #$00
         brk

@L100F:  sta     $012345
         lda     $00
         beq     @L101A
         lda     #$00
         .byte   $85
@L101A:  .byte   $8f
         eor     $23
         .byte   $01
         nop
         rts

L1020:   .byte   $af
Initial file commit 2018-09-28 10:05:11 -07: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 14:36:03 -08:00			`; .segment "SEG000"`
Initial file commit 2018-09-28 10:05:11 -07:00			`.org $1000`
			`.a8`
			`.i8`
Refactor tests 1002x and 1003x Tests 10022-embedded-instructions and 10032-flags-and-branches were a mix of 6502 and 65816 code. The 6502 code has been separated into its own file, so that the tests can be run on 8-bit-only assemblers. 2020-10-18 20:30:42 -07:00			`jsr L1006`
			`jmp L1020`
Initial file commit 2018-09-28 10:05:11 -07:00
Refactor tests 1002x and 1003x Tests 10022-embedded-instructions and 10032-flags-and-branches were a mix of 6502 and 65816 code. The 6502 code has been separated into its own file, so that the tests can be run on 8-bit-only assemblers. 2020-10-18 20:30:42 -07:00			`L1006: sep #$30`
Initial file commit 2018-09-28 10:05:11 -07:00			`lda $00`
Refactor tests 1002x and 1003x Tests 10022-embedded-instructions and 10032-flags-and-branches were a mix of 6502 and 65816 code. The 6502 code has been separated into its own file, so that the tests can be run on 8-bit-only assemblers. 2020-10-18 20:30:42 -07:00			`beq @L100F`
Initial file commit 2018-09-28 10:05:11 -07:00			`lda #$00`
Treat BRK as a 1-byte instruction The 65816 definition makes it a two-byte instruction, like COP. On the 6502 it acted like a two-byte instruction, but in practice very few assemblers treat it that way. Very few humans, for that matter. So it's now treated as a single byte instruction, with the following byte encoded as a data value. 2019-08-02 17:21:50 -07:00			`brk`
Initial file commit 2018-09-28 10:05:11 -07:00
Refactor tests 1002x and 1003x Tests 10022-embedded-instructions and 10032-flags-and-branches were a mix of 6502 and 65816 code. The 6502 code has been separated into its own file, so that the tests can be run on 8-bit-only assemblers. 2020-10-18 20:30:42 -07:00			`@L100F: sta $012345`
			`lda $00`
			`beq @L101A`
			`lda #$00`
			`.byte $85`
			`@L101A: .byte $8f`
			`eor $23`
			`.byte $01`
Initial file commit 2018-09-28 10:05:11 -07:00			`nop`
			`rts`

Refactor tests 1002x and 1003x Tests 10022-embedded-instructions and 10032-flags-and-branches were a mix of 6502 and 65816 code. The 6502 code has been separated into its own file, so that the tests can be run on 8-bit-only assemblers. 2020-10-18 20:30:42 -07:00			`L1020: .byte $af`