Marko Mäkelä 504d13a527 Initialize the sprite data at compilation time, not at runtime. ... VIC_II::SPRITE_ALIGNMENT: The MOS 6566/6567/6569 VIC-II expects sprite data to be aligned at 64 bytes. VIC_II::SPRITE_STARTING_BANK: Remove. VIC_II::write_multi_color_pixel(), VIC_II::write_pixel(): Make static. Write to the specified memory address. VIC_II::Sprite::Sprite(): Refactored from VIC_II::make_sprite(). VIC_II::enable_sprite(): Take a Sprite reference. sBall, sBat: Sprite images, declared at global scope. FIXME: How to ensure that the VIC_II::Sprite addresses do not end up in the range 0x1000..0x1fff or 0x9000..0x9fff (where the character generator ROM is overriding RAM)? Any portable alternative to using GCC-style __attribute__((section("sprites"))) and a linker script? Note: Declaring the sprite images as static const objects in main() would cause clang++4.0-svn279916-1 to generate code for initializing them. So, we will declare the objects in the global scope. This has been tested on a Commodore 64 with the following steps: clang++-4.0 -m32 -O3 -std=c++1z -S pong.cpp x86-to-6502 < pong.s > pong.asm edit pong.asm to define code start at 0x900 and to adapt the output invoke some 6502 assembler SYS2304 to run the output on a Commodore 64		2016-10-06 18:00:58 +03:00
..
pong.cpp	Initialize the sprite data at compilation time, not at runtime.	2016-10-06 18:00:58 +03:00
test2.cpp	Add support for D register, more opcodes	2016-07-07 10:51:54 -06:00
test3.cpp	Add support for D register, more opcodes	2016-07-07 10:51:54 -06:00
test.asm	Add some docs and test and cmake support	2016-07-07 15:48:27 -06:00
test.c	Add some docs and test and cmake support	2016-07-07 15:48:27 -06:00
test.cpp	Add support for D register, more opcodes	2016-07-07 10:51:54 -06:00