Jump to content

Recommended Posts

@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:

image.png.091f4574189ba4000195ffd27652ecc2.png

 

"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:

 

image.png.80f45f93994b0ae860a5fdec03753fd2.png

 

...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.

  • Like 1
Posted (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. :D

 

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 by flashjazzcat
  • Like 1
Posted (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:

image.png.091f4574189ba4000195ffd27652ecc2.png

: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 by tebe
  • Thanks 1

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.

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

  • Like 1
  • Thanks 1
Posted (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 by flashjazzcat
Posted (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 by tebe
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.

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.

Posted (edited)

I just tried the new mads feature for me (learned yesterday) in my project and it did not finish well...

 

i switched:

image.png.f5ccd7cb8955b90e8794d874398a1135.png

to

image.png.5435c7d0cd650b0d5f6ee0e1069b968f.png

the compilation looks ok:

image.png.72e03cbca411d68e971b77f8b815d73a.png

however the binary crashed and chkxex.exe output is:

image.png.862fb173e768ff5cbea40dcfb2c468b2.png

...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:

image.png.68fa1a69047881ea807abd2a79c748e5.png

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:

image.png.88dfb2cac62b64f7cc7b6032204b8b34.png

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 by matosimi
  • 5 months later...

I would like to create a a high byte and a low byte table in MADS with REPT, but doing it this way seems not possible:

 

    .REPT 40
        .byte <#*20
    .ENDR

 

(gives me a "ERROR: Extra characters on line")

 

Anyone any idea, if there are any workarounds for this? :)

Good evening everyone,

 

I was in the process of editing some of my old code to make something better and I just stumbled onto this, is this actually normal?

 

image.png.3c31e375a07ebeafe459850b8c094dca.png

 

What was expected: 'BNE SetVolumeFadeout_a', followed by '2 DEC ZPLZS.FadingOut' instructions

What was gotten: '2 DEC ZPLZS.FadingOut', with the expected BNE created from the SNE missing entirely.

 

Of course this is not a big deal, maybe I used the incorrect syntax, but I thought it would not hurt asking here just in case.

Assembled using MADS 2.1.7 on Linux.

 sne:  :2  dec ZPLZS.FadingOut

there should be penalties for such things

 

[whitespaces]label:

 

 sne:

it gets recognized as a label

 

You complicate simple things, what hinders you from this effective simplicity?

         bne SetVolumeFadeOut_a
         :2 dec ZPLZS.FadingOut

SetVolumeFadeOut_a

 

Edited by tebe
  • Like 2
  • Thanks 1
5 hours ago, tebe said:
 sne:  :2  dec ZPLZS.FadingOut

there should be penalties for such things

 

[whitespaces]label:

 

 sne:

it gets recognized as a label

 

You complicate simple things, what hinders you from this effective simplicity?

         bne SetVolumeFadeOut_a
         :2 dec ZPLZS.FadingOut

SetVolumeFadeOut_a

 

No problem, that makes sense now.

Thank you!

I am trying to assemble different program versions from the same source. The different version uses different graphics store in different files. If there a way to have a parameter somehow in the file name of an "INS/ICL" statement? Something like...

 

.macro m_test

ins "Example-Data-"+:1+".bin"

.endm

1 hour ago, JAC! said:

Yes, that is what I do today, but I thought maybe there is something more generic so the names or parts thereof can be passed from the command line/via -d:.

Macro trickery...

 

    .macro my_ins " "
    ins ":2:6.:4"
    .endm
    
    my_ins "robots" "dat" <:BANANA

 

And pass on the command line: -d:BANANA=200

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...