Language…
18 users online:  Ahrion, Anas, anonimzwx, autisticsceptile1993, Batata Douce, codfish1002, Foxy_9000_, Hammerer, LuigiTron, magianegra21, Mario's GameBase, Maw, NewPointless, playagmes169, ppp9q, sinseiga, Sokobansolver, The_Uber_Camper - Guests: 264 - Bots: 360
Users: 64,795 (2,376 active)
Latest user: mathew

Asar 1.71

Tool

  • Pages:
  • 1
  • 2
Asar 1.70 has been released! This release doesn't have a lot of new features, but still some cool stuff.

New features:
  • The fullsa1rom mapper now supports automatic freespace searching!
  • incbin ranges can now use math as an alternative to unprefixed hex. To use this, surround the math with parentheses. For example, incbin file:(4+2)-($F+$10).

Bugfixes:
  • Fixed like 5 crashes, most of which a normal user is unlikely to notice.
  • Fixed a bug that slowed Asar down by about 50%, causing an approximate 2x speedup.
  • Values greater than $80000000 should be handled better overall.
  • Fixed a freespace leak when using prot.

1.71 bugfixes:
  • Fixed sfxrom!
  • check bankcross off now doesn't mess up your PC (i.e. no more forced fastrom addressing).
  • Using the error command doesn't print the error twice. Most warnings now print the line that caused them.

More detailed changelog here.
Download here.
how bout you fix sfxrom Thanks for the update. I don't think I have use for those features, but the prot bugfix was overdue.
Quote
Fixed a freespace leak when using prot.


I'm sorta curious, how popular is prot command in the patches on SMW Central. Should I expect 2MB of freespace leaks ;)?
Originally posted by xfix
I'm sorta curious, how popular is prot command in the patches on SMW Central. Should I expect 2MB of freespace leaks ;)?

There are some pretty popular patches that do use it - but the leak only happened rarely.
Originally posted by Erik
how bout you fix sfxrom

I would if someone actually knew what was wrong with it - apparently the only one who does know that is DiscoTheBat and he appears to be pretty dead.
Thanks for the new version!

Could you check if something about this broke the Tolerance Timer patch? I'm not sure if it's due to something I changed on my end (if I even did that), but I'm getting errors along the lines of "autoclean used in free space (jml OnJump)" and "SNES address FFFFFFFF out of bounds (org remap_rom([...])".


 


Nice update, I must say. The feature that most interested me, however, was the fullsa1rom mapper; it is good to know we can, parting from this update, put data in the 6MB+ area of the ROM.





Dream team (feed them, please):






I'd like to thank you and the others working on asar for not only finally implementing the ability to use math on the incbin offsets (something I've been wanting for a long time), but also speeding up compile time significantly! ^_^ No joke, asar 1.70 alone saved 12 seconds of compile time on my SMW disassembly.

Out of curiosity, what caused asar 1.60/1.61 to compile as slowly as it did?
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
Thanks fot these updates. Big steps in fixing issues aren't taken over night. But it's the continuous improvent, which is important and which makes the tools on this site more perfect. This being said, i'd like to thank you again for making Asar a bit more perfect. Since it's the main patching tool your effort definitely was important! #smw{:TUP:}








Thanks for the prot leak fix, I ran into trouble with that without really knowing what caused it.
Nice update and keep up the good work #tb{:]}
My Youtube channel

Currently working on:
Project C

Finished project:
Originally posted by yoshifanatic
Out of curiosity, what caused asar 1.60/1.61 to compile as slowly as it did?

Basically, Asar recalculated the absolute path of the input file (which can apparently be quite an expensive function if you call if frequently enough) for every line it assembled.

Originally posted by WhiteYoshiEgg
Could you check if something about this broke the Tolerance Timer patch? I'm not sure if it's due to something I changed on my end (if I even did that), but I'm getting errors along the lines of "autoclean used in free space (jml OnJump)" and "SNES address FFFFFFFF out of bounds (org remap_rom([...])".

Can reproduce, looking into that right now.
Math in incbin alone is a cool enough feature for me to warrant this new update, so good job on implementing that while I'm still in my productivity low.
By the way: since you added that, don't forget to also update the manual at some point to mention the fact that incbin can now use math commands and that you need to use parentheses for that. Currently, the manual still claims that only hexadecimal number literals could be used.

Originally posted by WhiteYoshiEgg
Could you check if something about this broke the Tolerance Timer patch? I'm not sure if it's due to something I changed on my end (if I even did that), but I'm getting errors along the lines of "autoclean used in free space (jml OnJump)" and "SNES address FFFFFFFF out of bounds (org remap_rom([...])".


Actually, it's possible that I wrote that patch against Asar 1.37 and never submitted the updated version, so it's possible that Asar 1.40 or later break compatibility. The reason I'm thinking this is that my "shared" code library uses a lot of tricky logic functions, some of which I had custom implementations for before eventually integrating those into Asar directly with version 1.40. I can imagine that breaking something. It's worth downloading the most recent version of that patch from my GitHub and checking if that works.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Literally had to use prot the first time yesterday to fix some bank crossing errors, glad that the feature exists in it's now unbroken form otherwise I would have probably just given up on hacking for a few months out of sheer frustration lol. Thanks for all the hard work, you guys are doing us a great service in keeping us reasonably sane!
It's definitely nice to see fullsa1rom finally getting proper support. It's a shame that SA-1 can't be used to its full potential right now. The prot fix is also more than welcome, I've had to modify several patches to get around the bug in my hack.
Like the tools here is updated so often I keep on thinking........... can I still use the old tools to make a hack or do I have to just keep updating my tools all the time because if the update fixes stuff then will something break if I keep using the old one............. IDK
Originally posted by Final Theory
can I still use the old tools to make a hack or do I have to just keep updating my tools all the time because if the update fixes stuff then will something break if I keep using the old one


