Mad-Assembler (MADS)

[matosimi]

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

[flashjazzcat]

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

[tebe]

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

 

[tebe]

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

[flashjazzcat]

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.

[tebe]

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

[flashjazzcat]

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

[tebe]

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

[flashjazzcat]

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.

[flashjazzcat]

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

 

[matosimi]

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.

[matosimi]

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