Banner
Views: 695,505,050
Time:
15 users online: Allrounder, Withered Jinker Bolts, Mr. Darkolac, Twilight Sparkle Resolute Form, Flippn'Fences, ggamer77, SPOOKY SCARY SKELETONS WILL..., eyedoll, silvagunner, nintendofart, Romano338, Tarkan809, Mothman, spooky wood >;], WYE - Guests: 43 - Bots: 165Users: 36,369 (1,518 active)
Latest: Twigor
Tip: If you place too many sprites on the same screen, it will slow the game down and cause frustration to the player.Not logged in.
Asar: Under new management
Forum Index - SMW Hacking - Resource & Tool Releases - Asar: Under new management
Pages: « 1 216 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!
idk if this has been mentioned anywhere but itd be nice if you could access structs by just using their identifier. right now asar is gibing error when i do that

aka:
Code
struct aaa $0000
	.w: skip 1
endstruct align 1

LDA.w aaa	;error
LDA.w aaa.w	;fine
LDA.w aaa[0]	;error
LDA.w aaa[0].w	;fine


i think even empty structs bork like that

also a way to like nest structs. so you can do something stupid like aaa[0].q.tt[2][8].w
i think extend does something like that but apparently its a bit broken ???

also a way to limit the # of aligns/arrays. aka LDA.w aaa[31].w wont work because it limits you to 30. maybe warnpc can be abused in some way? so instead of limiting the # of list entries you just let it go until youre referencing an address past the warnpc. idk

--------------------
僕の日本語を失礼します。
Adding struct name itself as a label seems like it should be simple to do (array access might still not be possible in that case, though, I'm not sure).

Adding support for nested structs is unfortunately pretty much out of question right now. The way structs and extended structs are implemented in Asar in the first place is so incredibly hacky that I don't ever want to mess with it if I can avoid it. Nested structs would definitely cause some kind of major headache for me.

The last one, I'm not sure what that's about. Does Asar have some kind of weird built-in 30-length-array-limit?

--------------------
Feel free to visit my website/blog - it now isn't actually shit anymore!
no thats an example of what i want lol

aka
Code
struct aaa $0000
	.w: skip 1
endstruct align 5 limit 30

LDA.w aaa[30].w ;fine
LDA.w aaa[31].w ;error because limit set to 30


or

Code
struct aaa $0000
	.w: skip 1
endstruct align 5 warn $0010

LDA.w aaa[2].w ;fine
LDA.w aaa[3].w ;error because aligned struct exceeds addr


i know you can put warnpc inside the struct but thats different, affecting the size of the struct and not the # of structs you can use



also #smw{T_T} @ nested

--------------------
僕の日本語を失礼します。
Asar 1.61 has been released. It re-adds if !condition (because a few patches were using that), and fixes a really weird bug where the line doesn't get assembled if it has a label followed by >3 spaces and the line ends with ".

Download - Changelog
Also updated the waiting submission with this version.

--------------------
Feel free to visit my website/blog - it now isn't actually shit anymore!
I guess I should post this here:

What exactly is the error "Don't autoclean a label at the end of a freespace block, you'll remove some stuff you're not supposed to remove" supposed to mean?
I have never seen that being thrown when the description is actually accurate to what you're doing.

Anyway, I also don't really understand what is happening here and feel like this is a bug:

The patch

Code
sa1rom
print hex(read3($06F624))
print hex(read3($06F717))
print hex(read3($06F67B))
print hex(A)
print hex(B)
org $06F624 : autoclean dl A
freecode
B: db $0

org $06F717 : autoclean JML B

freedata align
A: rep 10 : db 0

org $06F67B : autoclean JML B


outputs

Originally posted by asar
888000
801C5C
80085C
128000
10CA1A
maintest.asm:7: error: (E5136): Don't autoclean a label at the end of a freespace block, you'll remove some stuff you're not supposed to remove. [autoclean dl A]
Errors were detected while assembling the patch. Assembling aborted. Your ROM has not been modified.

(4MB SA-1 ROM, using the currently waiting asar 1.61 but 1.50 and 1.37 do the same)

however, only autocleaning the B freespace once, or autocleaning both before or after the A freespace block will not throw the error.

The following variations work with the last one having a slightly different outcome:

Code
org $06F717 : JML B

freedata align
A: rep 10 : db 0

org $06F67B : autoclean JML B
Code
org $06F717 : JML autoclean B

freedata align
A: rep 10 : db 0

org $06F67B : JML B
Code
freedata align
A: rep 10 : db 0

org $06F717 : autoclean JML B
org $06F67B : autoclean JML B
Originally posted by asar
888000
801C5C
80085C
138000
10CA1A
Code
org $06F717 : autoclean JML B
org $06F67B : autoclean JML B

freedata align
A: rep 10 : db 0
Originally posted by asar
888000
801C5C
80085C
128000 ; different this time though this is probably just a thing of order and not a bug
10CA1A
Pages: « 1 216 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