6502/6502bench
1
0
Fork 0
mirror of https://github.com/fadden/6502bench.git synced 2024-12-02 13:51:36 +00:00
Code Issues Projects Releases Wiki Activity
3a02132694
6502bench/SourceGen/SGTestData/Expected/20120-char-encoding-a_cc65.S

282 lines
8.8 KiB
ArmAsm
Raw Normal View History

Rework 201XX-char-encoding-X tests We have a single character-encoding test that is cloned 3x so we can exercise the different values for the project's default character set. It was a 65816 test because it tested 16-bit immediate char operands, but that's a very small part of it. The 65816-specific portion is now 20122-char-encoding. The rest is now 201{2,3,4}0-char-encoding-X.
2020-10-19 22:01:02 +00:00
;Projected edited to format non-char operands as chars.
.setcpu "6502"
Add 2016-char-encoding-a and variations All tests use the same data file and nearly the same project file. The only difference is the default text encoding property setting. For "-a" it's ASCII, for "-p" it's PETSCII, for "-s" it's C64 screen code. Right now this only affects the code generated for 64tass. The test itself is a collection of strings and characters in the supported character encodings. How these are handled varies significantly between assemblers.
2019-08-16 21:53:50 +00:00
; .segment "SEG000"
.org $1000
lda #'A'
lda #'A' | $80
lda #$c1
lda #$41
ldx #'a'
ldx #'a' | $80
ldx #$41
ldx #$01
Rework 201XX-char-encoding-X tests We have a single character-encoding test that is cloned 3x so we can exercise the different values for the project's default character set. It was a 65816 test because it tested 16-bit immediate char operands, but that's a very small part of it. The 65816-specific portion is now 20122-char-encoding. The rest is now 201{2,3,4}0-char-encoding-X.
2020-10-19 22:01:02 +00:00
lda #$7f ;inappropriate format should be ignored
Add 2016-char-encoding-a and variations All tests use the same data file and nearly the same project file. The only difference is the default text encoding property setting. For "-a" it's ASCII, for "-p" it's PETSCII, for "-s" it's C64 screen code. Right now this only affects the code generated for 64tass. The test itself is a collection of strings and characters in the supported character encodings. How these are handled varies significantly between assemblers.
2019-08-16 21:53:50 +00:00
lda #$7f
lda #$7f
lda #$7f
lda #$0d
Rework 201XX-char-encoding-X tests We have a single character-encoding test that is cloned 3x so we can exercise the different values for the project's default character set. It was a 65816 test because it tested 16-bit immediate char operands, but that's a very small part of it. The 65816-specific portion is now 20122-char-encoding. The rest is now 201{2,3,4}0-char-encoding-X.
2020-10-19 22:01:02 +00:00
jmp L144B
Add 2016-char-encoding-a and variations All tests use the same data file and nearly the same project file. The only difference is the default text encoding property setting. For "-a" it's ASCII, for "-p" it's PETSCII, for "-s" it's C64 screen code. Right now this only affects the code generated for 64tass. The test itself is a collection of strings and characters in the supported character encodings. How these are handled varies significantly between assemblers.
2019-08-16 21:53:50 +00:00
.byte 'C'
.byte 'C' | $80
.byte $c3
.byte $43
.word 'd'
.word 'd' | $80
.word $44
.word $04
.dbyt 'E'
.dbyt 'E' | $80
.dbyt $c5
.dbyt $45
.byte $80
.byte "low ASCII str"
.macro HiAscii Arg
.repeat .strlen(Arg), I
.byte .strat(Arg, I) | $80
.endrep
.endmacro
HiAscii "high ASCII str"
.byte $80
.byte $d0,$c5,$d4,$d3,$c3,$c9,$c9,$20,$53,$54,$52
.byte $80
.byte $53,$03,$12,$05,$05,$0e,$20,$43,$0f,$04,$05,$20,$13,$14,$12
.byte $82
.byte $07,"Low ASCII CRLF",$0d,$0a
.byte $82
.byte $87,$c8,$e9,$e7,$e8,$a0,$c1,$d3,$c3,$c9,$c9,$a0,$c3,$d2,$cc,$c6
.byte $8d,$8a
.byte $82
.byte $93,$d0,$c5,$d4,$d3,$c3,$c9,$c9,$20,$57,$49,$54,$48,$20,$96,$43
.byte $4f,$4e,$54,$52,$4f,$4c,$05,$20,$43,$4f,$44,$45,$53,$0d
.byte $83
.byte " !",$22,"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVW"
.byte "XYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~"
.byte $83
.byte $a0,$a1,$a2,$a3,$a4,$a5,$a6,$a7,$a8,$a9,$aa,$ab,$ac,$ad,$ae,$af
.byte $b0,$b1,$b2,$b3,$b4,$b5,$b6,$b7,$b8,$b9,$ba,$bb,$bc,$bd,$be,$bf
.byte $c0,$c1,$c2,$c3,$c4,$c5,$c6,$c7,$c8,$c9,$ca,$cb,$cc,$cd,$ce,$cf
.byte $d0,$d1,$d2,$d3,$d4,$d5,$d6,$d7,$d8,$d9,$da,$db,$dc,$dd,$de,$df
.byte $e0,$e1,$e2,$e3,$e4,$e5,$e6,$e7,$e8,$e9,$ea,$eb,$ec,$ed,$ee,$ef
.byte $f0,$f1,$f2,$f3,$f4,$f5,$f6,$f7,$f8,$f9,$fa,$fb,$fc,$fd,$fe
.byte $83
.byte $20,$21,$22,$23,$24,$25,$26,$27,$28,$29,$2a,$2b,$2c,$2d,$2e,$2f
.byte $30,$31,$32,$33,$34,$35,$36,$37,$38,$39,$3a,$3b,$3c,$3d,$3e,$3f
.byte $40,$c1,$c2,$c3,$c4,$c5,$c6,$c7,$c8,$c9,$ca,$cb,$cc,$cd,$ce,$cf
.byte $d0,$d1,$d2,$d3,$d4,$d5,$d6,$d7,$d8,$d9,$da,$5b
.byte $5c
.byte $5d
.byte $5e
.byte $5f
.byte $60
.byte $41,$42,$43,$44,$45,$46,$47,$48,$49,$4a,$4b,$4c,$4d,$4e,$4f,$50
.byte $51,$52,$53,$54,$55,$56,$57,$58,$59,$5a
Rework 201XX-char-encoding-X tests We have a single character-encoding test that is cloned 3x so we can exercise the different values for the project's default character set. It was a 65816 test because it tested 16-bit immediate char operands, but that's a very small part of it. The 65816-specific portion is now 20122-char-encoding. The rest is now 201{2,3,4}0-char-encoding-X.
2020-10-19 22:01:02 +00:00
.byte $7b
.byte $7c
.byte $7d
.byte $7e
Add 2016-char-encoding-a and variations All tests use the same data file and nearly the same project file. The only difference is the default text encoding property setting. For "-a" it's ASCII, for "-p" it's PETSCII, for "-s" it's C64 screen code. Right now this only affects the code generated for 64tass. The test itself is a collection of strings and characters in the supported character encodings. How these are handled varies significantly between assemblers.
2019-08-16 21:53:50 +00:00
.byte $83
.byte $20,$21,$22,$23,$24,$25,$26,$27,$28,$29,$2a,$2b,$2c,$2d,$2e,$2f
.byte $30,$31,$32,$33,$34,$35,$36,$37,$38,$39,$3a,$3b,$3c,$3d,$3e,$3f
.byte $00,$41,$42,$43,$44,$45,$46,$47,$48,$49,$4a,$4b,$4c,$4d,$4e,$4f
.byte $50,$51,$52,$53,$54,$55,$56,$57,$58,$59,$5a,$1b
.byte $1c
.byte $1d
.byte $1e
.byte $1f
.byte $40
.byte $01,$02,$03,$04,$05,$06,$07,$08,$09,$0a,$0b,$0c,$0d,$0e,$0f,$10
.byte $11,$12,$13,$14,$15,$16,$17,$18,$19,$1a
Rework 201XX-char-encoding-X tests We have a single character-encoding test that is cloned 3x so we can exercise the different values for the project's default character set. It was a 65816 test because it tested 16-bit immediate char operands, but that's a very small part of it. The 65816-specific portion is now 20122-char-encoding. The rest is now 201{2,3,4}0-char-encoding-X.
2020-10-19 22:01:02 +00:00
.byte $7b
.byte $7c
.byte $7d
.byte $7e
Add 2016-char-encoding-a and variations All tests use the same data file and nearly the same project file. The only difference is the default text encoding property setting. For "-a" it's ASCII, for "-p" it's PETSCII, for "-s" it's C64 screen code. Right now this only affects the code generated for 64tass. The test itself is a collection of strings and characters in the supported character encodings. How these are handled varies significantly between assemblers.
2019-08-16 21:53:50 +00:00
.byte $84
.byte $c9,$c9,$c3,$d3,$d4,$c5,$d0,$20,$45,$53,$52,$45,$56,$45,$52
.byte $84
.byte $4e,$55,$4c,$4c,$20,$54,$45,$52,$4d,$20,$d0,$c5,$d4,$d3,$c3,$c9
.byte $c9,$00
.byte $84
.byte $d4,$48,$49,$53,$20,$4e,$55,$4c,$4c,$2d,$54,$45,$52,$4d,$49,$4e
.byte $41,$54,$45,$44,$20,$53,$54,$52,$49,$4e,$47,$20,$49,$53,$20,$54
.byte $4f,$4f,$20,$4c,$4f,$4e,$47,$20,$54,$4f,$20,$46,$49,$54,$20,$4f
.byte $4e,$20,$41,$20,$53,$49,$4e,$47,$4c,$45,$20,$4c,$49,$4e,$45,$2c
.byte $20,$41,$4e,$44,$20,$57,$49,$4c,$4c,$20,$42,$45,$20,$53,$50,$4c
.byte $49,$54,$2e,$00
.byte $84
.byte $13,$d0,$c5,$d4,$d3,$c3,$c9,$c9,$20,$57,$49,$54,$48,$20,$4c,$45
.byte $4e,$47,$54,$48
.byte $84
.byte $14,$00,$d0,$c5,$d4,$d3,$c3,$c9,$c9,$20,$57,$49,$54,$48,$20,$4c
.byte $45,$4e,$47,$54,$48,$32
.byte $84
PETSCII does DCI I didn't think it made sense, but I found something that used it, so apparently it's a thing. This updates the operand editor to let you choose PETSCII+DCI, and updates the assemblers to handle it correctly (really just 64tass, since the others either don't have a DCI directive or don't deal with PETSCII at all). Changed the char-encoding sample from "bad dcI" to "pet dcI", and updated the documentation.
2019-08-21 00:55:12 +00:00
.byte $50,$45,$54,$20,$44,$43,$c9
Add 2016-char-encoding-a and variations All tests use the same data file and nearly the same project file. The only difference is the default text encoding property setting. For "-a" it's ASCII, for "-p" it's PETSCII, for "-s" it's C64 screen code. Right now this only affects the code generated for 64tass. The test itself is a collection of strings and characters in the supported character encodings. How these are handled varies significantly between assemblers.
2019-08-16 21:53:50 +00:00
.byte $84
.byte $05,$04,$0f,$43,$20,$0e,$05,$05,$12,$03,$53,$20,$05,$13,$12,$05
.byte $16,$05,$12
.byte $84
Rework 201XX-char-encoding-X tests We have a single character-encoding test that is cloned 3x so we can exercise the different values for the project's default character set. It was a 65816 test because it tested 16-bit immediate char operands, but that's a very small part of it. The 65816-specific portion is now 20122-char-encoding. The rest is now 201{2,3,4}0-char-encoding-X.
2020-10-19 22:01:02 +00:00
.byte $0e,$15,$0c,$0c,$2d,$14,$05,$12,$0d,$20,$13,$03,$12,$05,$05,$0e
.byte $20,$03,$0f,$04,$05,$3f,$00
.byte $84
Add 2016-char-encoding-a and variations All tests use the same data file and nearly the same project file. The only difference is the default text encoding property setting. For "-a" it's ASCII, for "-p" it's PETSCII, for "-s" it's C64 screen code. Right now this only affects the code generated for 64tass. The test itself is a collection of strings and characters in the supported character encodings. How these are handled varies significantly between assemblers.
2019-08-16 21:53:50 +00:00
.byte $17,$53,$03,$12,$05,$05,$0e,$20,$43,$0f,$04,$05,$20,$17,$09,$14
.byte $08,$20,$0c,$05,$0e,$07,$14,$08
.byte $84
.byte $18,$00,$53,$03,$12,$05,$05,$0e,$20,$43,$0f,$04,$05,$20,$17,$09
.byte $14,$08,$20,$0c,$05,$0e,$07,$14,$08,$32
.byte $84
.byte $53,$03,$12,$05,$05,$0e,$20,$43,$0f,$04,$05,$20,$44,$43,$c9
.byte $84
.byte $85
.byte $00
.byte $01
.byte $02
.byte $03
.byte $04
.byte $05
.byte $06
.byte $07
.byte $08
.byte $09
.byte $0a
.byte $0b
.byte $0c
.byte $0d
.byte $0e
.byte $0f
.byte $10
.byte $11
.byte $12
.byte $13
.byte $14
.byte $15
.byte $16
.byte $17
.byte $18
.byte $19
.byte $1a
.byte $1b
.byte $1c
.byte $1d
.byte $1e
.byte $1f
.byte " !",$22,"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVW"
.byte "XYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~"
.byte $7f
.byte $80
.byte $81
.byte $82
.byte $83
.byte $84
.byte $85
.byte $86
.byte $87
.byte $88
.byte $89
.byte $8a
.byte $8b
.byte $8c
.byte $8d
.byte $8e
.byte $8f
.byte $90
.byte $91
.byte $92
.byte $93
.byte $94
.byte $95
.byte $96
.byte $97
.byte $98
.byte $99
.byte $9a
.byte $9b
.byte $9c
.byte $9d
.byte $9e
.byte $9f
Rework 201XX-char-encoding-X tests We have a single character-encoding test that is cloned 3x so we can exercise the different values for the project's default character set. It was a 65816 test because it tested 16-bit immediate char operands, but that's a very small part of it. The 65816-specific portion is now 20122-char-encoding. The rest is now 201{2,3,4}0-char-encoding-X.
2020-10-19 22:01:02 +00:00
.byte $a0,$a1,$a2,$a3,$a4,$a5,$a6,$a7,$a8,$a9,$aa,$ab,$ac,$ad,$ae,$af
.byte $b0,$b1,$b2,$b3,$b4,$b5,$b6,$b7,$b8,$b9,$ba,$bb,$bc,$bd,$be,$bf
.byte $c0,$c1,$c2,$c3,$c4,$c5,$c6,$c7,$c8,$c9,$ca,$cb,$cc,$cd,$ce,$cf
.byte $d0,$d1,$d2,$d3,$d4,$d5,$d6,$d7,$d8,$d9,$da,$db,$dc,$dd,$de,$df
.byte $e0,$e1,$e2,$e3,$e4,$e5,$e6,$e7,$e8,$e9,$ea,$eb,$ec,$ed,$ee,$ef
.byte $f0,$f1,$f2,$f3,$f4,$f5,$f6,$f7,$f8,$f9,$fa,$fb,$fc,$fd,$fe
Add 2016-char-encoding-a and variations All tests use the same data file and nearly the same project file. The only difference is the default text encoding property setting. For "-a" it's ASCII, for "-p" it's PETSCII, for "-s" it's C64 screen code. Right now this only affects the code generated for 64tass. The test itself is a collection of strings and characters in the supported character encodings. How these are handled varies significantly between assemblers.
2019-08-16 21:53:50 +00:00
.byte $ff
Rework 201XX-char-encoding-X tests We have a single character-encoding test that is cloned 3x so we can exercise the different values for the project's default character set. It was a 65816 test because it tested 16-bit immediate char operands, but that's a very small part of it. The 65816-specific portion is now 20122-char-encoding. The rest is now 201{2,3,4}0-char-encoding-X.
2020-10-19 22:01:02 +00:00
Tweak backslash escaping The initial implementation was testing the byte value rather than the converted value, so backslashes were getting through in high ASCII strings. PETSCII and C64 screen codes don't really have a backslash so it's not really an issue there. The new implementation handles high ASCII correctly. The various 201n0-char-encoding-x regression tests have been updated to verify this.
2021-08-01 03:22:21 +00:00
L144B: nop
jmp @L14DA
.byte "ASCII escapes \: \\ \r \n \",$22," \' \t"
.byte $80
.byte $d0,$c5,$d4,$d3,$c3,$c9,$c9,$20,$45,$53,$43,$41,$50,$45,$53,$20
.byte $5c
.byte $3a,$20
.byte $5c
.byte $5c
.byte $20
.byte $5c
.byte $52,$20
.byte $5c
.byte $4e,$20
.byte $5c
.byte $22,$20
.byte $5c
.byte $27,$20
.byte $5c
.byte $54
.byte $80
.byte $53,$43,$52,$20,$05,$13,$03,$01,$10,$05,$13,$20
.byte $1c
.byte $3a,$20
.byte $1c
.byte $1c
.byte $20
.byte $1c
.byte $12,$20
.byte $1c
.byte $0e,$20
.byte $1c
.byte $22
.byte $20
.byte $1c
.byte $27
.byte $20
.byte $1c
.byte $14
.byte $80
HiAscii "HIGH escapes \: \\ \r \n \0 \' \t"
.byte $80
@L14DA: nop
Allow single-character DCI strings The DCI string format uses character values where the high bit of the last byte differs from the rest of the string. Usually all the high bits are clear except on the last byte, but SourceGen generally allows either polarity. This gets a little uncertain with single-character strings, because SourceGen can't auto-detect DCI very effectively. A series of bytes with the high bit set could be a single high-ASCII string or a series of single-byte DCI strings. The motivation for allowing them is C64 PETSCII. While ASCII allows "high ASCII" as an escape hatch, PETSCII doesn't have that option, so there's no way to mark the data as a character or a string. We still want to do a bit of screening, but if the user specifies a non-ASCII character set and the selected bytes have their high bits set, we want to just treat the whole set as 1-byte DCI. Some minor adjustments were needed for a couple of validity checks that expected longer strings. This adds some short DCI strings in different character sets to the char-encoding regression tests. (for issue #102)
2021-08-08 22:38:39 +00:00
jmp @L1511
.byte $86
.byte "Hell",$ef
.byte "H",$c9
.byte $d8
.byte $a1
.byte $86
.byte $c8,$e5,$ec,$ec,$6f
.byte $c8,$49
.byte 'X'
.byte '!'
.byte $86
.byte $48,$45,$4c,$4c,$cf
.byte $48,$c9
.byte $d8
.byte $a1
.byte $86
.byte $c8,$c5,$cc,$cc,$4f
.byte $c8,$49
.byte $58
.byte $21
.byte $86
.byte $48,$05,$0c,$0c,$8f
.byte $48,$c9
.byte $d8
.byte $a1
.byte $86
@L1511: nop
Tweak backslash escaping The initial implementation was testing the byte value rather than the converted value, so backslashes were getting through in high ASCII strings. PETSCII and C64 screen codes don't really have a backslash so it's not really an issue there. The new implementation handles high ASCII correctly. The various 201n0-char-encoding-x regression tests have been updated to verify this.
2021-08-01 03:22:21 +00:00
rts
Rework 201XX-char-encoding-X tests We have a single character-encoding test that is cloned 3x so we can exercise the different values for the project's default character set. It was a 65816 test because it tested 16-bit immediate char operands, but that's a very small part of it. The 65816-specific portion is now 20122-char-encoding. The rest is now 201{2,3,4}0-char-encoding-X.
2020-10-19 22:01:02 +00:00
Reference in New Issue Copy Permalink