Name: | Asar v1.61 |
Authors: | Alcaro, Check changelog for full list |
Added: | |
Version History: | View |
Operating System: | Windows, Mac OS X, Linux |
Platforms: | SNES |
Games: | General |
Source Available: | Yes |
Featured: | Essential |
Website: | Link |
Description: | Asar is a Super Nintendo assembler based on xkas v0.06. It's the assembler used primarily on SMW Central. Asar's got a freespace finder, will ask for filenames if double clicked, can use parentheses and proper priority in math, can assemble SPC-700 and SuperFX codes, and has many, many other neat little features. The full list of features can be found in the manual. Some of the highlights in Asar v1.61:
Source code can be found on GitHub, where you can also contribute using pull requests. |
Tags: | assembler patcher |
Comments: | 63 (jump to comments) |
Rating: |
Download
530.53 KiB | 2,359 downloads
Comments (63)
>app says ver1.60
12/10
???
What's SA-1?But yeah, an alternate way of doing the same thing would be
which is what I've been using so far. I assumed it was more common than !!.
Regardless, I edited it in the 1.27 version.
So yeah, not quite sure what to do about it in the future. I think randomdude proposed reintroduing the feature, but marking it as "deprecated" and making it throw a warning.
People are aware of this and an update will probably happen soon after this one is accepted.
For now, changing the if statement on line 203 of lzx.asm to
Label:
.Label:
+
-
would mean different things, depending on if they were used inside or outside of a macro. In my opinion not an ideal solution, either. With the current implementation, the syntax is clear and means just a single thing, no matter the context (of course ?Label can't be used outside of macros, anyways, so the context doesn't matter there, but Label and #Label do the same thing, no matter where they are used).
I think one reason for this mess is that the concept of macros in xkas/Asar is kinda shaky to begin with. I personally like to think of macros as a text replacement mechanism, kinda like in C preprocessors, and that's mostly how I treat them, though in xkas and Asar, they also have traits/behaviors that are more function-like. This makes everything regarding them a bit tricky to deal with. When working with them, though, I prefer to lean more towards the "text replacement" side, which also influenced my decision here. Letting labels "leak" outside of macros by default is more "text replacement"-like, while not letting them leak outside is more "function"-like.
But backwards compatibility says that's hard or impossible to fix.
?Label
?.Label
?+
?-
for labels that should be local to the macro they're in.
#Label
for labels that are global, but don't modify the label hierarchy. All other types of labels are supposed to leak outside of macros, that's by design.
I have tried 4 times and I just can`t get it to work. It says it can`t open the file.
EDIT: I`m just stupid, I forgot to type a bit of the patch name.
This bug has been complicating some of the stuff I've worked on recently, and it'd be nice if it was fixed.
should attach .baz to foo:, not ?bar:.
This also happens on +/- symbols too, as tested on GPS.
Possibly the most annoying bug I've experienced when using GPS and PIXI. Thank god uberasm tool's library does not use that, instead it uses filename_label:
Probably, I'm not sure.
Actually, judging by test.cpp being made for Windows and Linux simultaneously (backslashes, but also including sys/stat.h), someone dropping a libasar.so in the source directory, and the empty help.sfc, there's a fair chance it doesn't.
So at least it seems like I didn't break anything that was previously working.
New features:
NOTE: Based entirely on conversion tables I got from Ladida; don't know if these conversions are actually correct. Some features may not work as intended when using those mappers (such as freedata, for example), but I can't verify this.
Bug fixes:
Notes:
Also if a tools moderator sees this, can you please moderate this version? I don't want to submit version 1.50 before version 1.40 has been approved (or denied). Thanks!
I'm late (don't regularly check the comments here). What bug is it? Maybe report it here if it still exists and needs to be fixed?
The first sentence of its description should be removed.
Kamekku, don't mislead people like that.
Use Destroyer.
niiice.
I don't really see much uses for the new functions but readfile seems cool.
New features:
turns into
for example, whereas
turns into
Bug fixes:
Notes:
It is recommend to everyone update it to avoid further issues, specially if you're using an enhancement chip in your ROM hack.