write_multi_color_line(), write_line(): Remove.
VIC_II::SpriteLine<bool multicolor>: A line of sprite bitmap data.
The constructor converts one line of data at a time.
VIC_II::Sprite<bool multicolor>: An array of SpriteLine.
This change does not affect the generated binary code.
In the assembler code generated by clang++-4.0, the binary data
will be formatted in groups of 3 bytes instead of 3*21 bytes.
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
