Erik wrote:
>That's close to the idea... but with overlays you may end up sharing
>identifiers across many subroutines that are scattered throughout your code.
How about this:
Any variables declared in the main .asm file (The file which is passed directly to DASM) are global variables.
Any variables declared in any sub-files (That is, files which are INCLUDEd in the main .asm file) are local variables. These variables are inherited by any sub-sub-files (where they are effectively global variables).
For example:
In file: MAIN.ASM
Global1 EQU $80
Global2 EQU $81
Global3 EQU $82
Global4 EQU $83
include intro.asm
include initgame.asm
include vertblank.asm
include kernal.asm
include overscan.asm
include subroutines.asm
include graphics.asm
include music.asm
[EOF]
The variables Global1, Global2, &etc would be available to all include files (intro.asm, initgame.asm, &etc).
Any further variables defined within intro.asm or initgame.asm or vertblank.asm (&etc) are local variables defined only within that file and any sub-files below it.
In file: INTRO.ASM
Local1 EQU $90
Local2 EQU $91
Local3 EQU $92
Local4 EQU $93
include introinit.asm
include introvertblank.asm
include introkernal.asm
include introoverscan.asm
include intrographics.asm
include intromusic.asm
[EOF]
The variables Local1, Local2 (&etc) are defined for any code within INTRO.ASM (Though this example is hyper-modular right now) and also to introinit.asm, introvertblank.asm (&etc). And further down though as many levels as needed.
If you want to make shared variable lists available to multiple .asm files, define them in macros. This would have the same effect as your overlay. (Do we need global and local macros too or should all macros just be global?)
The only hitch is backward compatibility since all previous code assumes all variables are global. So, we add a simple command to the main .asm file:
UseLocalVariables = 1
(Or similar)
This activates local variables. Any source which does not include this command is assumed to use only global variables.
This soloution introduces very little added syntax, is backwards compatible and should be clear and straightforeward for development and debugging. It also has the nice advantage of being extremely modular, making the adaptation of someone elses's code much easier as well as the co-ordination of multiple developers on a project - Since sub-files are effectively discrete, it becomes much easier to link them together without worrying about conflicting variable names. For that matter, labels should probably be treated the same way though you'd have to be carefull about keeping routines you want to JSR/JMP to that are buried away in a subfile.
So how about allowing explicit references to a variable or label that will over-ride Global/Local definitions. For example:
lda MAIN.INTRO.Local1
jsr MAIN.INTRO.INTROKERNAL.Label1
So we can have our cake and eat it too....
Chris...
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
