6502/6502bench
1
0
Fork 0
mirror of https://github.com/fadden/6502bench.git synced 2024-12-01 22:50:35 +00:00
Code Issues Projects Releases Wiki Activity
88c56616f7
6502bench/SourceGen/SGTestData/Expected/2016-char-encoding-a_64tass.S

309 lines
7.0 KiB
ArmAsm
Raw Normal View History

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
;Project edited to mark some non-ASCII operands as ASCII.
.cpu "65816"
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
.enc sg_hiascii
.cdef $20,$7e,$a0
Change the way ASCII is handled for 64tass The documentation for 64tass says you're required to pass "--ascii" when the source file is ASCII (as opposed to PETSCII). We were ignoring this, but it turns out that everything works a bit better if we don't. So we now pass "--ascii" on the command line, and add a two-line character encoding definition to every file that is generated with ASCII as the default encoding. The sg_petscii and sg_screen encodings go away, as PETSCII is now the default, and we can use the built-in "screen" encoding.
2019-08-20 18:21:30 +00:00
.enc sg_ascii
.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
.as
.xs
clc
xce
sep #$30
lda #'A'
lda #'A' | $80
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
.enc none
lda #'A'
.enc screen
lda #'A'
.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
ldx #'a'
ldx #'a' | $80
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
.enc none
ldx #'a'
.enc screen
ldx #'a'
.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 #$7f
lda #$7f
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
.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
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
.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
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
.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
rep #$30
.al
.xl
lda #'B'
lda #'B' | $80
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
.enc none
lda #'B'
.enc screen
lda #'B'
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
sep #$30
.as
.xs
rts
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
.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
.byte 'C'
.byte 'C' | $80
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
.enc none
.byte 'C'
.enc screen
.byte 'C'
.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
.word 'd'
.word 'd' | $80
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
.enc none
.word 'd'
.enc screen
.word 'd'
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 $00,$45
.byte $00,$c5
.byte $00,$c5
.byte $00,$45
.byte $80
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
.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
.text "low ASCII str"
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
.enc sg_hiascii
.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
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
.enc none
.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
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
.enc screen
.text "Screen Code 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 $82
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
.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
.text $07,"Low ASCII CRLF",$0d,$0a
.byte $82
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
.enc sg_hiascii
.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
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
.enc none
.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
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
.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
.text " !",$22,"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVW"
.text "XYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~"
.byte $83
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
.enc sg_hiascii
.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
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
.enc none
.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"
.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
.text "{|}~"
.byte $83
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
.enc screen
.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 $1c
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 $1e
.byte $1f
.byte $40
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"
.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
.text "{|}~"
.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
.enc none
.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
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
.enc screen
.text "edoC neercS 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
.ptext "Screen Code 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 $18,$00,"Screen Code 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 "Screen Code 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
.byte $85
;$00-ff block
.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
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
.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
.text " !",$22,"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVW"
.text "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
.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
Reference in New Issue Copy Permalink