Asar: Under new management - Resource & Tool Releases

That would be fairly stupid, actually =/
It's understandable that you wouldn't need the complete version, but there's always the possibility of having to patch a patch that someone else made, and uses some of the more complex versions.
Then you would have to download the complete version and suddenly you have two of them :V

As Sind said, the disadvantages of extra confusion outweighs any performance benefits. Assembling patches takes very little time to begin with, most of the time is spent in LM/YY-CHR/Notepad/whatever.

...speaking of confusion, I've been considering removing all special meaning from stdlib.asm. Its intended use was a list of labels and defines that can be used in all codes; I still like that idea, but I don't think we'd lose too much if we replaced that with an incsrc in all patches. Additionally, some users may not want it.
However, in reality, the only thing it's used for is various settings. This has two disadvantages: Updating may get annoying if I edit the list of settings, and it may create confusion if a patch is made for one stdlib and is assembled with another.
The settings, and my disposal plans, are the following:

warnings	Lock to "always on", except in emulation mode.
sandbox	Command line switch.
labelopt	Merge with emulation mode.
autocolon	Split off to a separate tool.
fastrom	Add the command "fastrom", to be used inside the patches.
aborterrors	Lock to 1, make errors only print in one of the three passes.
arch	Add the command "arch", to be used inside the patches.
autoexpand	Lock to on.
emulxkas	Make Asar check its own filename. xkas.exe = emulation mode, asar.exe or anything else = native mode.
checksum	Lock to on, unless arch spc700-raw is used in the patch.
werror	Lock to off. Warnings are pretty rare anyways.
romtitle	Lock to off. If LM accepts a ROM, I'm pretty sure Asar will as well.

Does anyone have any arguments in favor of keeping it? If no, I'll remove it in a few days.

<blm> zsnes users are the flatearthers of emulation

