Language…
6 users online: ASSATAKKU, Hidincuzimsmokin, katun24, Nitrogen, S.U, Vuong Van - Guests: 107 - Bots: 104
Users: 57,945 (2,498 active)
Latest user: karls_Corinthia

Asar: Under new management

I guess it should be doable if I just push the paths to the table files instead of the whole tables. That shouldn't need too much memory. Although it might not be that reliable, since I think you can combine multiple table files as long as you don't call cleartable inbetween. Guess I might as well just push the whole table. They're probably not that big, anyways, and it's not like modern systems are very likely to run out of memory so quickly.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Just guessing here, but I'd say a table has 2 byte per entry (key value pair). A table usually contains the 26 letters (small and capital) plus a couple of special characters, let's round it up to 70. In that case one table would be worth 140 bytes.
Even if the value is an int we get to 5 byte per entry and 350 byte in total.
So yeah, just push the whole thing.
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
Originally posted by JackTheSpades
Just guessing here, but I'd say a table has 2 byte per entry (key value pair). A table usually contains the 26 letters (small and capital) plus a couple of special characters, let's round it up to 70. In that case one table would be worth 140 bytes.
Even if the value is an int we get to 5 byte per entry and 350 byte in total.
So yeah, just push the whole thing.

No, the table isn't variable size at all, it's always 256 entries. Fixed-size arrays are easier than anything variable, I was lazy.

But that's still only 1KB, so there's no reason to try to trim that. The ROM takes 32MB internally already (16MB for writing, another 16MB for read3 to return the unmodified ROM), another kilobyte or two isn't relevant.
<blm> zsnes users are the flatearthers of emulation
Alright, ladies. Here we go!

Not submitting this to the tools section yet, because

a) the previous version 1.40 isn't even approved yet (seriously, what's up with that, where are all the tool moderators? #w{xD}) and I don't want to mess up the version history and stuff, so I'll wait for that version to get approved first.

b) implementing the API on "written blocks" required touching every single piece of code that modified ROM data, which of course means I could have easily messed up something, in which case certain functionality might either not write to the ROM at all anymore or write to the ROM in unintended ways - in other words, it doesn't hurt to get this tested for a bit before submitting it to the tools section.

Anyways, here is the changelog:

Originally posted by Asar v1.50
New features:
  • Added support for structs. Credits go to p4plus2: https://github.com/p4plus2/asar
  • Added API to Asar lib for getting information on all blocks of data written by Asar.
  • Added API to Asar lib for getting the mapper currently used by Asar.
  • Added support for ExLoROM and ExHiROM mappers.
    NOTE: Based entirely on conversion tables I got from Ladida; don't know if these conversions are actually correct. Some features may not work as intended when using those mappers (such as freedata, for example), but I can't verify this.
  • Added pushtable and pulltable commands, which let you back-up or restore the current character table to the/from the stack.
  • Added "ext\notepad-plus-plus\syntax-highlighting.xml". This file can be imported into Notepad++ as a user-defined language to add syntax highlighting for Asar patches, featuring all commands currently supported by Asar. By default, this syntax highlighting is enabled on all files with an extension of .asm or .asr, but this can be customized via Notepad++.

Bug fixes:
  • Lines starting with @ or ;@ that don't map to a recognized special command now only throw warnings at best and no errors.
  • Rewrote code of tests a little to make them easier to execute and make them clean up their own mess.
  • C# wrapper for Asar DLL was non-functional since it didn't specify a calling convention, making it always lead to an exception in some scenarios.


Additional notes:

@Ladida: I did try implementing some kind of "include multiple files at once" functionality, though I wasn't able to come up with any solution that had the level of flexibility I had hoped for while still offering good performance, so I gave up on this feature altogether. Without that flexibility, I really don't consider this feature very useful, especially since it poses a bunch of extra problems. For example: I'd also have to code some way to let the user sort the files they're including, since the order of includes might actually influence the way the game is behaving depending on how you structure your ASM files. Basically, if you want to include multiple ASM files at once quickly, you'll probably have to write your own script for that (I recommend using something like Ruby, where it's literally just a few lines of code at most to do this).