Well, Asar is probably different from most other SMW hacking tools in that regard, mainly because it's just an assembler/patching utility and doesn't really come with any SMW-related functionality. Usually the worst that can happen from updating your Asar version is that some old patches may not be compatible and might need some manual adjustments to work, but cases like that should be rare since the new versions at least try to be as backwards-compatible as possible.
Vice versa, the worst that can happen from sticking to an old Asar version is that new patches might not work with it and throw errors. Aside from that, you shouldn't get any problems, so if you don't plan on using any new patches, anyways, you should be fine.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
The speedrun is notable against SA-1 Pack, thank for the update.

It's pretty cool to see fullsa1rom working properly now. I will be sure to make more tests though the time; freecode should always go in the first 4MB portion of the ROM and freedata priorize the last 4MB of the ROM then go on the first 4MB of the ROM.

We need to eventually test how HiROM bank crossing works, that could be useful to reduce ROM freespace fragmentation. I don't know if the PC is automatically increased within the 24-bit range, but I suppose so.... probably biggest problem would be keeping the data bank depending on the patch.

The prot leak fix was also fundamental. Leaks are the worse thing that can happen after data corruption and certainly would cause a lot of frustration (as I had once with Touhou Mario 2 - the only time I had to ever port the ROM).

Good job and keep Asar up to date!
Will update my tools to use the latest version soon.
GitHub - Twitter - YouTube - SnesLab Discord
Always neat with an asar update, but why would you ever need to use values greater than $80000000? #smrpg{haha}

allow shy guy emojis in post footers you cowards!
I always feared freespace leaks. It's nice that you fixed one related to the prot command.

Other than that, I've never heard of fullsa1rom but it'll sure be useful for users who want to use the banks $80+. Small but great update!

Userbar by Green Jerry

Also a Fortaleza Reznor user. If you... digo, si hablas español, hackeas, buscas ayuda, o simplemente se te da conocer gente, únete, somos puerta abierta.
I've been trying out asar 1.70 these past couple days, and I have some feedback to give.


- To start off with, the ability to use math on the incbin commands is a great new addition, although there might be a bug with the implementation.

Code
!ROM = "smwOrig.smc"
!Header = $0200
org $008000
!Offset = (readfile1("!ROM", snestopc($008000)+!Header))
incbin "!ROM":($00)-(!Offset)


If this do this, asar throws the "broken incbin command" error. However, if I put a # in front of the = by !Offset, it works without issue. It's probably an issue with the readfile command, but it might be something else).


- Another oddity is that if you use the error command, it displays the error text twice. This is not the case with the warn command.


- Whenever asar reports an error, it gets the line numbers wrong in some situations. Also, the "(called from X:Y):" tends to display the same file name as the previously mentioned one (or sometimes even other things besides a file name, like a macro call or a label), but the line number displayed next to this is for a different file. My disassembly is really good for testing this issue, because it comes up frequently.


- You might want to consider increasing the limit on the number of freespace blocks one can have, because I've written patches that would require inserting far more than 125 freespace blocks at a time. This also seems to affect addmusicK, as I noticed it appends RATS tags onto the bin files it inserts.


- I've mentioned this before, but you should consider implementing a way to disable asar from automatically using FastROM addressing in lorom/hirom mode. While that's fine most of the time, it causes problems in some cases. My disassembly is affected and I have to use some hacky workarounds to stop this from happening (which I know are going to cause problems down the line).

Implementation wise, I fixed this in asar 1.60 by going into libsmw.h, going to inline int pctosnes(int addr), and removing the |0x800000 from the first "return addr|0x800000;" The same could be done for hirom by changing the first "return addr|0xC00000;" to "return addr|0x400000;". Maybe you could add a command that's on by default that stores 0x800000/0x000000 to a variable which gets OR'ed to addr's value on those two lines.
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
Originally posted by yoshifanatic
If this do this, asar throws the "broken incbin command" error. However, if I put a # in front of the = by !Offset, it works without issue. It's probably an issue with the readfile command, but it might be something else).

That's just Asar really hating spaces. Try removing the space after the comma in !Offset.

Note to self: why does assembleblock split with qsplit, not qpsplit? is there any case where spaces in parentheses definitely need to split arguments?

Originally posted by yoshifanatic
- Another oddity is that if you use the error command, it displays the error text twice. This is not the case with the warn command.

That's just caused by error printing the entire line that caused it. Not sure why it doesn't print the line when warnings are thrown. I should probably fix both of those, so that error/warn commands don't print the line while all other errors/warnings do.

Originally posted by yoshifanatic
You might want to consider increasing the limit on the number of freespace blocks one can have

I've been wanting to do that, but Asar uses the high byte of the current SNES address as a freespace counter, and for some reason the current SNES address is a signed integer, so only values 1-127 can be used safely. So without serious rewriting I can only bump the number up to 127, which probably wouldn't help much.

Originally posted by yoshifanatic
- I've mentioned this before, but you should consider implementing a way to disable asar from automatically using FastROM addressing in lorom/hirom mode. While that's fine most of the time, it causes problems in some cases. My disassembly is affected and I have to use some hacky workarounds to stop this from happening (which I know are going to cause problems down the line).

You probably only stumbled upon this because you are using warn bankcross off, which is implemented in a kinda hacky way. I have some WIP code for it that has been waiting since August, but I keep forgetting about it, lol.
  • Pages:
  • 1
  • 2

Tool