Asar: Under new management - Resource & Tool Releases

I didn't check how exactly those shared routines work, but the most obvious implementations can use the label assignment syntax instead, which I believe doesn't do anything to sublabels.

pushpc
org $123456
derp:
pullpc

->

derp = $123456

<blm> zsnes users are the flatearthers of emulation

It looks like this:

Code

macro include_once(target, base, offset)
	if !<base> != 1
		!<base> = 1
		pushpc
		if read3(<offset>+$03E05C) != $FFFFFF
			<base> = read3(<offset>+$03E05C)
		else
			freecode cleaned
				<base>:
				print "    Routine: <base> inserted at $",pc
				incsrc <target>
			ORG <offset>+$03E05C
				dl <base>
		endif
		pullpc
	endif
endmacro

!Aiming = 0
macro Aiming()
	%include_once("routines/Aiming.asm", Aiming, $00)
	JSL Aiming
endmacro

I suppose I could replace the <base>: with another label assignment, but that might mess with the sublabels used in the routines themselves. Like .return or .skip which are pretty common.

Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?

If the problem is mainly related to macros, then maybe the better solution would be to fix macro-labels themselves? (Don't know if that would be any easier yet, just considering the options)
Of course that would be a behavioral change, but I kinda doubt that any patch out there actually depends on this "unintended" behavior. It might also make sense to add macro-sublabels (in case something like that doesn't exist already). For example

Code

?macrolabel:
	blah

?.macrosublabel:
	blah

Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

Agreed. Also, if any patches actually do rely on that behavior, I still think it would be better practice to fix them as they show up rather than work around and keeping a broken system.

Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?

We need to fix that ".sfc is always headerless and .smc is" issue asap

Hi, I'm a signature!
Hack Thread
Hack Testing Status: Available.
Layout by Koopster.

The issue is LM still demanding headers, nothing else.

We can work around it by telling Asar to auto-rename it, but no headered sfc files ever. The long-term goal is getting rid of the headers completely; until that's done, we want a clear indication of whether the file is headered or not.

(Prior discussion on this topic part 1 part 2)

<blm> zsnes users are the flatearthers of emulation

Yeah, and since it can be fixed by just renaming your ROM, I wouldn't really call that a real issue to begin with. Renaming the ROM probably takes just as much effort as writing a "headered" into your patch or passing some kind of new command line to Asar. A warning by Asar would probably be nice, though (assuming it doesn't already print one).

Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

Originally posted by RPG Hacker

Yeah, and since it can be fixed by just renaming your ROM, I wouldn't really call that a real issue to begin with.

The issue is that newbies don't know that.
That Lunar Magic silently adds a header (because they totally know what a headered ROM is to begin with) and asar printing a cryptic error message abour weird ROM titles.

Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?

Yeah, that's why I said "add warnings, if there are none".

Basically, when you try to use a headered sfc file, Asar should say something like
"Asar detected a header on an sfc file, which is expected to be headerless. Attempting to apply this patch may damage your ROM. It's recommended to rename the extension of your ROM to smc and try again. Proceed anyways? (y/n)"

Respectively, when you try to use an unheadered smc file, Asar should say something like
"Asar detected no header on an smc file, which is expected to be headered. Attempting to apply this patch may damage your ROM. It's recommended to rename the extension of your ROM to sfc and try again. Proceed anyways? (y/n)"

Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

Yay for bug report :D

I noticed that "freedata align" can deadlock. I don't really know the exact circumstances but apparently when graphics related stuff to the ROM before. Included test rom, according to Mirann has:

"some layer 3 changes, edited some gfx and applied dsx just now".

removing the "align" part does fix the deadlock, so I'm pretty sure that's the issue here.

Sample patch
Note that the content of the binaries is really irrelevant, just the cfg data and some pointers. Their length doesn't even really matter (except _versionflags.bin which needs to be 4 bytes long).

Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?

I will take a look at this once I have some spare time. If it's reproducible, it should be easy to catch in the debugger.

Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

Originally posted by RPG Hacker

I will take a look at this once I have some spare time. If it's reproducible, it should be easy to catch in the debugger.

While you at it, can you add pushdefine and pulldefine? I'm annoyed of having several things using the same !define name.

Code

!Define = $1234

pushdefine

!Define = $4567

pulldefine

;!Define now equals $1234 here.

Also:

Quote

- pushpc/pullpc: In case you want to put code at one place instead of two.

That needs to be more descriptive: "one place instead of two", you mean places located in the ASM file or the ROM? I assume that the opcodes and things between push and pull could be at a different area, can you show me an example?

Give thanks to RPG hacker for working on Asar.

!def = 1
...
!old := !def
!def = 42
...
!def := !old

though not having to name your backups would indeed be easier.

<blm> zsnes users are the flatearthers of emulation

Code

freecode
code:
lda.b #10	;code inserted at some freespace
sei
xba

pushpc
org $008000	;completely unrelated code, but you wanted to insert it here because you're lazy and unorganized.
	nop #2
pullpc

asl		;resume the code before the push/pull pc
ldy #$00
wdm

pushpc
freedata align	;it also lets you to use freedata/freecode
	incbin some_stuff.bin
pullpc

brk #$00
stp
bra $FF		;resume the code before the push/pull pc

It allows you to basically place orgs anywhere between your asm file, it preserves the last pc address that the patch was writting to.

Probably it has a better usage, but I fail at seeing a better way to use it besides being lazy of putting orgs at a relevant place.

Yeah, that's exactly the intended use. Stick lots of code in the same freecode, while keeping the hijacks near the jump targets.

No clue why it supports nesting.

<blm> zsnes users are the flatearthers of emulation

For the defines part, I assume the easiest way is to do this:

Code

incsrc "<relative path>"

!Define = $1234

incsrc "<relative path>"
;^restore the defines back. Must be
;the same as the first incsrc path
;for the same file. Avoid putting
;SNES code in the defines,
;its a waste of space

Give thanks to RPG hacker for working on Asar.

I've tested if the macrolabel can also screws up the "+" or "-" labels, and it did, by doing this:

On Gopher Popcorn Stew (GPS), I created a block file with this code:

Code

;This is a template block.
db $37
JMP MarioBelow : JMP MarioAbove : JMP MarioSide : JMP SpriteV
JMP SpriteH : JMP MarioCape : JMP MarioFireball : JMP TopCorner
JMP BodyInside : JMP HeadInside : JMP WallFeet : JMP WallBody

MarioBelow:
MarioAbove:
MarioSide:

TopCorner:
BodyInside:
HeadInside:
	print "plus test ",pc
	BRA +
	%MacroLabelTest()
	+
SpriteV:
SpriteH:

MarioCape:
MarioFireball:

WallFeet:
WallBody:
	RTL

And on the created routine file named MacroLabelTest.asm, I've added this code:
Code
```
+
NOP
NOP
NOP
RTL
```

Then I inserted the block into the ROM, I then run the game using bsnes plus, and breakpointed the address shown on the tooltip on Lunar Magic, after the
breakpoint have fired, I've look at the executed code using "step":

Code

90802d bra $8048     [908048] A:8024 X:0000 Y:0001 S:01e7 D:0000 DB:90 nvMXdiZc V: 24 H: 23 F:11 ;>In block code
908048 nop                    A:8024 X:0000 Y:0001 S:01e7 D:0000 DB:90 nvMXdiZc V: 24 H: 28 F:11 ;\in routine file
908049 nop                    A:8024 X:0000 Y:0001 S:01e7 D:0000 DB:90 nvMXdiZc V: 24 H: 32 F:11 ;|
90804a nop                    A:8024 X:0000 Y:0001 S:01e7 D:0000 DB:90 nvMXdiZc V: 24 H: 35 F:11 ;|
90804b rtl                    A:8024 X:0000 Y:0001 S:01e7 D:0000 DB:90 nvMXdiZc V: 24 H: 39 F:11 ;/

I noticed that the BRA jumps into the subroutine code rather than jumping to the + after %MacroLabelTest() inside the block code.

Right now, in case if other asm makers uses macros, stick to using main labels (that does not use the same main label as any of them inside the macro) until this is fixed. It literally treats as if any types of label (main labels, +/- and .sublables) exist outside the %callmacro(). I even tested by replacing all the + with screwy (main label) in both the block's and routine's while keeping the routine filename as MacroLabelTest.asm and it errors out saying screwy is redefined, even when screwy label doesn't physically exist 2+ times in the block file (outside the macro) itself.

EDIT: Feature request - can you add sublabels for macro labels that prefixed with "?"? It mentions about using "?":

Originally posted by xkas.html

Lastly, there are labels specifically for macros. They are identical to real labels, and begin with a ?
Example: ?label:

Edit: According to alcaro:

Originally posted by Alcaro on Dischord

asar macros are just copypasting the contents right into where they're called, no smarts whatsoever
exceptions: macrolabels (but they're still ugly hacks), and error messages (though they're still fairly limited)

Give thanks to RPG hacker for working on Asar.

This is entirely GPS' fault though. The first time a shared routine is called, it does something like this:

Code

JSL MacroLabelTest
pushpc
	freecode cleaned
	MacroLabelTest:
		incsrc "routines/MacroLabelTest.asm"
pullpc

It has some additional shenanigans about saving the pointer to then checking on that to prevent re-insertion. Second time forward, all it does is:

Code

MacroLabelTest = read3($xxxxxx) ; from some address

Now as you can see, the first time it adds a main label, so naturally that's gonna screw up any sort of sublabel.

Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?

One simple solution is use namespace command
it won't overwrite main label, but still can't use +/- label and can't use namespace command in sprite asm.

Originally posted by my commit

Code

macro include_once(target, base, offset)
	if !__<base>__ != 1
		!__<base>__ = 1
		pushpc
		if read3(<offset>+$03E05C) != $FFFFFF
			<base> = read3(<offset>+$03E05C)
		else
			freecode cleaned
				namespace __<base>__
				<base>:
				print "    Routine: <base> inserted at $",pc
				incsrc <target>
				namespace off
			org <offset>+$03E05C
				namespace __<base>__
				dl <base>
				namespace off
		endif
		pullpc
	endif
endmacro

asar did mentions namespace, but didn't tell its syntax or how to use it, because that was obscure on using the word "off" after the command (also what if you wanted a label named "off" but is reserved for actually turning the namespace off). I really really hope this label/sublabel/+/- that crosses over a callmacro gets fixed soon. I agree with JackTheSpades, pushing and pulllabel, have that automatically incurred when calling a macro would be a good idea.

I'm not sure about Akaginite if you were to have a ..label before the call, then a .label inside the macro would cause issues.

Give thanks to RPG hacker for working on Asar.