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/20140-char-encoding-s_64tass.S

392 lines
8.9 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.
.cpu "6502"
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "sg_hiascii"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.cdef $20,$7e,$a0
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "sg_ascii"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.cdef $20,$7e,$20
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
* = $1000
lda #'A'
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
lda #'A' | $80
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "none"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
lda #'A'
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "screen"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
lda #'A'
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "sg_ascii"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
ldx #'a'
ldx #'a' | $80
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "none"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
ldx #'a'
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "screen"
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
ldx #'a'
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "sg_ascii"
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
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "none"
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
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "screen"
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
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "sg_ascii"
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 #$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
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.byte 'C'
.byte 'C' | $80
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "none"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.byte 'C'
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "screen"
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'
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "sg_ascii"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.word 'd'
.word 'd' | $80
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "none"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.word 'd'
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "screen"
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
.word 'd'
.byte $00,$45
.byte $00,$c5
.byte $00,$c5
.byte $00,$45
.byte $80
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "sg_ascii"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.text "low ASCII str"
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "sg_hiascii"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.text "high ASCII str"
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 $80
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "none"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.text "PETSCII str"
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 $80
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "screen"
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
.text "Screen Code str"
.byte $82
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "sg_ascii"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.text $07,"Low ASCII CRLF",$0d,$0a
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 $82
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "sg_hiascii"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.text $87,"High ASCII CRLF",$8d,$8a
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 $82
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "none"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.text $93,"PETSCII with ",$96,"control",$05," codes",$0d
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
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "sg_ascii"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.text " !",$22,"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVW"
.text "XYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~"
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
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "sg_hiascii"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.text " !",$a2,"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVW"
.text "XYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~"
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
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "none"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.text " !",$22,"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVW"
.text "XYZ["
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 $5c
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.byte ']'
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 $5e
.byte $5f
.byte $60
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.text "abcdefghijklmnopqrstuvwxyz"
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 $7b
.byte $7c
.byte $7d
.byte $7e
.byte $83
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "screen"
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
.text " !",$22,"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVW"
.text "XYZ["
.byte $1c
.byte ']'
.byte $1e
.byte $1f
.byte $40
.text "abcdefghijklmnopqrstuvwxyz"
.byte $7b
.byte $7c
.byte $7d
.byte $7e
.byte $84
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "none"
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.text "IICSTEP esrever"
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
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.null "null term PETSCII"
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
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.text "This null-terminated string is too long to fit on a single lin"
.text "e, and will be split.",$00
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
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.ptext "PETSCII with length"
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
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.text $14,$00,"PETSCII with length2"
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
Improve multi-encoding output in 64tass Previously, we used the default character encoding from the project properties to determine how strings and character constants in the entire source file should be encoded. Now we switch between encodings as needed. The default character encoding is no longer relevant. High ASCII is now an actual encoding, rather than acting like ASCII that sometimes doesn't work. Because we can do high ASCII character operands with "| $80", we don't output a .enc to switch from ASCII to high ASCII unless we need to generate a string. (If we're already in high ASCII mode, the "| $80" isn't required but won't hurt anything.) We now do a scan up front to see if ASCII or high ASCII is needed, and only output the .cdefs for the encodings that are actually used. The only gap in the matrix is high ASCII DCI strings -- the ".shift" pseudo-op rejects text if the string doesn't start with the high bit clear.
2019-08-21 20:30:25 +00:00
.shift "pet dci"
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
Operand for ".enc" should be in double quotes The 64tass assembler was generating a warning.
2020-07-02 15:14:42 +00:00
.enc "screen"
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
.text "edoC neercS esrever"
.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
.text "null-term screen code?@"
.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
.ptext "Screen Code with length"
.byte $84
.text $18,$00,"Screen Code with length2"
.byte $84
.shift "Screen Code DCI"
.byte $84
.byte $85
.text "@abcdefghijklmnopqrstuvwxyz["
.byte $1c
.byte $1d
.byte $1e
.byte $1f
.text " !",$22,"#$%&'()*+,-./0123456789:;<=>?"
.byte $40
.text "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
.byte $5b
.byte $5c
.byte $5d
.byte $5e
.byte $5f
.byte $60
.byte $61
.byte $62
.byte $63
.byte $64
.byte $65
.byte $66
.byte $67
.byte $68
.byte $69
.byte $6a
.byte $6b
.byte $6c
.byte $6d
.byte $6e
.byte $6f
.byte $70
.byte $71
.byte $72
.byte $73
.byte $74
.byte $75
.byte $76
.byte $77
.byte $78
.byte $79
.byte $7a
.byte $7b
.byte $7c
.byte $7d
.byte $7e
.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
.byte $a0
.byte $a1
.byte $a2
.byte $a3
.byte $a4
.byte $a5
.byte $a6
.byte $a7
.byte $a8
.byte $a9
.byte $aa
.byte $ab
.byte $ac
.byte $ad
.byte $ae
.byte $af
.byte $b0
.byte $b1
.byte $b2
.byte $b3
.byte $b4
.byte $b5
.byte $b6
.byte $b7
.byte $b8
.byte $b9
.byte $ba
.byte $bb
.byte $bc
.byte $bd
.byte $be
.byte $bf
.byte $c0
.byte $c1
.byte $c2
.byte $c3
.byte $c4
.byte $c5
.byte $c6
.byte $c7
.byte $c8
.byte $c9
.byte $ca
.byte $cb
.byte $cc
.byte $cd
.byte $ce
.byte $cf
.byte $d0
.byte $d1
.byte $d2
.byte $d3
.byte $d4
.byte $d5
.byte $d6
.byte $d7
.byte $d8
.byte $d9
.byte $da
.byte $db
.byte $dc
.byte $dd
.byte $de
.byte $df
.byte $e0
.byte $e1
.byte $e2
.byte $e3
.byte $e4
.byte $e5
.byte $e6
.byte $e7
.byte $e8
.byte $e9
.byte $ea
.byte $eb
.byte $ec
.byte $ed
.byte $ee
.byte $ef
.byte $f0
.byte $f1
.byte $f2
.byte $f3
.byte $f4
.byte $f5
.byte $f6
.byte $f7
.byte $f8
.byte $f9
.byte $fa
.byte $fb
.byte $fc
.byte $fd
.byte $fe
.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
.enc "sg_ascii"
.text "ASCII escapes \: \\ \r \n \",$22," \' \t"
.byte $80
.enc "none"
.text "PETSCII escapes "
.byte $5c
.text ": "
.byte $5c
.byte $5c
.byte ' '
.byte $5c
.text "r "
.byte $5c
.text "n "
.byte $5c
.text $22," "
.byte $5c
.text "' "
.byte $5c
.byte 't'
.byte $80
.enc "screen"
.text "SCR escapes "
.byte $1c
.text ": "
.byte $1c
.byte $1c
.byte ' '
.byte $1c
.text "r "
.byte $1c
.text "n "
.byte $1c
.byte $22
.byte ' '
.byte $1c
.byte $27
.byte ' '
.byte $1c
.byte 't'
.byte $80
.enc "sg_hiascii"
.text "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
.enc "sg_ascii"
.shift "Hello"
.shift "HI"
.shift "X"
.shift "!"
.byte $86
.enc "sg_hiascii"
.byte $c8,$e5,$ec,$ec,$6f
.byte $c8,$49
.enc "sg_ascii"
.byte 'X'
.byte '!'
.byte $86
.enc "none"
.shift "hello"
.shift "hi"
.shift "x"
.shift "!"
.byte $86
.byte $c8,$c5,$cc,$cc,$4f
.byte $c8,$49
.byte 'x'
.byte '!'
.byte $86
.enc "screen"
.shift "Hello"
.shift "HI"
.shift "X"
.shift "!"
.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