Banner
Views: 661,807,147
Time:
23 users online: anonimzwx, aterraformer, BeeKaaaay, BootaNoBijuu, Davideesk, eskayelle, Flux3on, Green Jerry, izaguirrefermin28, Kanbi, Landonb8x, Lotica, NaroGugul, Pablo's Corner, randombot999, randomdude999, SimFan96, SQL_Infection, Sweetdude, ThalesMangaka, Vlif14, WhiteYoshiEgg, Will16 - Guests: 71 - Bots: 626Users: 35,420 (1,294 active)
Latest: Flux3on
Not logged in.
Asar: Under new management
Forum Index - SMW Hacking - Resource & Tool Releases - Asar: Under new management
Pages: « 1 ... 13 14 15 16 17 18 19 »
Are you, by chance, passing a relative path to the Asar executable? Something like

Code
asar.exe my_file.asm


instead of

Code
asar.exe C:/my_folder/my_file.asm


I can imagine there being a bug with relative file paths breaking stuff. Can you try the latter and see if that fixes the problem? If so, we have a potential lead on where to look.

--------------------
Feel free to visit my website/blog - it now isn't actually shit anymore!
Originally posted by RPG Hacker
Are you, by chance, passing a relative path to the Asar executable? Something like

Code
asar.exe my_file.asm


instead of

Code
asar.exe C:/my_folder/my_file.asm


I can imagine there being a bug with relative file paths breaking stuff. Can you try the latter and see if that fixes the problem? If so, we have a potential lead on where to look.


Yes. I do the former whenever I apply a patch. Anyway, I tried doing the latter and the patch applied with no issues.

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
Alright, thanks for checking. So it seems like something with relative paths broke (yet again). Actually, I think I ran into this same bug with an old patch just yesterday, but didn't get to investigate it yet. It will be something to look into later.

--------------------
Feel free to visit my website/blog - it now isn't actually shit anymore!
About the error without a message: I have reduced your case to this:
Code
org $008000
LDA.b .

