6502/6502bench
1
0
Fork 0
mirror of https://github.com/fadden/6502bench.git synced 2024-12-11 13:50:13 +00:00
Code Issues Projects Releases Wiki Activity
3a02132694
6502bench/SourceGen/SGTestData/Expected/20042-address-changes_merlin32.S

108 lines
1.9 KiB
ArmAsm
Raw Normal View History

Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
org $021000
Initial file commit
2018-09-28 17:05:11 +00:00
clc
xce
sep #$ff
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
jsr L21100
jsr L21107
jmp L22000
Initial file commit
2018-09-28 17:05:11 +00:00
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
org $021100
L21100 bit L21100
L21103 lda #$11
Initial file commit
2018-09-28 17:05:11 +00:00
ldx #$11
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
L21107 ldy #$11
per L21103
bra L21103
Initial file commit
2018-09-28 17:05:11 +00:00
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
org $021100
:L21100_0 bit :L21100_0
Initial file commit
2018-09-28 17:05:11 +00:00
lda #$22
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
:L21105 ldx #$22
Initial file commit
2018-09-28 17:05:11 +00:00
ldy #$22
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
per :L21105
jmp :L21105
Initial file commit
2018-09-28 17:05:11 +00:00
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
org $021100
:L21100_1 bit :L21100_1
Initial file commit
2018-09-28 17:05:11 +00:00
lda #$33
ldx #$33
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
:L21107_0 ldy #$33
per :L21107_0
bra :L21107_0
Initial file commit
2018-09-28 17:05:11 +00:00
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
org $022000
L22000 bit L22000
beq $022018
bra :L22020
Initial file commit
2018-09-28 17:05:11 +00:00
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
org $022020
:L22020 bit :L22020
beq $022029
brl :L22080
Initial file commit
2018-09-28 17:05:11 +00:00
Finish removal of "disable label localizer" feature The label localizer is now always on. The regression tests turned it off by default, but that's no longer allowed, so the generated output has changed for many of them. The tests themselves were not altered.
2019-11-17 01:15:03 +00:00
:offend nop
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
org $022080
:L22080 bit :L22080
Finish removal of "disable label localizer" feature The label localizer is now always on. The regression tests turned it off by default, but that's no longer allowed, so the generated output has changed for many of them. The tests themselves were not altered.
2019-11-17 01:15:03 +00:00
lda :offend
jsr :offend
Allow explicit widths in project/platform symbols, part 3 Implement multi-byte project/platform symbols by filling out a table of addresses. Each symbol is "painted" into the table, replacing an existing entry if the new entry has higher priority. This allows us to handle overlapping entries, giving boosted priority to platform symbols that are defined in .sym65 files loaded later. The bounds on project/platform symbols are now rigidly defined. If the "nearby" feature is enabled, references to SYM-1 will be picked up, but we won't go hunting for SYM+1 unless the symbol is at least two bytes wide. The cost of adding a symbol to the symbol table is about the same, but we don't have a quick way to remove a symbol. Previously, if two platform symbols had the same value, the symbol with the alphabetically lowest label would win. Now, the symbol defined in the most-recently-loaded file wins. (If you define two symbols with the same value in the same file, it's still resolved alphabetically.) This allows the user to pick the winner by arranging the load order of the platform symbol files. Platform symbols now keep a reference to the file ident of the symbol file that defined them, so we can show the symbols's source in the Info panel. These changes altered the behavior of test 2008-address-changes, which includes some tests on external addresses that are close to labeled internal addresses. The previous behavior essentially treated user labels as being 3 bytes wide and extending outside the file bounds, which was mildly convenient on occasion but felt a little skanky. (We could do with a way to define external symbols relative to internal symbols, for things like the source address of code that gets relocated.) Also, re-enabled some unit tests. Also, added a bit of identifying stuff to CrashLog.txt.
2019-10-02 23:26:05 +00:00
lda $2029
jsr $2029
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
lda :L22080-1
jsr :L22080-1
lda :L22080
jsr :L22080
Initial file commit
2018-09-28 17:05:11 +00:00
lda $00
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
beq :L22100
Initial file commit
2018-09-28 17:05:11 +00:00
dfb $ad
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
org $022100
:L22100 nop
Initial file commit
2018-09-28 17:05:11 +00:00
nop
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
jmp :L23000
Initial file commit
2018-09-28 17:05:11 +00:00
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
org $022800
Initial file commit
2018-09-28 17:05:11 +00:00
dfb $00
dfb $28
Tweak Merlin DS output The default fill value is $00. Don't specify it explicitly when we don't have to.
2020-01-02 01:42:21 +00:00
ds 14
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
org $022820
Tweak Merlin DS output The default fill value is $00. Don't specify it explicitly when we don't have to.
2020-01-02 01:42:21 +00:00
ds 18
Initial file commit
2018-09-28 17:05:11 +00:00
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
org $023000
:L23000 bit :L23000
Initial file commit
2018-09-28 17:05:11 +00:00
lda #$44
ldx #$44
ldy #$44
Finish removal of "disable label localizer" feature The label localizer is now always on. The regression tests turned it off by default, but that's no longer allowed, so the generated output has changed for many of them. The tests themselves were not altered.
2019-11-17 01:15:03 +00:00
brl :fwd
Initial file commit
2018-09-28 17:05:11 +00:00
Finish removal of "disable label localizer" feature The label localizer is now always on. The regression tests turned it off by default, but that's no longer allowed, so the generated output has changed for many of them. The tests themselves were not altered.
2019-11-17 01:15:03 +00:00
:ulabel dfb $00
Initial file commit
2018-09-28 17:05:11 +00:00
dfb $01
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
org $023100
Tweak "nearby" label finder The code that found a nearby data target for an instruction operand was searching backward but not forward. We now take one step forward, so that "LDA TABLE-1,Y" fills in automatically. This altered 2008-address-changes, which had just this situation. It didn't alter 2010-target-adjustment, but the existing tests were insufficient and have been improved.
2019-10-30 01:12:22 +00:00
dfb $02
Initial file commit
2018-09-28 17:05:11 +00:00
Finish removal of "disable label localizer" feature The label localizer is now always on. The regression tests turned it off by default, but that's no longer allowed, so the generated output has changed for many of them. The tests themselves were not altered.
2019-11-17 01:15:03 +00:00
:fwd bit :fwd
lda :ulabel
lda :ulabel+1
Allow explicit widths in project/platform symbols, part 3 Implement multi-byte project/platform symbols by filling out a table of addresses. Each symbol is "painted" into the table, replacing an existing entry if the new entry has higher priority. This allows us to handle overlapping entries, giving boosted priority to platform symbols that are defined in .sym65 files loaded later. The bounds on project/platform symbols are now rigidly defined. If the "nearby" feature is enabled, references to SYM-1 will be picked up, but we won't go hunting for SYM+1 unless the symbol is at least two bytes wide. The cost of adding a symbol to the symbol table is about the same, but we don't have a quick way to remove a symbol. Previously, if two platform symbols had the same value, the symbol with the alphabetically lowest label would win. Now, the symbol defined in the most-recently-loaded file wins. (If you define two symbols with the same value in the same file, it's still resolved alphabetically.) This allows the user to pick the winner by arranging the load order of the platform symbol files. Platform symbols now keep a reference to the file ident of the symbol file that defined them, so we can show the symbols's source in the Info panel. These changes altered the behavior of test 2008-address-changes, which includes some tests on external addresses that are close to labeled internal addresses. The previous behavior essentially treated user labels as being 3 bytes wide and extending outside the file bounds, which was mildly convenient on occasion but felt a little skanky. (We could do with a way to define external symbols relative to internal symbols, for things like the source address of code that gets relocated.) Also, re-enabled some unit tests. Also, added a bit of identifying stuff to CrashLog.txt.
2019-10-02 23:26:05 +00:00
lda $300e
Initial file commit
2018-09-28 17:05:11 +00:00
lda $300f
Finish removal of "disable label localizer" feature The label localizer is now always on. The regression tests turned it off by default, but that's no longer allowed, so the generated output has changed for many of them. The tests themselves were not altered.
2019-11-17 01:15:03 +00:00
lda :fwd-1
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
beq :L23182
Initial file commit
2018-09-28 17:05:11 +00:00
dfb $ea
dfb $ea
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
org $023180
Initial file commit
2018-09-28 17:05:11 +00:00
dfb $00
dfb $01
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
:L23182 bit :L23182
Finish removal of "disable label localizer" feature The label localizer is now always on. The regression tests turned it off by default, but that's no longer allowed, so the generated output has changed for many of them. The tests themselves were not altered.
2019-11-17 01:15:03 +00:00
lda :label1
lda :label1+1
lda :label1+112
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
bra :L23200
Initial file commit
2018-09-28 17:05:11 +00:00
Finish removal of "disable label localizer" feature The label localizer is now always on. The regression tests turned it off by default, but that's no longer allowed, so the generated output has changed for many of them. The tests themselves were not altered.
2019-11-17 01:15:03 +00:00
:label1 dfb $ea
Initial file commit
2018-09-28 17:05:11 +00:00
dfb $ea
Improve handling of C64 PRG header C64 PRG files are pretty common. Their salient feature is that they start with a 16-bit value that is used as the load address. The value is commonly generated by the assembler itself, rather than explicitly added to the source file. Not all assemblers know what a PRG file is, and some of them handle it in ways that are difficult to guarantee in SourceGen. ACME adds the 16-bit header when the output file name ends in ".prg", cc65 uses a modified config file, 64tass uses a different command-line option, and Merlin 32 has no idea what they are. This change adds PRG file detection and handling to the 64tass code generator. Doing so required making a few changes to the gen/asm interfaces, because we now need to have the generator pass additional flags to the assembler, and sometimes we need code generation to start somewhere other than offset zero. Overall the changes were pretty minor. The 20042-address-changes test needed a 6502-only variant. A new test (20040-address-changes) has been added and given a PRG header. As part of this change the 65816 variant was changed to use addresses in bank 2, which uncovered a code generation bug that this change also fixes. The 64tass --long-address flag doesn't appear to be necessary for files <= 65536 bytes long, so we no longer emit it for those. (issue #90)
2020-10-17 23:10:48 +00:00
org $023200
:L23200 bit :L23200
Initial file commit
2018-09-28 17:05:11 +00:00
dfb $00
dfb $01
Reference in New Issue Copy Permalink