To be clear, I don't want to include C libs or compiled C code, I thought maybe a compiler may still be able to optimize inline ASM code.
There is more or less 25KB of 6502 code, and about 13KB of game data.
I can give a bit more detail but the consensus seems to be negative.
Right now the game runs in a "virtual" 6502 environment, that means there's no hardware specific emulation (no graphics no sound), except for input. The draw functions are intercepted and redirected to D3D.
Here's a screenshot at init:
-each square is a byte.
-each white frame is a label (I can hover over it and get its name)
-each black byte has never been accessed
-each red byte is byte that's been written to
-each blue byte is byte that's been read (uninitialized access!)
-each green byte is byte that's been written to and read.
After running the game for 2 frames:
The area between $2700-$7d00 is the code. Before/After that it's data.
All the memory up to $9200 is used (the black areas will be used)
ZP is almost full and gives back some decent amount of code space. I'm already using the bottom of the stack.
After just 10 seconds of gameplay it's mostly all green, so yes the game touches a lot of code and data.
I'm using 37KB of RAM *without* Screen buffers (modeE 2 * 160pix*216 lines ), PMG Area, DL, disc buffer, Atari code. I think my 64 KB are pretty much full.
Not counting graphics/sound yet!
Dmsc, another forum member provided a fast lz4 decompressor at +-1500 bytes/frame. The game touches a lot of code per frame so decompressing code on the fly doesn't seem like a good option.
I'm hoping I'll be able to decompress graphics data on the fly though.
The project is 128KB. All the graphics/sound data will go into the extra 64KB.
Nope the code is 6502 originally.
I've done a little bit of code/data optimization on the project and I'm not very good at it , managed to save a few KB though.
Not yet but perhaps people will be interested in contributing once it gets a public release.