Looks like it happens because asar is trying to throw an "invalid label name" (about ".") error on pass 1, but the error is marked for pass 0, which causes it to not be shown. Interestingly, this doesn't happen with "LDA .", which correctly shows the error. I have no idea why this check isn't ran on pass 0 though. (arch_65c816.cpp is the messiest thing i've seen tbh)
Fixed the bug with passing relative file paths to Asar. Asar internally normalizes file paths to make sure that include guards and memory files work as reliably as they can. This path normalization had a bug that could occur in certain situations. Basically, it does a string cmpare against "." and ".." to find (and, if possible, remove) special path components, and it uses a length to compare those strings. This length, however, can end up being 0 in some cases, and a comparison between two 0-sized strings will always return "equal", so in this case the function assumed another ./ component was found, tried to remove it and corrupted the string.

A fix should be available in this build, so you can download that one and check if it works for you.

--------------------
Feel free to visit my website/blog - it now isn't actually shit anymore!
Originally posted by RPG Hacker
Fixed the bug with passing relative file paths to Asar. Asar internally normalizes file paths to make sure that include guards and memory files work as reliably as they can. This path normalization had a bug that could occur in certain situations. Basically, it does a string cmpare against "." and ".." to find (and, if possible, remove) special path components, and it uses a length to compare those strings. This length, however, can end up being 0 in some cases, and a comparison between two 0-sized strings will always return "equal", so in this case the function assumed another ./ component was found, tried to remove it and corrupted the string.

A fix should be available in this build, so you can download that one and check if it works for you.


Yep, it works. Thanks for fixing this!

--------------------
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Inside Story (on hold)
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6 / Latest Test Build (Mario & Yoshi's Strange Quests)

Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
Hello. First off, thank you for all the work you put into Asar. It's an incredible tool.

Might be a dumb question, but is there a way to get the current value of the PC as an integer? I see it's accessible in the print function, but outside of that, I've tried "pc" "pc()" and "!pc" but these don't seem valid. I would like to be able to get its value and store it in a define for later use, if possible.
Code
!offset #= pc()


Thanks again!
No, you can't do that sadly. If you want to go back to an older PC location you can use pushpc to save the PC and pullpc to restore it.
Oh, that's unfortunate. Would it be possible to add that in a future release?

The reason I ask is, I'm trying to disassemble part of a ROM where certain binary data is broken into pieces, and spread out through the ROM at different banks (yeah it's weird). It literally stores the data until it hits the end of a bank, then jumps, then continues. If I could store the PC value before storing one of these pieces, I could calculate what length of data will be written, and then in the next bank, continue where that piece ended in the data by passing that length to the `incbin` command.

I'm trying to avoid hardcoding values as much as possible, so people can customize the binary data without worrying about changing any lengths or offsets.

Without the PC, I think I'll have to hardcode the lengths and offsets of each piece. Or maybe there's some other way to handle this...
Unfortunately I don't think that will work with Asar, for the same reason that you can't do math with labels: Asar has multiple passes, and I think the value of PC changes inbetween pases (because of opcode length optimization and stuff). This means with Asar, unfortunately keeping track of positions yourself will be your only option. You could maybe make some macros to make this more handy and more customizable.

Code
!current_pos #= $008000


macro step(num)
	!current_pos #= !current_pos+<num>
endmacro


macro read_and_step(num)
	db read1(!current_pos)
	%step(<num>)
endmacro


org $048000

!current_pos #= $008000
read_and_step($1000)

!current_pos #= $018000
read_and_step($1000)


This is just a meaningless example to demonstrate the idea. With some more information on what exactly you're trying, I might be able to help some more.

I guess what could, in theory, be possible, would be to add a command line option to completely disable Asar's opcode length optimizer and allow label math. I think that could work. If so, a getpc() function also could be possible.

--------------------
Feel free to visit my website/blog - it now isn't actually shit anymore!
Originally posted by RPG Hacker
I think that could work.

Code
freecode cleaned
nop
if getpc() < $110000
rep $6000 : nop
endif

Let $108000 to $10BFFF be used in the target ROM, everything else is free.

If the condition is true, $6009 bytes won't fit in $10C000, so Asar has to place it at $118000. But then the condition is false.

If the condition is false, 9 bytes will fit at $10C000, and Asar will do that. But then the condition is true.


And I don't like the idea of command line flags to control assembler behavior, they make things harder for our users. They should be in the patch, like @xkas.


Better idea: Keep track of whether the current PC is known constant across passes (that flag being set by org, and cleared by LDA Label and freecode - it's not set by the 'pad to $00F606' command, it can leave pc >= $00F606 if pc was originally above that).

If so, it's safe to use the PC address (including via labels), and bank crossings can be permitted (but only if explicitly permitted with 'incbin large.bin +cross' or something, unexpected bank crossings will break your ROM no matter what you do). If pc is not constant, keep the current limitations.


e: also, if you allow bank crossings, you have to figure out how to deal with freespaces larger than 0x10000 bytes. I'd vote error out and see if anyone whines, but there are other possibilities. ...okay, the above model won't permit bank crossings in freespace at all, but you may want to add a comment about that or something.

--------------------
<blm> zsnes users are the flatearthers of emulation
Thanks for the input. I think for now I'll try keeping track of the PC using macros that track how much binary data has been loaded from files after the last time I use `org`. I'd love to comment on the getpc() function feasibility but it's far beyond my level of knowledge.
Originally posted by Alcaro
And I don't like the idea of command line flags to control assembler behavior [...]


Me neither (at least for stuff that could reasonably be expected to be used in patches and stuff). Though I was too lazy for a

Originally posted by Alcaro
Keep track of whether the current PC is known constant across passes [...]


solution, so a command line option was my first instinct. That being said, your point on freespace is valid, leaving "keep track of [...]" as the only good solution to the problem, so we'd have to go with that if we decided to implement this.

"We" currently meaning "someone else", because I have so many things on my mind right now, I can barely even find time to think about Asar, let alone work on it productively.

--------------------
Feel free to visit my website/blog - it now isn't actually shit anymore!
Pages: « 1 ... 13 14 15 16 17 18 19 »
Forum Index - SMW Hacking - Resource & Tool Releases - Asar: Under new management

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2018 - SMW Central
Legal Information - Privacy Policy - Link To Us


Total queries: 23

Menu

Follow Us On

  • Facebook
  • Twitter
  • YouTube

Affiliates

  • Talkhaus
  • SMBX Community
  • GTx0
  • Super Luigi Bros
  • ROMhacking.net
  • MFGG
  • Gaming Reinvented