Language…
17 users online:  Ahrion,  Alex,  AmperSam, Apple Boy,  DeppySlide,  Fyre150, HammerBrother, Heitor Porfirio, LucasRCD,  Ringo, RollingRigatonis, SAMYR DUTRA ARAUJO, sholmes, ShoopDaWhoop, signature_steve, tired_ideabox, xhsdf - Guests: 143 - Bots: 220
Users: 65,554 (2,174 active)
Latest user: johnmario

Asar 1.90: the "Better Late Than Never" update

ToolResource Release

Hello and welcome to another Asar C3 thread! Dubbed the "Better Late Than Never" Update, Asar 1.90 has been in development for a bit over 3 years (and we were saying "we should probably release 1.90 soon" like 2.5 years ago already... hence the title), but well, it's here now! This release is brought to you primarily by myself (formerly known as randomdude999, in case that name rings any bells),  RPG Hacker, and p4plus2, with minor contributions from Sir Walrus (also known as Alcaro),  Atari2.0, and spooonsss.

Download link

The most important new features are:

  • for loops have been added, which are technically pretty much the same as while loops, but more convenient to type. The syntax is:
    Code
    for i = 123..456
      ; code here...
      db !i
    endfor
    ; is equivalent to this while loop:
    !i = 123
    while !i < 456
      db !i
      !i #= !i+1
    endwhile
  • spcblock is a new, more flexible replacement for arch spc700-inline.
  • You can make fancier error/warning messages using the warn and error commands.
  • "static" labels (that is, labels that are defined with the label = $123456 syntax) can now be used in if conditions (and elseif and while too obviously).
  • freecode can now be used in HiROM, ExHiROM, and ExLoROM mappers.
  • Namespaces can now be saved and restored with the pushns and pullns commands.
  • New pc() and realbase() math functions.
  • The syntax of some commands has been changed to be less ambiguous: Variadic macro arguments now use <...[math]>. Incbin with a range now looks like incbin file:123..456. The warnpc command has been deprecated in favor of assert pc() <= $xxxxxx, which is more explicit about what the exact condition is (and is more flexible in general). while loops should now be ended with endwhile instead of endif.

There's also lots of bug fixes and some more minor additions, see the changelog for details. Everything should also be documented in the manual.

However, during development of Asar 1.9, we have also been working on Asar 2.0, which removes a lot of old cruft that has accumulated over the years and currently only exists for backwards compatibility. This makes it a lot easier for us to add new features (quite a few of which have already been added, like allowing spaces in math expressions, and better error messages for invalid instructions). Everything that will be removed in 2.0 will throw deprecation warnings in 1.90. Most of these should be pretty unlikely to occur in any existing patch, or trivial to fix (renaming old deprecated aliases, or just deleting commands that did nothing). See the changelog linked above for the full list of deprecations.

The deprecation that could most likely cause trouble is the rep command being deprecated (due to it conflicting with the rep #$xx assembly instruction, which makes asar's parser hackier and generally didn't sit right with me). To that end, the new for loops are generally a satisfactory replacement: rep 123 : nop can be replaced with for i = 0..123 : nop : endfor. In some cases you can also use the repeating pseudo-instructions (i.e. nop #123), or the fill command.

We won't be releasing Asar 2.0 until at least the next C3 (though it'll probably take even longer if i'm being honest). So if you have Opinions about the current deprecations, feel free to voice them (either here or in Asar's tool thread after C3 ends) and we'll consider them. We might then make an Asar 1.91 that deprecates more or less features depending on feedback.
Hi. Nice addition of the command. Reminds me of something seen in PIXI, except there, it was 'if'.
I've been waiting for this for quite a while ever since I was told about some things potentially breaking in the long run. However, I delayed implementation of all of this into AddmusicK because of a bug with the very first thing that was requested of me... namely, by using norom. It required me to switch to the 65816 side. I decided that would have been ugly for me to implement, so I held off on doing it, especially since I wanted nothing to do with commit-level dependencies.

I have decided I will not have AddmusicK 1.0.10 be the first version to jump to Asar 1.9, citing the desire to have it fix regressions moreso than keeping up with the latest and greatest. Once that's finalized (via being moderated), then I can consider going through with the upgrade. Plus, I noticed you just submitted Asar 1.90. Well... AddmusicK 1.0.10 has been on standby for four months, so it may be a bit.
Thanks to everyone who's been working on this; I've been watching all the hard work and flurry of activity getting this ready, and I, for one, welcome our new 1.90 overlords.
I love reading release notes and lists of new features even though they most likely won't concern me. #tb{:>} Asar is like the backbone of most of the vital tools we host, and it's nice to see it still being in development and handled so professionally. Kudos on the release, and all the best for 2.0 development!