@imamelia: I did look into fixing the incbin bug you described above, though I wasn't able to reproduce it at all here. Neither with a generic 64 KB bin file, nor with the specific 64 KB bin file included in that patch, and neither on an SMW ROM, nor in a standalone ASM file. It just always worked fine for me, so I assume that the error is caused either by how Sprite Tool uses Asar or by the way you've written/set up the patch. A few possible error sources:
  • Did you make sure the bin file is - at most - 65536 bytes large?
  • Did you consider the space required by the RATS tag itself? (An additional 8 or 9 bytes, I think). So basically, your ROM needs at least 0x10009 consecutive bytes of free space somehwere, spanning at least two consecutive free banks.
  • Did you try just splitting the bin file into two 32 KB bin files? Since the game needs to DMA from at least two tifferent banks, anyways, I suppose there is really no reason why two 32 KB files wouldn't work. Or, instead of splitting the actual file, I think you could also do something like this:

    Code
    GFXAddr1:
    incbin yibncgfx.bin:0-32768
    GFXAddr2:
    incbin yibncgfx.bin:32768-65536


    So maybe give that a try and see if it works?
  • Also did you make sure to check all the errors Sprite Tool was giving you? If I remember correctly, Sprite Tool has some special working directory shenanigans. In other words: It's possible that it's just not finding the bin file at all (though I think it wouldn't print the freespace error message in that case).

Aynways, enough things for you to try out.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Awesome #wario{O_o}
No seriously, if everything in this works as intended, making tools could be a bit easier with asar.dll ^^'
Though I don't know what problem you had with C#. I've used it before and never ran into any trouble with it?

Speaking of tools, think you could add a way of adding defines via CLI/API? Similiar to gccs -D flag

Originally posted by gcc
-D name
Predefine name as a macro, with definition 1.
-D name=definition


I forgot the exact syntax, but iirc asar has a way of checking for labels, so this could allow tools (or batch files) to use 1 asm file in multiple variations.
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
Thanks!

Originally posted by JackTheSpades
No seriously, if everything in this works as intended, making tools could be a bit easier with asar.dll ^^'


I sure hope it does! I honestly forgot to test a few of the features as much as I probably should have, such as the "written blocks" API. I did test it for a bit and it seemed to work as intended (espcially the "sorting ROM writes into banks" part), though I'm not sure if it works as intended in 100% of cases. Anyways, that's why my post exists in the first place. If something broke from my changes, I hope someone will notice it soon enough.

Originally posted by JackTheSpades
Though I don't know what problem you had with C#. I've used it before and never ran into any trouble with it?


Well, it's possible that the exception it threw wasn't harmful at all and only appeared in debug builds (and even then only when enabling certain debug settings). In my case, the exception was thrown when calling Asar.patch(), I think. I think the exception mentioned a stack imbalance or something like that. In any case, adding the C calling convention as an attribute to each function made the exception disappear completely, so I suppose it's better and safer like that.

Originally posted by JackTheSpades
Speaking of tools, think you could add a way of adding defines via CLI/API? Similiar to gccs -D flag

Originally posted by gcc
-D name
Predefine name as a macro, with definition 1.
-D name=definition


I forgot the exact syntax, but iirc asar has a way of checking for labels, so this could allow tools (or batch files) to use 1 asm file in multiple variations.


One way you could potentially solve this now already would be to include your patch from another file and then pass that file's path to Asar. Something like this:

Code
; settings1.main:

!define1=0
!define2=0

incsrc actual_patch.asm


Code
; settings2.main:

!define1=1
!define2=2

incsrc actual_patch.asm


Code
; actual_patch.asm

!define1 ?= -1
!define2 ?= -1

if !define1 <= 0 || !define2 <= 0
	error "Some defines are not set - are you trying to patch actual_patch.asm directly?"
endif

if !define1 == 0
	; Do something
else
	; Do something else
endif

if !define2 == 0
	; Do something
elseif !define2 == 1
	; Do something else
else
	; Do something entirely different
endif


Code
> asar.exe settings1.main output_rom.smc


Or if you absolutely need this behavior dynamically, you could just let your application create a text file in the Windows temp folder and then pass the path to that text file to Asar.

Anyways, for now, I'm not planning to add any more new features to Asar (although I'll still try to fix all bugs introduced in v1.40 or v1.50 if people report any). Back then, I really only started on v1.40 because there were a few features I absolutely wanted to have in Asar for a patch of mine. Then, when people suggested new features for v1.50, I wanted to do them a favor and try to add all these features. After that, I quickly lost motivation, though, which is why progress has been lying dormant for a couple of months on the new version. This shows me that it's probably better to leave it at that, so I decided to quickly finish this version some time ago so that I could finally move on (or rather move back to the patch that orignally made me start implementing new features).

