6502bench/SourceGen/SGTestData/Expected/20052-branches-and-banks_acme.S

;ACME can't handle 65816 code that lives outside bank zero
*       =       $0000
        !pseudopc $1000 {
        !hex    18fbe2304c00002c0000a500a503d0ba30b862b5ff7006826d00000102a51482
        !hex    a5ff2c80005c0000442cc0ff823d00cf000044af000044ad0000a50030f562b2
        !hex    ffd0b082a9ff1700170044cfc0ff44f005303c8239005c0020002c0020f41700
        !hex    f44400d003dc1300ea201220201520200f202256341260
        } ;!pseudopc
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			`;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`
			`!pseudopc $1000 {`
Add a blank line between constants and addresses In the assembler output, add a blank line between the constants and addresses in the long list of equates. The earlier change that corrected the BIT instruction caused test 2009-branches-and-banks to fail, because it was relying on the idea that BIT made the carry flag indeterminate. Changing a BCC to a BVS restored the desired behavior. 2019-10-23 05:43:10 +00:00			`!hex 18fbe2304c00002c0000a500a503d0ba30b862b5ff7006826d00000102a51482`
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			`!hex a5ff2c80005c0000442cc0ff823d00cf000044af000044ad0000a50030f562b2`
			`!hex ffd0b082a9ff1700170044cfc0ff44f005303c8239005c0020002c0020f41700`
			`!hex f44400d003dc1300ea201220201520200f202256341260`
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			`} ;!pseudopc`