6502bench/SourceGen/SGTestData/Expected/20010-string-types_cc65.cfg

# 6502bench SourceGen generated linker script for 20010-string-types
MEMORY {
    MAIN: file=%O, start=%S, size=65536;
#    MEM000: file=%O, start=$1000, size=3132;
}
SEGMENTS {
    CODE: load=MAIN, type=rw;
#    SEG000: load=MEM000, type=rw;
}
FEATURES {}
SYMBOLS {}
Regression test rework, part 2 Renamed the remaining tests. Only edits were to the project files that referenced .sym65/.cs. 2020-06-06 22:36:08 +00:00			`# 6502bench SourceGen generated linker script for 20010-string-types`
Add linker config scripts to cc65 generator output The system configuration you get with "-t none" works for smaller files but fails for larger ones. This updates the generator to produce a source file and linker script pair. (I kinda saw this one coming -- it's why the gen/asm dialog has a combo box for the file preview -- so it didn't require that much work.) This currently generates a fixed script for a generic system with 64KiB of RAM, using .ORGs to set the addresses as before. With this change, assembling a file with 65536 NOPs succeeds. (issue #39) 2018-11-18 21:49:02 +00:00			`MEMORY {`
			`MAIN: file=%O, start=%S, size=65536;`
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39) 2018-11-18 22:36:03 +00:00			`# MEM000: file=%O, start=$1000, size=3132;`
Add linker config scripts to cc65 generator output The system configuration you get with "-t none" works for smaller files but fails for larger ones. This updates the generator to produce a source file and linker script pair. (I kinda saw this one coming -- it's why the gen/asm dialog has a combo box for the file preview -- so it didn't require that much work.) This currently generates a fixed script for a generic system with 64KiB of RAM, using .ORGs to set the addresses as before. With this change, assembling a file with 65536 NOPs succeeds. (issue #39) 2018-11-18 21:49:02 +00:00			`}`
			`SEGMENTS {`
			`CODE: load=MAIN, type=rw;`
Attempt to generate segment names for cc65 This worked, sort of. The problem is that SourceGen will revert to hex output in certain situations, such as a broken symbolic reference. There happens to be one in the ZIPPY example, and it's on a relative branch. The goal with the segment stuff is to allow cc65 to treat the source as relocatable code. In that context, a relative branch to an absolute address doesn't make any sense, so the assembler reports a range error. We don't currently have a mechanism that guarantees no references are broken (and no affordance for finding them), so we can't make this mode the default yet. Instead, we continue to use the generic config, but generate the correct set of lines as comments. (issue #39) 2018-11-18 22:36:03 +00:00			`# SEG000: load=MEM000, type=rw;`
Add linker config scripts to cc65 generator output The system configuration you get with "-t none" works for smaller files but fails for larger ones. This updates the generator to produce a source file and linker script pair. (I kinda saw this one coming -- it's why the gen/asm dialog has a combo box for the file preview -- so it didn't require that much work.) This currently generates a fixed script for a generic system with 64KiB of RAM, using .ORGs to set the addresses as before. With this change, assembling a file with 65536 NOPs succeeds. (issue #39) 2018-11-18 21:49:02 +00:00			`}`
			`FEATURES {}`
			`SYMBOLS {}`