matosimi Posted June 3 Share Posted June 3 @flashjazzcat I am experiencing kind of similar issues with the scopes for a long time (more than 10 years), but I am using some workarounds here and there. The most surprising issue is when I am incorporating some g2f into my game inside a .local like here with the fk_title.g2f: portb equ $d301 org $2000\ mva #$ff portb\ rts\ ini $2000 org $9000 jsr g2f.main jmp * run $9000 .local g2f icl "fk_title_altered.asm" .endl -> fk_title_local.asm G2F picture is simply saved as ASM Assembler File ... in fact several files, one of them is fk_title.asm. I create an altered copy where I move init block outside into my main code and I also remove the "run" command. when I try to compile code above, I get an error: mva #@dmactl(standard|dma|lineX1|players|missiles) dmactl ;set new screen width fk_title_altered.asm (291) ERROR: Undeclared label STANDARD (BANK=0) Writing listing file... This is the way how I fix it: ;mva #@dmactl(standard|dma|lineX1|players|missiles) dmactl ;set new screen width mva #scr40 dmactl No idea why it does not it work out of the box. also in if the color fade is in use, there is another instance of weirdness in fk_title.fad: "fade" is the name of the .local at the beginning of the file... and I have to put there a new label like "xx" just after the .local definition: ...and replace jmp :fade with jmp fade.xx .local FADE_OUT ldx <fade ldy >fade jmp fade.xx ;fix You can try on your own: fk_title_local.zip G2F is quite widely used, and I often use several G2F pictures in my projects, I have to put each of them in separate .local scope...together with these fixes, it is quite surprising that no one else has reported these issues. I also have issues with my own macros called within another macros within some locals... so the labels within macros are reported as unknown. In those cases I unroll the deepest macro level to overcome the issue. Unfortunately I cannot create simple example, because it always pops up quite later when my project gets bigger and more complex... throughout the years I could not find the exact moment when that starts to happen... ...but at least I know how to overcome it. 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 3 Share Posted June 3 (edited) 1 hour ago, matosimi said: I have to put each of them in separate .local scope...together with these fixes, it is quite surprising that no one else has reported these issues. I guess we've strayed into some uncharted territory, perhaps. Likewise, maybe not too many people are attempting to use LOCALs for encapsulation in huge banked cartridge applications. I'm looking at CA65 to see if it might do what I need it to, but honestly: moving a huge project heavily bound to MADS to a different compiler wouldn't be my first choice. However, CA65's relocatable format might suit my needs for another large project (I've requested for some years the capability to produce multiple reloc blocks using MADS' proprietary relocatable format, but that question now tends to elicit no response at all, so I have given up asking). 1 hour ago, matosimi said: I also have issues with my own macros called within another macros within some locals... The only real issue I have with macros is that the assembler insists on reporting assembly-time errors in macro calls with reference to the place in which the macro is defined, rather than where it is called (and yes, it makes sense why it does that, but it's rarely helpful as a means of locating the error). Thanks for your comments and examples, anyway. EDIT: CA65 looks to be a non-starter for a number of reasons. Edited June 3 by flashjazzcat 1 Quote Link to comment Share on other sites More sharing options...
tebe Posted June 3 Share Posted June 3 1 hour ago, matosimi said: mva #@dmactl(standard|dma|lineX1|players|missiles) dmactl .enum @dmactl blank = %00 narrow = %01 standard= %10 wide = %11 missiles= %100 players = %1000 lineX1 = %10000 lineX2 = %00000 dma = %100000 .ende Quote Link to comment Share on other sites More sharing options...
tebe Posted June 3 Share Posted June 3 (edited) 1 hour ago, matosimi said: also in if the color fade is in use, there is another instance of weirdness in fk_title.fad: :FADE refers to the namespace in the main block, outside the LOCAL areas if you put FADE in the LOCAL block i.e. you have hidden it you must then specify the full path LOCAL.FADE colbak = 712 org $2000 fade lda #$26 <------------- sta colbak | jmp * | | .local temp | | fade lda #$c6 | sta colbak | jmp * | | .local test | | jmp :fade -------------- fade lda #$86 sta colbak jmp * .endl .endl run temp.test Edited June 3 by tebe 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 3 Share Posted June 3 Since the LOCAL scope can't span multiple banks, the best I can do is to at least have the variables in the same namespace by manipulating the bank number around the declarations. This will mean access to said variables from outside of the 'fs' scope will have to be prefixed with ':' as well as the scope qualifier (since they're no longer in bank 0 and are thus no longer global), but it's either that or manually adding prefixes to all the labels: icl 'macros.inc' opt h- opt f+ org $80 lmb #0 Bank .ds 1 BankTemp .ds 1 BankTemp2 .ds 1 CurrBank .ds 1 BaseBank equ 0 LongJSR equ $BF9D org $2000 FileHandle ; global scope .word 0 lmb #1 .local fs ; RAM (variables) FileHandle .word 0 ; part of 'fs' scope .endl lmb #2 .proc Main lda FileHandle ; access global variable lda :fs.FileHandle ; access variable in fs namespace ljsr :fs.Open ; call procedure in fs namespace rts .endp .proc InitialiseCart .endp .proc Start .endp NextBank lmb #1 org $a000 .local fs ljsr :fs2.Setup ; different scope for different bank ljsr :fs2.Rename .proc Open lda FileHandle ; in fs namespace rts .endp .endl NextBank lmb #2 .local fs2 .proc Setup lda FileHandle ; fs namespace ljsr :fs.Open rts .endp .proc Rename lda FileHandle rts .endp .endl Certainly a better option than leaving my clothes in a neat pile on the beach and quietly walking into the sea. Quote Link to comment Share on other sites More sharing options...
tebe Posted June 3 Share Posted June 3 6 minutes ago, flashjazzcat said: Since the LOCAL scope can't span multiple banks, the best I can do is to at least have the variables in the same namespace by manipulating the bank number around the declarations. This will mean access to said variables from outside of the 'fs' scope will have to be prefixed with ':' as well as the scope org $2000 nop .local fs fade0 .endl lmb #1 .local +fs fade1 .endl lmb #2 .local +fs fade2 .endl rmb .print =fs.fade0 .print =fs.fade1 .print =fs.fade2 .LOCAL +LOCAL_NAME 1 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 3 Share Posted June 3 (edited) 9 minutes ago, tebe said: org $2000 nop .local fs fade0 .endl lmb #1 .local +fs fade1 .endl lmb #2 .local +fs fade2 .endl rmb .print =fs.fade0 .print =fs.fade1 .print =fs.fade2 .LOCAL +LOCAL_NAME Wow - perfect. I see now what you mean by 'additive' (this wasn't apparent from the documentation). I really appreciate the example - thank you. Edited June 3 by flashjazzcat Quote Link to comment Share on other sites More sharing options...
tebe Posted June 3 Share Posted June 3 (edited) 25 minutes ago, flashjazzcat said: I see now what you mean by 'additive' The '+' sign is needed when you are in a different namespace, if it is the same namespace and .LOCAL have the same names then they merge automatically .local temp .local fs fade0 .endl .endl .local sample .local +temp.fs fade1 .endl .endl LMB>0 implicitly creates a new namespace, banks >0 only have access to bank =0 (global namespace) Edited June 3 by tebe Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 3 Share Posted June 3 8 minutes ago, tebe said: The '+' sign is needed when you are in a different namespace, if it is the same namespace and .LOCAL have the same names then they merge automatically LMB>0 implicitly creates a new namespace OK - understood. Thanks again. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted June 3 Share Posted June 3 It seems the English MADS documentation here has become a little out of date, so I'll use this one from now on (it includes a description of the additive LOCALs, etc). 1 Quote Link to comment Share on other sites More sharing options...
matosimi Posted June 3 Share Posted June 3 5 hours ago, tebe said: .enum @dmactl blank = %00 narrow = %01 standard= %10 wide = %11 missiles= %100 players = %1000 lineX1 = %10000 lineX2 = %00000 dma = %100000 .ende Yes, but this has already been defined at the beginning of fk_title.h which is included at the beginning of fk_title.asm. Quote Link to comment Share on other sites More sharing options...
matosimi Posted June 4 Share Posted June 4 (edited) I just tried the new mads feature for me (learned yesterday) in my project and it did not finish well... i switched: to the compilation looks ok: however the binary crashed and chkxex.exe output is: ...the version with "org" compiles ok and chkxex.exe also works and the binary works. there is an issue within the xex blocks...these are the first 3 blocks of the "org" version: block 002 is basically the part in the screenshots above.. where the get_byte is stored at $9ffe, but assembled at $cb ... and relocated into ZP later. the output binary when .local player,player.playerzp is used has following couple bytes at the beginning: so it looks like block 001 starts from $9b00 to $00d4 ... and that is definitely incorrect. -> reason also for the runtime error in the chkxex.exe. I tried switch from ORG -> .LOCAL name,address to see if the blocks 001 and 002 get merged into single block. Edited June 4 by matosimi Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.