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.
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.
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:
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"
- 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:
... 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
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!