6502bench/SourceGen/SGTestData/Expected/20042-address-changes_acme.S

;ACME can't handle 65816 code that lives outside bank zero
*       =       $0000
        !pseudopc $021000 {
        !hex    18fbe2ff2000112007114c00202c0011a911a211a01162f7ff80f52c0011a922
        !hex    a222a02262f9ff4c05112c0011a933a233a03362fbff80f92c0020f01380192c
        !hex    2020f004825800ea2c8020ad2820202820ad2920202920ad7f20207f20ad8020
        !hex    208020a500f061adeaea4c003000280000000000000000000000000000000000
        !hex    0000000000000000000000000000002c0030a944a244a04482f5000001022c01
        !hex    31ad0c30ad0d30ad0e30ad0f30ad0031f06deaea00012c8231ad9031ad9131ad
        !hex    00328070eaea2c00320001
        } ;!pseudopc
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			`;ACME can't handle 65816 code that lives outside bank zero`
Fix ACME code gen "overflow" ACME has a "real" PC and a "pseudo" PC. The "real" PC determines the initial position in a 64KB buffer used to hold assembler output. If the amount of code generated runs off the end, the assembler fails with "produced too much code". The source code generator in SourceGen was outputting a "real" PC for the first address range and "psuedo" PCs for any address ranges that followed. This produced nice results for code with a single range, but caused problems for multi-range sources if the initial range was high in memory and a later range was lower in memory. While the assembler isn't actually generating more than 64KB of code, ACME's buffer management was detecting an overflow. Now, if a source file has multiple address ranges, we set the "real" PC to $0000 and use a "pseudo" PC for all ranges. Output for projects with a single address range is unmodified. 2020-05-14 23:37:33 +00:00			`* = $0000`
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			`!pseudopc $021000 {`
			`!hex 18fbe2ff2000112007114c00202c0011a911a211a01162f7ff80f52c0011a922`
			`!hex a222a02262f9ff4c05112c0011a933a233a03362fbff80f92c0020f01380192c`
			`!hex 2020f004825800ea2c8020ad2820202820ad2920202920ad7f20207f20ad8020`
			`!hex 208020a500f061adeaea4c003000280000000000000000000000000000000000`
			`!hex 0000000000000000000000000000002c0030a944a244a04482f5000001022c01`
			`!hex 31ad0c30ad0d30ad0e30ad0f30ad0031f06deaea00012c8231ad9031ad9131ad`
			`!hex 00328070eaea2c00320001`
Finish ACME v0.96.4 support There's no easy way to make non-zero-bank 65816 code work, so I'm punting and just generating a whole-file hex dump for those. This renders tests 2007 and 2009 useless, so I'm hesitant to claim that ACME support is fully functional. 2019-08-04 21:48:42 +00:00			`} ;!pseudopc`