Originally posted by trillian
The deprecation that could most likely cause trouble is the rep command being deprecated (due to it conflicting with the rep #$xx assembly instruction, which makes asar's parser hackier and generally didn't sit right with me). To that end, the new for loops are generally a satisfactory replacement: rep 123 : nop can be replaced with for i = 0..123 : nop : endfor. In some cases you can also use the repeating pseudo-instructions (i.e. nop #123), or the fill command.

Uneducated opinion: if it's just the naming conflict that's causing trouble, wouldn't renaming it to something like repeat be a solution?


 
Originally posted by wye
Uneducated opinion: if it's just the naming conflict that's causing trouble, wouldn't renaming it to something like repeat be a solution?

technically yes, but i don't really like the way it works to be honest. rep 123 : nop : nop writes out 124 nops, not 246, so i think the for loop is just more explicit about what it does

but i guess if enough people liked rep and dislike for we could bring it back, yeah
The big problem with `rep` is that it's not obvious what its semantics are wrt other blocks. What `rep 2 : if !x` does is not very well-defined. Simply removing it in favour of a more straightforward command is a far better alternative to having a command that does something nonsensical if you use it in a context that it doesn't expect, even if it comes at a cost of slightly more verbose code.
Congrats on the release!

Can't wait to try it out. :)
lol the incbin changes mess up my stuff... BUT it looks so much sexier with that new syntax. I hated using - for ranges and hated even more not being able to use $ for hex.

Looking forward to use this new version and adapt my patches to use it. Congrats on the release!
Looks like my slot just opened up, since AddmusicK 1.0.10 was finalized! So here's what I'll do. I will focus on getting AddmusicK 1.0.11 up and running through Asar 1.90. AddmusicK was initially unfrozen by me versioning-wise (though other contributions completed the process), and I see the importance of ensuring that it doesn't become refrozen, as I am effectively in a leader-ish position maintenance-wise (well, at least for running the repository).

I noticed you retired the rep command in favor of something else. AddmusicK used the db command instead of an opcode, so it just so happens that I can instead take advantage of padbyte and pad, as a quick replacement example. I'll be checking for any other deprecation warnings (some of which could have been caused by my own additions).
nice, 2 questions:

This new version allows you to know the size of the inserted bytes WITH padding? because V1.81 gives you the value without padding only.

This version allows more than 127 freecodes/freespace/freedata?

------------------------------------------------------

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources
Originally posted by anonimzwx
This new version allows you to know the size of the inserted bytes WITH padding? because V1.81 gives you the value without padding only.

i don't think we have such a feature. i'm not sure what exactly you mean though. if by "padding" you mean the way asar pads the rom with zeros if you org past the end of the rom, you can calculate the amount of padding just from the output rom's size. so i'm not sure how this number would be helpful.
Originally posted by anonimzwx
This version allows more than 127 freecodes/freespace/freedata?

that's in asar 2.0 only.
Originally posted by trillian

i don't think we have such a feature. i'm not sure what exactly you mean though. if by "padding" you mean the way asar pads the rom with zeros if you org past the end of the rom, you can calculate the amount of padding just from the output rom's size. so i'm not sure how this number would be helpful.

Well i was doing a tool that uses asar and i wanted that the tool gave me the amount of bytes used by the tool at the end, but when i do that, the amount of bytes inserted on the rom is different than the amount of data that asar said, i asked why on asar channel in sneslab discord server, and they said me that asar adds a bit of padding to the patches and they said me that is not possible to know the amount of padding added in version 1.81.

------------------------------------------------------

Youtube
Twitter
SMWControlLibX GitHub
My Discord Server
Snestorage where you can download my resources
Originally posted by anonimzwx
Well i was doing a tool that uses asar and i wanted that the tool gave me the amount of bytes used by the tool at the end, but when i do that, the amount of bytes inserted on the rom is different than the amount of data that asar said, i asked why on asar channel in sneslab discord server, and they said me that asar adds a bit of padding to the patches and they said me that is not possible to know the amount of padding added in version 1.81.

oh, you mean the padding at the end of freespaces? this padding shouldn't be added to freespaces at all in 1.90.

ToolResource Release