Anyways, the source code of Asar is, of course, publicly available, and this feature in particular sounds like it would be quite easy to implement (I think you really only have to modify a global array containing the defines). So maybe someone else can give it a try? #w{=3}
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Originally posted by RPG Hacker
if !define1 <= 0 || !define2 <= 0
error "Some defines are not set - are you trying to patch actual_patch.asm directly?"
endif

@includefrom
<blm> zsnes users are the flatearthers of emulation
True, almost forgot that exists. Although @includefrom takes the name of a file. I know it doesn't verify that it's included from this file, but it might still be counter-intuitive to use it when the actual main file might have one of differen names. I guess it's still wise to use it, just for clarity.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
There is a @include that just says "wrong file", not "wrong file, use 123.asm instead".
<blm> zsnes users are the flatearthers of emulation
Yeah, that would be more suitable in this case. I'd probably use that in combination with a temporary file generated by another script.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Yeah, I'm aware that I can use it like this, but in the end, I still have to have multiple asm files with the defines that then import that actual patch.

If it's too much trouble, then don't bother, but I just think it would be nice for tools to invoke different behavior without having the need of different asm files lying around or having to modify them.

Most mundane example I can think of right now would be debug messages.
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
I think it's a feature that's rather simple to implement, since really, I think you only have to add elements to Asar's global array of defines. Maybe if someone finds a bug in v1.40 or v1.50 that I still need to fix, anyways, I can work it in there quickly, since it shouldn't take more than a few minutes. In any other case, as I said, it should be really easy to implement and anyone with at least a moderate amount of C++ experience should be able to do it, so maybe you could even give it a try yourself in that case.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
I guess I'll have to see what happens next time I need to include a file larger than 0x7FF8 bytes.

On an unrelated note, are there any plans to allow macros to support variable numbers of arguments?

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

I'm working on a hack! Check it out here.
Can you give a usage example? I assume you're thinking of something like variadic functions in C? That would be very useful, but would also probably take a bit of time to implement and would required some kind of special syntax and special commands to determine the number of arguments and stuff like that.

But thinking of it, I can imagine that this might already be possible to simulate using defines and while loops. I'll have to experiement with this for a bit.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Yes, that's it. Would it be easier to implement if the first argument determined how many there were? Like, I don't know, CreateTable($03, $AA, $BB, $CC, $DD) vs CreateTable($05, $AA, $BB, $CC, $DD, $EE, $FF) or something. I was going to use it for a state engine-type algorithm, but it's come up in other things as well (homebrew, at least, for placing objects and sprites with variable byte counts).

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

I'm working on a hack! Check it out here.
I'd say the actual difficulty isn't really in determining the number of arguments, but in actually using those arguments. You'd need some kind of special syntax to access each argument and maybe even iterate over them. Something like va_list and va_arg in C. That could be a pain to implement, but I'm not sure, as I haven't looked further into this.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
So did anyone try the new version at all? I kinda want to get closure on this, but it doesn't seem like anyone even tested the new version at all, so I just don't feel confident yet that it's bug free enough for an upload to the actual tools section (plus, Asar 1.40 has been stuck in the "waiting" Limbo for four months now - come on, is noone gonna look at that thing? I don't want to fuck over the whole version history with an upload...)
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
I've planned to use the new version the next time I need Asar, it's just that that hasn't happened yet.

I'm sure my setup isn't so complex as to be a full test suite, but if you'd like, I can run your version with my patchall.bat and see if that turns up any blatant errors.


 
Also, I'd honestly suggest you upload the new version right away even without 1.40 having been moderated.
I think you're just needlessly having things moderated twice.
Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?