What if we made most of the configuration into command line switches? That would avoid any stdlib.asm compatibility issues and just turn into an Asar end-user issue (as long as the projects don't use some big long batch, but even then the user can just edit the batch to fix any command line changes...)

I haven't actually used Asar since it still seems to be in its stage of growth, but things like -werror are very helpful to me when I use the GNU toolchain.

Emulxkas seems like it would be better done as a command line option anyway, rather than renaming to xkas.exe! And if you have Linux compatibility [not sure on this one as I haven't used it] it wouldn't even have a .exe ending....

Yeah, I guess I could keep them as command line options. (I still want to remove some of them, though.)

Linux compatibility has always existed. The CLI frontend uses only the standard C and C++ libraries and works fine on Linux, and I think the DLL frontend could become a .so if I found the correct G++ flags. (However, the CLR DLL won't work for that, since it's filled with Microsoft extensions.)

However, I'm not going to move emulxkas to the command line, since that'd destroy the entire point of it. Several tools use system("xkas tmpasm.asm tmpasm.bin > temp.log"); (sometimes with filenames edited), and I want Asar to be a 100% compatible replacement for those too.
...though you do have a point with the Linux argument. Stripping off the directory name and extension and checking only the base name is a good idea.

Either way, here's a new one.

pushpc no longer throws idiotic errors everywhere.
asar-cli.dll has been renamed to asar-clr.dll, and its contents has been moved to namespace AsarCLR instead of asarcli. This will require your tools to be edited, but it shouldn't take longer than a minute or two. (I don't think anything except ASMPad uses it anyways.)
asar-clr.dll can now return errors/warnings/etc without crashes.
Removed AsarCLR::Asar::unmanageerrors() from asar-clr.dll. It's an internally used function that shouldn't be exported.
Killed off a bunch of memory leaks in asar-clr.dll.
Added a function to the DLLs to view the table data.
STA $12,y warnings now print only once.
asar_resolvedefines no longer throws exceptions outside the DLL. I don't know what happens if an exception leaves a DLL, but I don't think it'd lead to anything good.
New setting: werror. It makes warnings emit errors if encountered. (Yes, I posted it in the table above, I forgot how new it was.)
Squashed a memory leak bug where the math module allocates some memory without freeing it when the DLL is unloaded.

I plan on releasing 1.0 later this year. When I do, full backwards compatibility with everything made for older Asar versions (with the exception of xkas emulation mode (it's only provided to ease the transition, I want it to be made obsolute after a while)) will be a priority, so it should be possible to start using Asar in a larger scale around here.

<blm> zsnes users are the flatearthers of emulation

Best would be for the authors of the tools to use something like $ASSEMBLER tempasm.asm tempasm.bin (or %ASSEMBLER%)

and then the user sets the ASSEMBLER env variable to set what assembler he's using. But eh, that'd require a lot of organized work with tools... Which honestly should be a lot more organized anyway. Wish there was more of an open source attitude with them so that we could make everything be compatible with the many options available for each type of tool.

That already exists.

Originally posted by Iceguy

That already exists.

Not exactly what I'm referring to, though. Why do we need a wrapper when the OS supports this natively? That seems more of a convenience thing than something that is used natively by the tools [For example, how can I make BTSD use that?]

There's a reason that things like Makefiles usually use $(CC) instead of gcc. But we digress to a point where we are completely off top on this thread...

Originally posted by monadic

For example, how can I make BTSD use that?

Make a fake executable "xkas.exe" (a bat, since btsd doesn't run on *nix so much) that calls python to run that script. Assuming BTSD leaves the original source of the block intact, it should assemble just fine, even still allowing for different assemblers and for BTSD to catch errors (though it might be better to change it a little, I believe it prints some kind of confirmation message that will trip BTSD's error recognition code even if there is no error, though I can't remember for sure).

Using an environment variable would not be as powerful, because you would either not be able to use multiple types of assemblers in the same go (if it's set by users) or the entire idea of using an environment variable would be useless (if it just got read by the tool similarly to how the wrapper does it).

Originally posted by HuFlungDu

Make a fake executable "xkas.exe" (a bat, since btsd doesn't run on *nix so much)

Originally posted by contents of eee.exe

echo 123456789
pause

Originally posted by results of executing it, translated from Swedish

C:\DOCUME~1\blah\eee.exe
NTVDM CPU discovered an illegal instruction.
CS:07ab IP:0100 OP:65 63 68 6f 20 Pick Close to close the program.

When pressing Ignore, I got two more of those, and then it closed. I'm pretty confident that this method isn't working.
I can execute it if I call it eee.exe.bat and type "eee.exe" in the command line, but that looks pretty horrible.

Quote

Assuming BTSD leaves the original source of the block intact,

It makes a copy of it called tmpasm.asm, with header lorom org $008000 (use of : vs \n unknown) prepended, and doesn't tell xkas the original filename.
However, it does leave the original ASM file unchanged.
Is this intact enough for your needs?

<blm> zsnes users are the flatearthers of emulation

Sadly, no. The problem is that it needs the first line to be one of the calls for it to work correctly, though I could easily make a separate version that would play nice with BTSD if it was something people actually wanted.

However, the first part you posted there is disheartening, I have my doubts it will work (sometimes calling bats as executables works, other times not so much). Obvious way then would be to make it act exactly like a bat, but still be a compiled exe file (c I guess), but that's a bit much really.

There's a bunch of .bat->.exe converters floating around, but all I've seen (aka all that have been submitted to our tool section) print funny banners that'll trip BTSD's error filters (unless you pay for them, which isn't really what we want).

But yeah, a C tool that calls a batch file is trivial, especially since the filenames are already known (tmpasm.asm and temp.bin (temp.bin is unheadered)). Here you go (source code). Call the Python-calling batch file assemble.bat and put it in the same folder as BTSD and this tool (rename this tool to xkas.exe, I renamed it in the filebin to not confuse people who may think I made the world's tiniest assembler).

Also last chance if anyone wants stdlib.asm to have any special meaning. If not, I'll start the removal process tomorrow and cram in a bunch of labels from all.log into it for the next version.

<blm> zsnes users are the flatearthers of emulation

Eh, looks like I would still need to write a very new wrapper that is very specific to BTSD (Namely the fact that the syntax for lorom changes between assemblers, and also that different assemblers use different syntax for inserting bytes, and BTSD adds a 'db "ENDOFFILE"' to all of it's blocks). I doubt this is worth it, especially with a new version coming soon.

You may want to detect the Spritetool and Tessera headers as well. The spritetool header is char xkas_org_line[] = "lorom\x0D\x0Aorg $008000\x0D\x0A";, and I'm too lazy to check Tessera.

And here's the one I think will be the final one. I'll submit it in a few weeks, unless I get any new ideas. I will also attempt to keep the API stable.

If an error occurs, it now prints the buggy block, if relevant.
Dropped autocolon, since it's useless and never used.
The set command has been removed, in accordance with my post earlier.
stdlib.asm has lost its special meaning.
Fixed a memory allocation mismatch.
Various changes to the DLL API.
Crappily cobbled together a hack to make Asar compatible with Sprite Tool (a file called tmpasm.bin is now considered to be headered).
Included the script I use to compile the .NET DLL, so others can inspect the horror I went through.

whee
Suggestions for additions to stdlib.asm are welcome. I just tossed in a bunch of stuff I think may be useful.

Edit: Put a few lines back where they should be, to get rid of a crash.

Edit2:

Fixed a crash bug in asar_i_reset() if the function does not create any custom functions.
Made it possible to call asar_i_patch() multiple times without calling asar_reset() between them. The errors will remain until you use asar_reset(), meaning they'll accumulate until you clear them out.

Edit3:

Renamed the DLL frontend to LIB, since DLLs only exist on Windows and dynamic libraries exist elsewhere too. No point using more Windows terminology than needed.
Various edits to the library frontends. asar_i_* has been renamed to asar_*, and errors and warnings now tell where they're called from, if found inside a macro. I know that this violates the backwards compatibility promise, but the only user of the library frontends is ASMPad, and it's still in active development.
The command line frontend tells where problematic macros are called from.
Made my license choice explicit.

Edit4:

$xxFFFF can now safely be overwritten.
Removed garbage from some errors.

Edit5:

Asar no longer crashes if it tries to open a file of less than 512 bytes if it thinks it's headered. This fixes Sprite Tool compatibility.
Updated libsmw and libstr to the latest versions from AlcaRobot. (I don't think any of the improvements are used in Asar.)

Edit6:

gah, spritetool compatibility was still broken. Looks like tmpasm.bin is unheadered after all. Repaired again.

<blm> zsnes users are the flatearthers of emulation

I'm tired of editing that post six times, so I'll just bump this one.

Removed #ifdef ALCAROBOT (sandbox mode) from a few source files.
Replaced the math library with a more powerful one. It's boring to cram in label support into those math libraries... good thing I made them so I know how they work.
New command: math. See changes.txt for details.
Homemade functions can now safely replace builtin ones, to compensate for the possibility that new builtin functions may collide with ones in your codes.
Added a few new functions: log, log10, and log2.
Fixed a few more memory leaks.

Additionally, while I'm still not sure why some users prefer seeing the tools in the tool section, it's now there. Merry Christmas.
Yes SWR, I still hate you.

Edit: Oh, and the file bin links scattered everywhere in this thread are now outdated.

Edit2: Whoops.

Restored db 1+'a' support to the math parser. I wonder if anyone would've noticed it went missing if I didn't list it.
Merged the dupe descriptions for the fastrom command in the documentation.
Added special meaning to the define !assembler: Its value is always "asar", even if you assign something else to it. Intended usage: !assembler = xkas : %freespace_!assembler(), where %freespace_xkas() requires the user to set freespace and %freespace_asar() contains a freecode.
Fixed sublabel support, which the new math engine broke as well.

<blm> zsnes users are the flatearthers of emulation

I would like to incorporate asar into my new Mac assembler shell, Maxkas. It seems that asar is a "cleaner," more modern, and possibly more efficient assembler, and I'd like your permission to use it in my GUI, on top of xkas. Though I admit, it makes the name Maxkas a little silly, maybe Masar? Meh, I'll figure it out.

EDIT: Hmm, I seem to be having some issues compiling it on Mac. Any guidelines? I seem to be getting a bunch of linking errors, no matter how much tweaking I do...

EDIT2: Nevermind, I think I got it working under OS X. I have a few questions, though. First of all, why don't you #include interface-cli in main.cpp? You already have the #ifdef set up so it won't do anything unless INTERFACE_CLI is defined. Also, what is scapegoat.hpp? I haven't really looked enough in-depth, but it looks to me like a JSON/serialization library? What's that used for?

Quote

I'd like your permission to use it in my GUI, on top of xkas.

Running Asar on top of xkas sounds tricky, and it doesn't seem to make much sense either.
If you mean running it on top of Maxkas, LGPL says I'm not allowed to stop you, and it sounds like an interesting project. Do whatever you want.

Quote

Hmm, I seem to be having some issues compiling it on Mac. Any guidelines? I seem to be getting a bunch of linking errors, no matter how much tweaking I do...

I can't be sure without seeing the error messages, but I'd guess you either forgot defining INTERFACE_CLI (or INTERFACE_LIB, if you prefer .dylib over separate executables), or only compiled main.cpp (it should be *.cpp).

Quote

why don't you #include interface-cli in main.cpp?

I prefer not having to edit main.cpp if I make a new frontend. I already send *.cpp to the compiler anyways, so I gain nothing from making the files include each other more than needed.

Quote

what is scapegoat.hpp? I haven't really looked enough in-depth, but it looks to me like a JSON/serialization library? What's that used for?

That guess is incorrect. I have no use for JSON and serialization in this assembler (though I do have libraries for that in other projects).
scapegoat.hpp defines a structure that can map strings to arbitrary data, like std::map. It contains defines, labels, and some other funny stuff.

Edit: Oh, and the name of this tool is Asar, not asar.

<blm> zsnes users are the flatearthers of emulation

Originally posted by Alcaro

Running Asar on top of xkas sounds tricky, and it doesn't seem to make much sense either.
If you mean running it on top of Maxkas, LGPL says I'm not allowed to stop you, and it sounds like an interesting project. Do whatever you want.

Awesome, thanks. And by "on top of," I meant "as well as." So yeah, it has been done.

Quote

I can't be sure without seeing the error messages, but I'd guess you either forgot defining INTERFACE_CLI (or INTERFACE_LIB, if you prefer .dylib over separate executables), or only compiled main.cpp (it should be *.cpp).

Yeah, thanks for that. Got it working now.

Quote

That guess is incorrect. I have no use for JSON and serialization in this assembler (though I do have libraries for that in other projects).
scapegoat.hpp defines a structure that can map strings to arbitrary data, like std::map. It contains defines, labels, and some other funny stuff.

Ah, I see. It has some JSON stuff in there (at least it looks like it) so I was a bit confused.

Quote

Edit: Oh, and the name of this tool is Asar, not asar.

Got it, thanks. Current version of Maxkas has it as asar, but I'll fix it in the next update.

New command: warn. See changes.txt for details.
The math parser now accepts strings like 0.5 if you turn off rounding. It'll break if rounding is on, since that wouldn't make any sense. It'll round down as soon as it's returned from the math parser; db 0.9 is the same as db 0, but db 0.4*0.4 is the same as db 1.
assert can now take another parameter. If this is given, it is printed in the error message. (All error-generating blocks are printed, which makes these messages appear twice, but I don't care.)
Restored documentation of the functions to changes.txt. I forgot their existence when I removed stdlib.asm.
Asar now attempts to check if the ROM title looks sane before applying a patch.
Added Linux/OSX support to asardll.cpp. I haven't been able to test on OSX, but the only difference from Linux is a file extension, so I'm pretty sure it will work.
Added asar_math() to the library frontend. I didn't test it very much, though.
Fixed crashes if a macro is called with wrong number of arguments.
Fixed silent errors when using LDA Label,y if Label is in another bank.
Now prints a message if patching is successful. However, calling it from the command line makes it remain silent, unless you add -verbose.

Yay, links that break as soon as I upload a new version. Luckily, the update rate seems to have dropped.

<blm> zsnes users are the flatearthers of emulation

I wish there was a command or something that targets the freespace to the start of a new bank. That way, it's easier for patches like the VWF dialogues to keep track of how much bytes are used.

Melba: The Peach Saga - basic concept of 'hub' world finished

The Shrine Policy - Always think you're better than me

Asar refuses to cross bank borders (incbin'ing a 32768 byte file always claims an entire bank, and 32769 makes it throw errors), and honestly I can't see any reason why misalignment would matter in other situations.

<blm> zsnes users are the flatearthers of emulation