6502/6502-cpp
1
0
Fork 0
mirror of https://github.com/lefticus/6502-cpp.git synced 2024-06-26 00:29:30 +00:00
Code Issues Projects Releases Wiki Activity
23 Commits 2 Branches 2 Tags 237 KiB
C++ 85.9%
CMake 14.1%
504d13a527
Go to file
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
examples Initialize the sprite data at compilation time, not at runtime. 2016-10-06 18:00:58 +03:00
src Implement some more instructions, and fix typos. 2016-10-06 17:41:33 +03:00
CMakeLists.txt Add some docs and test and cmake support 2016-07-07 15:48:27 -06:00
make_file.sh Reorganize file structure 2016-08-24 16:55:08 -06:00
readme.md Add some docs and test and cmake support 2016-07-07 15:48:27 -06:00

readme.md

About

Attempts to translate x86 assembly into mos6502 assembly.

Why?

Why not? I figured I just barely knew some x86 and some 6502, so why not learn some more about both. Besides, this project can actually have some interesting applications.

Example

After compilation (requires a full C++14 compiler), you can run something like this:

// test.asm
main:
	movb	$1, 53280
	xorl	%eax, %eax
	ret

cat test.asm | x86-to-6502

And get this output:

main:
	ldy #$1
	sty 53280
	lda $00
	rts

Caveats

  • Nothing is guaranteed. This could break your computer. Who knows?
  • All values are truncated to 8 bit. We have no support for 16bit math or pointers yet
  • Only as many instructions are supported as I have needed to support to get my test cases working

To Do

Everything

Well, lots of things.

Better code organization

I really had no idea what I was doing when I started this. So, like all code, it's going to need some improvements along the way to make it more organized and more maintainable.

Improvements

  • Keep track of input source lines and add comments in output to show where lines came from, for learning / debugging purposes
  • Better / more efficient translation
  • Support for 16bit math? Maybe? We need to at least be able to do 16bit pointer math
  • Consider supporting the "Sweet 16" virtual 16bit CPU that Woz designed?
  • Maybe for 16bit operation we try to detect if the input code is working on 8bit registers or 16+bit registers and do the right thing?
  • Support for more CPU instructions
  • A test suite