You can mix & match menu, game and score kernels so the location of things will move around in 6507 BIN. Sure I could prebuild each combination, at the moment I have plans for 2 menu, 3 game kernels and 3 score kernels so would need to pre-build 18 BIN for inclusion by the C code, but that quickly becomes large as new choices are added. A new score option was suggested by kdgarris, which would bump that up to 24 pre-built BINs. Add a new menu option after that and we're at 36.
To complicate the above, I'm working on having it push the free space to the front of the 6507 code, so if the choices result in 3K of 6507 code an extra 1K will be available in the C code space.
Additionally, letting dasm build from source means easier debugging via Stella, it'll pick up the symbol file and show my labels rather than like LF093.
I agree that it's easier to just let the assembler do all the work of locating the included code. You also don't have to deal wiith linking of object code. I wanted the same simplicity in C02 (http://atariage.com/...4-c02-compiler/) but rather than using dasm's include functionality, the compiler copies the include file contents directly into the asm file that is generated.
It would be nice if any commands that use temp variables had them listed next to them on the bB page so we would know how far down the list (6, 5, 4, 3, 2, 1) we can go with our own use of temp variables when using a certain command. If we're using a command that uses temp1 and temp2, we'd know it's safe to use temp6, temp5, temp4, and temp3, then use them the way you mentioned above.
Awesome! I didn't know that adding to playerXheight would copy any rows like that. That could be a handy trick. Did you still have to define the colors of the rows that weren't yet in existence, presumably?
There isn't any copying of rows happening. All that changing playerXheight does is make the player taller ot shorter.
The reason the player is solid pixels is because settng player1pointerlo to 1 and player1pointerhi to 255 makes the player data point to location 65280 ($FF00) which is at the end of the catridge ROM and the compile just happens to fill unused space with 255's ($FF). If the compiled code ever exceeds 3,584 bytes, then you will the player will contain apparently random patterns.
As for the colors, I'm assuming that the example posted used the single-color player option. If multi-color were enabled, the all the lines of the player would be color $FF, or white.
So I'm curious how this works.. Is there a little bit of extra hardware in the cartridge that "listens" in on those addresses and then directs the bus to a bank? Perhaps a simple set of transistors turned high by the read? (I'm not an electronics whiz)