14 users online:  Amethyst, Capeman,  Donut, gui, habarakoyo,  idol, Isikoro, jollyball77, muffinchops, playagmes169, slogra, TheJavabrew, TheKolyian4ik, xfix - Guests: 81 - Bots: 135
Users: 58,744 (2,331 active)
Latest user: SkeletonDance

Asar: Under new management

I think it's still not binary compatible because of this check in the C binding:

if (asar_apiversion() < expectedapiversion || [...])

Since asar_apiversion() now returns 303, while current tools expect 300, they should fail loading this new version (unless, of course, they didn't use this binding).
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
...that condition is true. 303 < 300. And the major version is the same. So it should still be compatible.
e: nvm i suck at math
That check is supposed to block a tool built against API=303 from loading an API=300 DLL. The other direction should be allowed.

(Though I can't promise I didn't bug it up.)
<blm> zsnes users are the flatearthers of emulation
Then you bugged it up LOL

although I'm still quite sure I managed to load the beta DLL on some old tools. Maybe we didn't change the API ver back then.
As far as I remember, we wanted to take another look at this handling of API versions, anyways (though I'm not sure if we've made an issue for it). So yeah, another thing to put on our to-do list.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
You mean here?
IMO the API version is an easy way to prevent crashes (from using the wrong DLL) while still allowing an older application to use a newer backwards-compatible DLL. Those goals are still quite important, so we would have to think of another solution.
Yup, that is important. I wouldn't get rid of that entirely, either, just slightly rewrite the check to make user of Asar's main version number instead or something like that (since it should accomplish the same thing, just with less numbers ot keep track of). Another possibility is to write APIs in a way that won't crash stuff because of version changes (kinda like what I tried to do with asar_patch_ex()), though I don't know if that's always possible and/or practical.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Nevermind, we all (except Alcaro, so just me and RPG Hacker) are idiots, apiversion() < expectedapiversion is the condition that triggers raising an error. The full line was:
if (asar_apiversion() < expectedapiversion || (asar_apiversion() / 100) > (expectedapiversion / 100)) return false;

So the backwards compatibility code is still correct.
Isn't that exactly what I've been saying from the beginning, though? 🤔
Since the API version has changed and thus that line will return false, asar_init() will fail, which means the new DLL can't be loaded in the current tools.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
asar_apiversion() will return 303. expectedapiversion will return 300. The condition 303 < 300 is false, thus the branch is not taken, and the function will exit sucessfully.
What is the correct usage of "freedata"? I couldn't find any answer in the manual.

I'm having an issue with "freedata", it's always sending a warning that "This freespace appears to be leaked" and it always reallocates a new freespace each time the patch is inserted.

This is what I'm doing:

print "Expanded machine data at $", pc
    ; A whole lot of DB $xx

    ; A whole lot of DB $xx

; A few more repeating this pattern

The way I'm using these values is like so:

    LDA.l Turn_Speed_Tbl,x

I tried adding "autoclean" before "LDA.l" but it errors.

This is not SMW related, if you need this info.
I'm reverse-engineering and hacking F-Zero (SNES)!

My YouTube channel, with various hacking tests
You use freedata for codes without bank switching and large tables. That should be obvious. Cleaning freedata also works the same as freecode. In fact, the only difference between "freecode" and "freedata" is the location where the code is put but are otherwise identical.

Your problem is that you try to clean freedata inside a freespace block. That isn't allowed. "autoclean" can only be used inside fixed locations. The only alternative you can use is "prot label1, label2, label3, ...". "prot" allows you to protect freespace blocks inside others which is what you want here. Keep in mind that you need only one label. That means, while you can use "prot Turn_Speed_Tbl, Another_Label, ...", you only need to use "prot Turn_Speed_Tbl".
To simplify: when you use autoclean, it always needs to go on your hijack. Usually, when making a patch, you have some hijack somewhere in the ROM which jumps to a new routine in freecode. The autoclean has to go on that jump (I think it only supports jump commands, that's why LDA is not supported). Of course this means if you only use freedata and don't also have any code in your freespace area that you jump to, the regular autoclean doesn't work. However, there are also alternative versions of autoclean. You can also put autoclean on a dl that points into your freespace area. So in your situation, something like this could help:

	; ...
	autoclean dl Turn_Speed_Tbl

	; ...



	; ...

I also suggest taking a look at the new manual, which explains autoclean in more detail than the old one.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Ah thanks, that worked out.

There was no actual "hijack" per se, I just needed a way to expand and relocate some of the tables in ROM (it might sound weird, but it was the only way around for what I needed to do)

So I ended up adding the "autoclean dl Turn_Speed_Tbl" at the place where the original tables are.

Something like this:
org $xxxxxx ; Relocate "Turn_Speed_Tbl" to the expanded version
    LDA.l Turn_Speed_Tbl,x ; Originally used long addressing too
org $xxxxxx ; Relocate "Another_Tbl" ...
    LDA.l Another_Tbl,x ; Originally used long addressing too

org $xxxxxx ; Original location of the tables
    autoclean DL Turn_Speed_Tbl

print "Expanded data at $", pc
    ; Loads of "DB $xx"

    ; More lots of DB $xx ....

; Even more tables following with loads of "DB $xx"

I'm reverse-engineering and hacking F-Zero (SNES)!

My YouTube channel, with various hacking tests
Visual Studio is giving me this error related to the asar.cs file included in asar 1.60 beta release when I try to compile UberASM Tool 1.2.

I kinda need it because the tool currently uses asar 1.50 and that one has a broken sa1rom support.

Edit: All I did was replacing the asar.cs and asar.dll files inside of the UberASMTool folder with the asar 1.60 ones and then build the project with Visual Studio.
I don't remember who the last one was to update the C# binding. We also currently don't have tests for any of our bindings (would be useful to have them, but also quite time-consuming).

Simplest guess: maybe that ToArray() function is only available in a later version of Visual Studio/C#?
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
It also happens in the most recent version of the Mono runtime.

That error was introduced by commit 0bf5cf5. I'll debug it a bit more, and make an issue on the github.

Edit: fixed. Try the latest one from github.
Like I mentioned on Discord, it worked. Thanks.
I got a couple bugs to report.

- In asar 1.60, using a relative path that goes back to a previous folder seems broken/inconsistent. As an example, if I do this:

incsrc "../File.asm"

... and the patch that does this, asar, and the file I'm patching are in the same folder, while File.asm is in a previous folder, asar will give error E5015. If I used incbin instead of incsrc, then asar gives error E5016 instead. And if I used asar 1.50 in this situation, then it applies the patch just fine.

- In asar 1.50-1.60, doing the following causes asar to say that errors were detected while assembling the patch, but it doesn't say what the error was:

!RAM_Test = $7E0000

org $0FFFFC
	LDA.b .!RAM_Test

I just happened to stumble upon this odd behavior by complete accident.

By the way, on an unrelated note, I'm rally liking some of the new features in the asar 1.60 beta, some of which will come in handy for some of my projects. I'm also glad to see that the readfile/canreadfile crash was fixed! :)
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.