6502/6502bench
1
0
Fork 0
mirror of https://github.com/fadden/6502bench.git synced 2024-12-12 21:29:30 +00:00
Code Issues Projects Releases Wiki Activity
8b1e70fa58
6502bench/SourceGen/SGTestData/Expected/20130-char-encoding-p_merlin32.S

365 lines
8.4 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.
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
org $1000
lda #'A'
lda #"A"
lda #$c1
lda #$41
ldx #'a'
ldx #"a"
ldx #$41
ldx #$01
Rework 201XX-char-encoding-X tests We have a single character-encoding test that is cloned 3x so we can exercise the different values for the project's default character set. It was a 65816 test because it tested 16-bit immediate char operands, but that's a very small part of it. The 65816-specific portion is now 20122-char-encoding. The rest is now 201{2,3,4}0-char-encoding-X.
2020-10-19 22:01:02 +00:00
lda #$7f ;inappropriate format should be ignored
Add 2016-char-encoding-a and variations All tests use the same data file and nearly the same project file. The only difference is the default text encoding property setting. For "-a" it's ASCII, for "-p" it's PETSCII, for "-s" it's C64 screen code. Right now this only affects the code generated for 64tass. The test itself is a collection of strings and characters in the supported character encodings. How these are handled varies significantly between assemblers.
2019-08-16 21:53:50 +00:00
lda #$7f
lda #$7f
lda #$7f
lda #$0d
Rework 201XX-char-encoding-X tests We have a single character-encoding test that is cloned 3x so we can exercise the different values for the project's default character set. It was a 65816 test because it tested 16-bit immediate char operands, but that's a very small part of it. The 65816-specific portion is now 20122-char-encoding. The rest is now 201{2,3,4}0-char-encoding-X.
2020-10-19 22:01:02 +00:00
jmp L144B
Add 2016-char-encoding-a and variations All tests use the same data file and nearly the same project file. The only difference is the default text encoding property setting. For "-a" it's ASCII, for "-p" it's PETSCII, for "-s" it's C64 screen code. Right now this only affects the code generated for 64tass. The test itself is a collection of strings and characters in the supported character encodings. How these are handled varies significantly between assemblers.
2019-08-16 21:53:50 +00:00
dfb 'C'
dfb "C"
dfb $c3
dfb $43
dw 'd'
dw "d"
dw $44
dw $04
ddb 'E'
ddb "E"
ddb $c5
ddb $45
dfb $80
asc 'low ASCII str'
asc "high ASCII str"
dfb $80
hex d0c5d4d3c3c9c920535452
dfb $80
hex 53031205050e20430f040520131412
dfb $82
asc 07,'Low ASCII CRLF',0d0a
dfb $82
asc 87,"High ASCII CRLF",8d8a
dfb $82
hex 93d0c5d4d3c3c9c920574954482096434f4e54524f4c0520434f4445530d
dfb $83
asc ' !"#$%&',27,'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWX'
asc 'YZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~'
dfb $83
asc " !",a2,"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWX"
asc "YZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~"
dfb $83
hex 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
hex 40c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9da5b
dfb $5c
dfb $5d
dfb $5e
dfb $5f
dfb $60
hex 4142434445464748494a4b4c4d4e4f505152535455565758595a
dfb $7b
dfb $7c
dfb $7d
dfb $7e
dfb $83
hex 202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f
hex 004142434445464748494a4b4c4d4e4f505152535455565758595a1b
dfb $1c
dfb $1d
dfb $1e
dfb $1f
dfb $40
hex 0102030405060708090a0b0c0d0e0f101112131415161718191a
dfb $7b
dfb $7c
dfb $7d
dfb $7e
dfb $84
hex c9c9c3d3d4c5d02045535245564552
dfb $84
hex 4e554c4c205445524d20d0c5d4d3c3c9c900
dfb $84
hex d4484953204e554c4c2d5445524d494e4154454420535452494e472049532054
hex 4f4f204c4f4e4720544f20464954204f4e20412053494e474c45204c494e452c
hex 20414e442057494c4c2042452053504c49542e00
dfb $84
hex 13d0c5d4d3c3c9c92057495448204c454e475448
dfb $84
hex 1400d0c5d4d3c3c9c92057495448204c454e47544832
dfb $84
PETSCII does DCI I didn't think it made sense, but I found something that used it, so apparently it's a thing. This updates the operand editor to let you choose PETSCII+DCI, and updates the assemblers to handle it correctly (really just 64tass, since the others either don't have a DCI directive or don't deal with PETSCII at all). Changed the char-encoding sample from "bad dcI" to "pet dcI", and updated the documentation.
2019-08-21 00:55:12 +00:00
hex 504554204443c9
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
dfb $84
hex 05040f43200e05051203532005131205160512
dfb $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
hex 0e150c0c2d1405120d2013031205050e20030f04053f00
dfb $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
hex 1753031205050e20430f04052017091408200c050e071408
dfb $84
hex 180053031205050e20430f04052017091408200c050e07140832
dfb $84
hex 53031205050e20430f0405204443c9
dfb $84
dfb $85
dfb $00
dfb $01
dfb $02
dfb $03
dfb $04
dfb $05
dfb $06
dfb $07
dfb $08
dfb $09
dfb $0a
dfb $0b
dfb $0c
dfb $0d
dfb $0e
dfb $0f
dfb $10
dfb $11
dfb $12
dfb $13
dfb $14
dfb $15
dfb $16
dfb $17
dfb $18
dfb $19
dfb $1a
dfb $1b
dfb $1c
dfb $1d
hex 1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d
hex 3e3f404142434445464748494a4b4c4d4e4f505152535455565758595a5b
dfb $5c
dfb $5d
dfb $5e
dfb $5f
dfb $60
dfb $61
dfb $62
dfb $63
dfb $64
dfb $65
dfb $66
dfb $67
dfb $68
dfb $69
dfb $6a
dfb $6b
dfb $6c
dfb $6d
dfb $6e
dfb $6f
dfb $70
dfb $71
dfb $72
dfb $73
dfb $74
dfb $75
dfb $76
dfb $77
dfb $78
dfb $79
dfb $7a
dfb $7b
dfb $7c
dfb $7d
dfb $7e
dfb $7f
dfb $80
dfb $81
dfb $82
dfb $83
dfb $84
dfb $85
dfb $86
dfb $87
dfb $88
dfb $89
dfb $8a
dfb $8b
dfb $8c
dfb $8d
dfb $8e
dfb $8f
dfb $90
dfb $91
dfb $92
dfb $93
dfb $94
hex 95969798999a9b9c
dfb $9d
dfb $9e
dfb $9f
dfb $a0
dfb $a1
dfb $a2
dfb $a3
dfb $a4
dfb $a5
dfb $a6
dfb $a7
dfb $a8
dfb $a9
dfb $aa
dfb $ab
dfb $ac
dfb $ad
dfb $ae
dfb $af
dfb $b0
dfb $b1
dfb $b2
dfb $b3
dfb $b4
dfb $b5
dfb $b6
dfb $b7
dfb $b8
dfb $b9
dfb $ba
dfb $bb
dfb $bc
dfb $bd
dfb $be
dfb $bf
dfb $c0
hex c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9da
dfb $db
dfb $dc
dfb $dd
dfb $de
dfb $df
dfb $e0
dfb $e1
dfb $e2
dfb $e3
dfb $e4
dfb $e5
dfb $e6
dfb $e7
dfb $e8
dfb $e9
dfb $ea
dfb $eb
dfb $ec
dfb $ed
dfb $ee
dfb $ef
dfb $f0
dfb $f1
dfb $f2
dfb $f3
dfb $f4
dfb $f5
dfb $f6
dfb $f7
dfb $f8
dfb $f9
dfb $fa
dfb $fb
dfb $fc
dfb $fd
dfb $fe
dfb $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
asc 'ASCII escapes \: \\ \r \n \" \',27,' \t'
dfb $80
hex d0c5d4d3c3c9c9204553434150455320
dfb $5c
hex 3a20
dfb $5c
dfb $5c
dfb $20
dfb $5c
hex 5220
dfb $5c
hex 4e20
dfb $5c
hex 2220
dfb $5c
hex 2720
dfb $5c
dfb $54
dfb $80
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
hex 534352200513030110051320
dfb $1c
hex 3a20
dfb $1c
dfb $1c
dfb $20
dfb $1c
hex 1220
dfb $1c
hex 0e20
dfb $1c
dfb $22
dfb $20
dfb $1c
dfb $27
dfb $20
dfb $1c
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
dfb $14
dfb $80
asc "HIGH escapes \: \\ \r \n \0 \' \t"
dfb $80
:L14DA nop
Fix DCI string edge case If a DCI string ended with a string delimiter or non-ASCII character (e.g. a PETSCII char with no ASCII equivalent), the code generator output the last byte as a hex value. This caused an error because it was outputting the raw hex value, with the high bit already set, which the assembler did not expect. This change corrects the behavior for code generation and on-screen display, and adds a few samples to the regression test suite. (see issue #102)
2021-08-10 21:08:39 +00:00
jmp :L1587
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
dfb $86
dci 'Hello'
dci 'HI'
dci 'X'
dci '!'
dfb $86
dci "Hello"
dci "HI"
dfb 'X'
dfb '!'
dfb $86
hex 48454c4ccf
hex 48c9
hex d8
hex a1
dfb $86
hex c8c5cccc4f
hex c849
dfb $58
dfb $21
dfb $86
hex 48050c0c8f
hex 48c9
hex d8
hex a1
dfb $86
Fix DCI string edge case If a DCI string ended with a string delimiter or non-ASCII character (e.g. a PETSCII char with no ASCII equivalent), the code generator output the last byte as a hex value. This caused an error because it was outputting the raw hex value, with the high bit already set, which the assembler did not expect. This change corrects the behavior for code generation and on-screen display, and adds a few samples to the regression test suite. (see issue #102)
2021-08-10 21:08:39 +00:00
dci 'ascii',7f
dfb $86
dci '"A quote1"'
dci 27,'A quote2',27
dfb $86
dci a2,"HA quote1",a2
dci "'HA quote2'"
dfb $86
hex 50455453434949de
dfb $86
hex 22412051554f544531a2
hex 27412051554f544532a7
dfb $86
hex dc
dfb $86
hex 53031205050e430f04059e
dfb $86
hex 22412011150f140531a2
hex 27412011150f140532a7
dfb $86
hex 9c
dfb $86
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
Fix DCI string edge case If a DCI string ended with a string delimiter or non-ASCII character (e.g. a PETSCII char with no ASCII equivalent), the code generator output the last byte as a hex value. This caused an error because it was outputting the raw hex value, with the high bit already set, which the assembler did not expect. This change corrects the behavior for code generation and on-screen display, and adds a few samples to the regression test suite. (see issue #102)
2021-08-10 21:08:39 +00:00
:L1587 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