TROGBlog

I don't use many subroutines, so I'm only reserving 8 bytes for the stack.

 

Eight bytes? You think you're on a 5200 or something? Strat-O-Gems does a fair amount of subroutine stuff, and it works just fine with a limit of 2 bytes pre-stacked before any kernel entry, plus two for the kernel entry itself. There are a few spots in the kernel that use one more stack level (another two bytes), but the last two bytes of kernel scratchpad aren't used by those routines, and the calling code doesn't mind if they get trashed.

Only 8, I'm using 14. My 4 color score routine pushes the graphics for 2 of the digits onto the stack. It was the first routine I wrote before I remembered my 6502 coding from back in the day. Think I'll redo it before I start on the fireball rewrite.

My 4 color score routine pushes the graphics for 2 of the digits onto the stack.

 

I tend not to use the stack much except for JSR/RTS. If I need to stash the accumulator for awhile, I find a named address where I can do it. I don't have any formal means of keeping track of which locations are 'live', but can usually find some location that's not in use. Sometimes I'll use PHA/PLA or PHP/PLP if I know that I won't be making any subroutine calls with the data still on the stack, but generally I think stack usage should be kept to a minimum.

Coding on the 2600 is definitely different than on my C= systems. Right now I'm using 4 bytes to store the scores, then 14 on the stack as temporary storage when I draw them. I'll redo it by using 8 bytes to store the scores(use pointers like the sprites), then nothing on the stack is needed to draw them.

Coding on the 2600 is definitely different than on my C= systems. Right now I'm using 4 bytes to store the scores, then 14 on the stack as temporary storage when I draw them. I'll redo it by using 8 bytes to store the scores(use pointers like the sprites), then nothing on the stack is needed to draw them.

 

Why do you need eight bytes "full-time" to keep the scores? Use four bytes to keep the scores (alternate with scratchpad bytes). When you want to draw the scores, fill in the scratchpad bytes appropriately (assuming you're after zero-page addressing). Once you're done with the scores, you can munge the missile y positions and use three of the four scratchpad bytes to help with those (or use the scratchpad bytes for paddle readings, or whatever).

That's very true

 

Odd/even fireball usage might be tough considering the "blank scanline" between the score and top of the castles is pretty full of code, but I could find some use for them... I use a temp variable to count down the king shape, one could be assigned to that, and the last of them could be used to hold Paddle0's reading if I put 3 bytes after that for the other paddles....

 

Or I could move the score line to the bottom which would leave plenty of time to init all the high bytes for the score pointers... Rearranging code might be messy so I'll hold off on this idea for a bit.

Odd/even fireball usage might be tough considering the "blank scanline" between the score and top of the castles is pretty full of code, but I could find some use for them... I use a temp variable to count down the king shape, one could be assigned to that, and the last of them could be used to hold Paddle0's reading if I put 3 bytes after that for the other paddles....

 

Are you using two-line resolution for the scores? If so, you could afford to trash two of the pointers as soon as you'd loaded GRP0 and GRP1 for the first of them (I figure use player 0 and player 1 for the player 1 and player 3 scores; the playfield can take care of the other two).

Are you using two-line resolution for the scores? If so, you could afford to trash two of the pointers as soon as you'd loaded GRP0 and GRP1 for the first of them (I figure use player 0 and player 1 for the player 1 and player 3 scores; the playfield can take care of the other two).

The score is 1 line resolution. It's also drawn exclusively using the playfield, else I'd have to use an extra scan line or two to reposition the shields of the top players.

 

Just finished rewriting the score routine, works quite well and saved a bit of RAM. My stack is now 2 bytes

It's also drawn exclusively using the playfield, else I'd have to use an extra scan line or two to reposition the shields of the top players.

 

I'd figured you could hit both players on one line (taking advantage of their limited mobility), and that doing that might let you take care of some other 'prep' work while displaying the score digits (especially if they used 2-line resolution as is common with playfield-based digits).