Quote:
I try to emulate this paradigm somewhat in my 6502 programming. I name each of my routines such that they begin with the name of the "class" it operates on. For example, all my player routines have names like PLAYER_Init, PLAYER_Update, PLAYER_Jump, and PLAYER_Shoot. Likewise with routines such as INPUT_Init/INPUT_Update, SOUND_Init/SOUND_Update, and so on.
This is a great idea. I'm always searching for names I can remember for my labels, and often I fail greately so I should find the routine back to know its exact name.
I keep my files more or less separed as you said. It makes things easier in the end, dealing with a huge file is just very impratical.
Quote:
The main difference between my 6502 and C++ coding styles is that member functions in C++ take an additional argument (the 'this' pointer), which I don't emulate in my 6502 coding. Instead, I make extensive use of globals due to their low overhead. In fact, I so far have never pushed any arguments onto the stack. Instead, I allocate several "temp" variables in zero page and use those for any arguments I can't pass via registers.
This is definitely the way of doing it. I don't know about the stack thing, but that's certainly not something to do with the 6502.
If there is 3 or less int agruments I pass them with A, X, Y. If there is more I pass them with Temp1-4, and if there is a pointer I pass it trough PointerL/PointerH variables. Also sometimes "globals" serves as arguments too. I like to use the carry as an output boolean.
Also if there is a few arguments that are always constant on each routine call (but different on different routine calls), a good idea is to put them as .db $xx after the jsr instruction, and modify the return adress as supposed in the routine. This saves bytes if used a couple of times.