Language…
9 users online: acd13141,  AmperSam, Cristian Cardoso, CroNo, fanfan21, Green Jerry, Hayashi Neru, Maw, tOaO - Guests: 241 - Bots: 391
Users: 64,795 (2,377 active)
Latest user: mathew

Asar: Under new management

Originally posted by Alcaro
Yes, I know those are files. It doesn't matter which file you use for this, Asar will just ignore it.
Some generic existing file is probably easier since you won't need to care about Windows vs Linux.


It's probably an irrelevant subject, but do you mean that the program won't need to care, or the user won't. It's probably best as a command line option if you just want to use a consistent name.

I was under the impression you could give it a device and the program would just happily read from and write to the device as if it was a file without special internal handling, but I am not sure. If that were true, it would work already.

Originally posted by Alcaro
Inserting binary files is indeed stupid. I think all spritetool tells the assembler where to place the file, but I'm not entirely sure. (BTSD seems to insert binary files.)
Romi's reinserts everything, which takes a minute for larger ROMs. I never checked Tessera, but something tells me that feature is missing there too.
(I'm not sure if I like the idea of an all-in-one sprite inserter either, but that's irrelevant.)

Random note: Just like it is indeed easier to offload everything to Asar, it is also easier to reinsert all files than checking timestamps. People will often use the easiest solution, even if it isn't the best.


I am pretty sure romi's at least and I think Tessera as well assemble to a temp file to find the size first at least. And really, if your doing that, why not just insert the temp file instead of running the emulator again? Though I am honestly not sure if they do.

Originally posted by Alcaro
I think you've misunderstood something. Both dynamic and static libraries can offer various functions for each other to call. External programs offers only more convulted communication methods (you can hijack stdin and stdout, but that could get annoying).

Either way, making external programs are easier for me (I don't know how to declare that a function should be visible to a DLL, nor do I know how to load one). Sending instructions through stdlib.asm and parsing stdout is good enough for me.

To be honest, my experiences with this type of thing tends to involve monolithic parser classes/functions that end up doing most of the work, and lots of little utility functions that don't do much that is useful on there own. I just assumed a dynamic library would end up being a fancy wrapper to some "assemblethis()" function. It would still be useful for file IO stuff but it doesn't really seem to offer much more flexibility. I havn't looked into it much.

Originally posted by Alcaro
...do we have any reason to follow the official documents?
Besides, I wouldn't trust a document that uses bits everywhere instead of bytes for use as toilet paper.

It's most likely not following the official documents is the reason why there are so many opcode lists in the first place. Though I would expect byuu's to be pretty close.

Originally posted by Alcaro
Yes, you have an LDA.l <label>,x there, which the HTML filter doesn't seem to like. I fixed it for you.
I run into the same problem sometimes when I post a code containing for (int i=0;str[i];i++) str[i]=tolower(str[i]); or something like that.
...though I can't claim to have run into <label> before.

Ugh, I forgot all about that.
Your layout has been removed.
Originally posted by KilloZapit
Originally posted by Alcaro
Yes, I know those are files. It doesn't matter which file you use for this, Asar will just ignore it.
Some generic existing file is probably easier since you won't need to care about Windows vs Linux.


It's probably an irrelevant subject, but do you mean that the program won't need to care, or the user won't. It's probably best as a command line option if you just want to use a consistent name.

I was under the impression you could give it a device and the program would just happily read from and write to the device as if it was a file without special internal handling, but I am not sure. If that were true, it would work already.

I meant that the person making the Asar-using tool won't need to care about Windows vs Linux.
But after thinking about it a little more, that isn't true: Windows uses system("asar.exe blah"), while Linux uses system("./asar blah"). The ./ confuses Windows, and dropping it makes Linux not find it. (The .exe is optional, but if not everything is identical, you'll need an #ifdef.)

And yeah, it won't treat device files differently.

Quote
Originally posted by Alcaro
Inserting binary files is indeed stupid. I think all spritetool tells the assembler where to place the file, but I'm not entirely sure. (BTSD seems to insert binary files.)
Romi's reinserts everything, which takes a minute for larger ROMs. I never checked Tessera, but something tells me that feature is missing there too.
(I'm not sure if I like the idea of an all-in-one sprite inserter either, but that's irrelevant.)

Random note: Just like it is indeed easier to offload everything to Asar, it is also easier to reinsert all files than checking timestamps. People will often use the easiest solution, even if it isn't the best.


I am pretty sure romi's at least and I think Tessera as well assemble to a temp file to find the size first at least. And really, if your doing that, why not just insert the temp file instead of running the emulator again? Though I am honestly not sure if they do.

(Assuming "emulator" is a typo/whatever of "assembler") Yes, they do. I meant the second pass, that one should probably be put directly in the ROM.
Also a simple JSR Graphics will break if you move it around. That's why everyone does two passes.

Quote
Originally posted by Alcaro
I think you've misunderstood something. Both dynamic and static libraries can offer various functions for each other to call. External programs offers only more convulted communication methods (you can hijack stdin and stdout, but that could get annoying).

Either way, making external programs are easier for me (I don't know how to declare that a function should be visible to a DLL, nor do I know how to load one). Sending instructions through stdlib.asm and parsing stdout is good enough for me.

To be honest, my experiences with this type of thing tends to involve monolithic parser classes/functions that end up doing most of the work, and lots of little utility functions that don't do much that is useful on there own. I just assumed a dynamic library would end up being a fancy wrapper to some "assemblethis()" function. It would still be useful for file IO stuff but it doesn't really seem to offer much more flexibility. I havn't looked into it much.

Yeah, if that's what you want, then there are no advantages with dynamic or static libraries over an external program.
For those other functions, that's exactly why the various lib* files exist. They're designed to be used by others (I even added mathlib.cpp for exactly that purpose, Asar doesn't use it).

Quote
Originally posted by Alcaro
...do we have any reason to follow the official documents?
Besides, I wouldn't trust a document that uses bits everywhere instead of bytes for use as toilet paper.

It's most likely not following the official documents is the reason why there are so many opcode lists in the first place. Though I would expect byuu's to be pretty close.

Yeah, the (tiny) parts I checked appears to be identical between bass-spc-canonical and SNES Dev Manual.
I guess I'll allow everything bass allows, but also allow some stuff that I belive makes more sense than the "official" method.

So let's see how many addressing modes I'll need...
Originally posted by extracted from bass
x,a
a,x
a,y
x,sp
y,a
sp,x
a,(x)+
(x)+,a
(x),a
ya,x
a,(x)
(x),(y)
ya,?*"
?*,ya
a,#?*
x,#?*
a,(?*+x)
a,(?*)+y
(?*)+y,a
a,?*+x
a,?*+y
a,?*
x,?*+y
x,?*
y,#?*
y,?*+x
y,?*
c,!?*.?
c,?*.?
?*.?,c
(?*+x),a
?*+x,a
?*+y,a
?*,a
?*+x,y
?*+y,x
?*,x
?*,y
?*.?,?*
?*,#?*
?*+x,?*
?*,?*
a
x
y
ya
p
?*.?
(?*+x)
?*+x
?*


...this looks fun.
<blm> zsnes users are the flatearthers of emulation
Originally posted by Alcaro
I meant that the person making the Asar-using tool won't need to care about Windows vs Linux.
But after thinking about it a little more, that isn't true: Windows uses system("asar.exe blah"), while Linux uses system("./asar blah"). The ./ confuses Windows, and dropping it makes Linux not find it. (The .exe is optional, but if not everything is identical, you'll need an #ifdef.)

And yeah, it won't treat device files differently.

I am sort of surprised ./ confuses windows, as I thought they treated \ and / interchangeably now, though that might only be in quoted paths. Ether way, calling via system is always tricky like that.

Originally posted by Alcaro
(Assuming "emulator" is a typo/whatever of "assembler") Yes, they do. I meant the second pass, that one should probably be put directly in the ROM.
Also a simple JSR Graphics will break if you move it around. That's why everyone does two passes.

(Oops, yeah. Dumb typo/whatevers.)
That's a good point. I guess they just insert an org at the top of the file?

Originally posted by Alcaro
Yeah, if that's what you want, then there are no advantages with dynamic or static libraries over an external program.
For those other functions, that's exactly why the various lib* files exist. They're designed to be used by others (I even added mathlib.cpp for exactly that purpose, Asar doesn't use it).

It's not that I think helper functions wouldn't be useful for various tools that need to find freespace, calculate offsets, and do other such things. It's just that if you parse a asm file with big functions filled with a big switch/case statements into hex values in buffers ready to be written to the file or something, is there anything a tool can do with the assembler as a dynamic library without actually modifying the source files it can't by running it externally?

I guess all this assumes a program like spritetool would actually want to change how files are assembled. I guess if the library were set up to support it, it would be useful enough just to not need to write temporary files, and to assemble multiple files into a buffer without writing to the rom (though I guess you could write a list of files to include in one asm file, maybe). I donno.

Note: I have to admit I have not actually looked at the source yet (or even used the program yet, as I have been distracted by stuff), and I am only really talking about other things I have peeked at. Maybe I am mistaken about the switch/case thing. Or a good deal really.

Originally posted by Alcaro
Yeah, the (tiny) parts I checked appears to be identical between bass-spc-canonical and SNES Dev Manual.
I guess I'll allow everything bass allows, but also allow some stuff that I belive makes more sense than the "official" method.

So let's see how many addressing modes I'll need...
-snip-
...this looks fun.


Maybe it might be easier to look up the hex code with a two dimensional table/array or something for some opcodes? You know x86 has instructions like that, but I think it has a way of encoding opcodes so you can easily encode what addressing mode it uses. I can't tell if there is a pattern to some of the spc instructions or not. :/
Your layout has been removed.
Originally posted by KilloZapit
Originally posted by Alcaro
I meant that the person making the Asar-using tool won't need to care about Windows vs Linux.
But after thinking about it a little more, that isn't true: Windows uses system("asar.exe blah"), while Linux uses system("./asar blah"). The ./ confuses Windows, and dropping it makes Linux not find it. (The .exe is optional, but if not everything is identical, you'll need an #ifdef.)

And yeah, it won't treat device files differently.

I am sort of surprised ./ confuses windows, as I thought they treated \ and / interchangeably now, though that might only be in quoted paths. Ether way, calling via system is always tricky like that.

Yeah, that is within quotes. Unfortunately, quotes don't seem to work so well in when using popen/system, so that's not really an option.
Finally done with this thing.
Changelog:
  • Asar can now assemble SPC700 code; see stdlib.asm for how to enable it. Please note that I only did very minimal testing, and I may have left some bugs in there. Also note that mov a,(x)+ has been moved to mov a,(x+), since that opcode increases X and not the value X points to. If you want to allow the confusing syntax as well, uncomment two lines in arch-spc700.cpp.
  • rep Label has been blocked. It was never supposed to be allowed.
  • The first line of stdlib is no longer ignored. I forgot initializing a variable.
  • The fastrom command has been moved to set fastrom on.
  • Assembling is aborted if errors are detected, instead of continuing. As a side effect from this, errors are no longer printed twice or thrice.
  • I readded the base command. I still can't see any serious reason to use it, but I needed the functionality for spc700-inline, so I decided to allow it in other architectures as well.
  • Various other uninteresting changes.

<blm> zsnes users are the flatearthers of emulation
Yay, double post.
wiiqwertyuiop found a highly serious bug that makes various opcodes, for example JSR and TSB, break pretty badly. Here's the fixed version.
Changelog:
  • Added a missing else statement on the label optimizer disabling flag that made it turn it on, or get values that change in crappy ways, for everything.
I also got some other oddities when doing this, but fixing this bug made those symptoms go away, so I guess it's fixed.
<blm> zsnes users are the flatearthers of emulation
Yay, a week of loldead and another highly serious bug (and some minor junk).
  • How quickly Asar aborts if it finds errors can be set
  • Fixed some uninitialized value errors that created garbage error messages if the patch doesn't exist
  • autocolon now accepts db $20, $30
  • Putting a label in front of an opcode messed up earlier; this has been fixed
  • autoclean JSL.l is now valid
  • freecode forgot setting a few variables, which creates a bunch of errors if it's used
Yay.

Edit: Fixed relative forward branches in freespace too.
<blm> zsnes users are the flatearthers of emulation
This seems to shape up fairly nicely.

How long is the to-do list now anyways?
Originally posted by list
X remove DIEDIEDIE
X fix blank lines in macros
X make errors not abort macro assembling
X finish linux compile script
inspect try/catch in macro.cpp
print freespace size/pos/etc
block write to rom?
print dependencies
EX: rat tag protection syntax
rats tags protecting each other: instruction after a rats tag, tells that data at SNES $xxxxxx must be removed if this RATS tag is removed
EX: bigincbin syntax
bigincbin: includes a file and may cross bank borders
inconce: incsrc, but only if it hasn't been included earlier in this pass (must be sandboxed)
hijack everywhere
stderr
EX: block comment syntax
block comments
make internals know if size is known or guessed
block jml.w
warn on LDA $7E0060
EX: superfx opcode table
arch superfx
EX: cx4 opcode table
arch cx4
EX: more opcode tables
more architectures
EX: unsucky syntax for !a = eval(!a+1)
!a = eval(!a+1)
[redacted]

The Linux script is done, but it's only usable for AlcaRobot.

Also here's ANOTHER bugfix...
  • Removed the command DIEDIEDIE, a useless command that intentionally froze Asar if it's called from $088000 or later. It was probably useful for something a while ago, but... uuh...
  • Blank lines are now allowed in macros.
  • Broken or unknown macro arguments no longer abort assembling the rest of the macro.

Edit:
  • Asar will no longer no longer place rats tag at any part of the unexpanded area, not even if it's a long list of 00s
  • Fixed a bunch of odd bugs with the automatic size finder and label optimizer, including one that treated LDA.l Label,x as LDA.w Label,x
*sigh*

Edit2: I think labelopt is off in this stdlib. I'll fix it in the next version.

Edit3:
  • labelopt is no longer off (I forgot turning it on after a debugging session)
  • A lone { or } is now treated as a null command (for use with code folding). Note that they're not allowed elsewhere. They don't need to be matched.
  • autoclean no longer kills inappropriate data if pointed to an unused area. Operator precendence screwed up stuff.

<blm> zsnes users are the flatearthers of emulation
Sorry for interupting rather important stuff for asar (Updates, bugfixes etc.) but I would like to know If I could simply substitute xkas with asar? Or am I missing somethin?
It's supposed to work in most cases.
If it doesn't, post the code here and I'll see what's going on.
<blm> zsnes users are the flatearthers of emulation
Here's a suggestion that may or may not be useful/doable: optional Automatic backup.
Basically, it would make a copy of your rom, before applying the patch.
Of course, I can understand if not everybody wants this, so maybe you could make it some sort of option when patching
Quote
Asar patch.asm rom.smc -b
Or something like that
If you're using it from the command line, it's likely that you're using a batch file. In that case, why not add another line to the batch file?
Originally posted by example
copy super_smw_world.smc backup.smc
asar level.asm super_smw_world.smc
pause


Either way, here's a pretty big update.
  • set fastrom is now documented in stdlib.asm. I forgot it last time.
  • Opcodes that may or may not take an argument (INC, LSR, etc) now work better together with autocolon.
  • "Unknown command" errors have been edited.
  • Minor edits to the documentation.
  • The main attraction of this release: I added an xkas emulation mode, which makes Asar act a bit more like xkas 0.06. I think it's now 100% compatible with all our patches/sprites/etc; if not, contact me.
  • set resizable has been removed. I don't think it was ever useful for anything.
  • Asar can now fix the checksum.
  • The command line options have been edited a bit, including a few bugfixes.

<blm> zsnes users are the flatearthers of emulation
*insert crappy "forever alone" image*
  • if statements have been made much more powerful. The old action if the statement is false was skipping the rest of the line if the statement is false; the new action is skipping the rest of the line, or if the if statement is at the end of the line, it skips everything until an endif. Nested if statements are allowed, as are else statements. (Note that you can't use else on one-line if statements.)
  • autoclean now works if called from $008000.
  • autoclean now works if aiming for the last eight bytes of a RATS tag.
  • New command: prot. If used directly after a freecode or freedata command (that is, at the start of the RATS tag), it may contain a list of labels (up to 80 or something). The freespace blocks pointed to by these labels are removed if the freespace area is cleared by an autoclean. Example: org $008000 : autoclean JSL Main : freecode : prot Mydata : Main: LDA Mydata : RTL : freedata : Mydata: db $12,$34,$56,$78
  • autoclean now refuses to protect anything that isn't a label, for example math or constants, unless you're using the two-parameter method.
  • autoclean now refuses to protect a label at the end of a freespace block, since it'll think the RATS tag after that is the one that should be removed.
  • After reading the xkas documentation a bit, I noticed that labels may be defined as Main(), not just Main:. This has been noted in my documentation.
  • The biggest change: Asar can now be built as a DLL file. It's not tested very throughly, but it worked for everything I tested it on.
  • 'x' = $1234 is now a valid operation. It's equivalent to table file, but it accepts math and it's one file less to keep track of.
  • db 'x'+4 is now a valid operation.
  • db 1/Label : Label: is now accepted, instead of being treated as a division by zero.
  • freecode and freedata can now expand the ROM if needed.
  • !a equ $1234 is no longer valid. xkas has too many ugly synonyms for everything; I'm not sure why I supported this one in the first place.
  • !a = abc : !{a}def is now valid operation; it's equivalent to abcdef. You can nest defines inside the !{}s; a!{b!{c!def}g}h is accepted (assuming all defines exist). I knew there was a better way to use those braces than treating them as whitespace.
  • ($12),x is an error in xkas, since that addressing mode doesn't exist. However, Asar accepts parentheses and treats it as LDA $12,x, which isn't what the user meant. Therefore, I made it emit a warning if this happens.
Here it is.
<blm> zsnes users are the flatearthers of emulation
Jebus. Aside from the expanded if statement, I have no idea how any of these could be actually useful in any realistic case o.o

Though, may I suggest a simpler rats tag?
Something like "startrats" and "endrats"
And since you like to take extreme precautions, maybe even labeling them so one can use separate rats tags in one file.
"startrats firstR : code : endrats firstR : org somewhere else : startrats secondR : code : endrats secondR"
Originally posted by Sind
Jebus. Aside from the expanded if statement, I have no idea how any of these could be actually useful in any realistic case o.o

I can admit that some of them may be useless, but most are bugfixes or useful.
  • if statements have been made much more powerful. [...] → I made it for use with RPG Hacker's VWF tool, but it's not unlikely for it to be useful for other stuff.
  • autoclean now works if called from $008000. → Not much. Maybe some patches that want to run very early.
  • autoclean now works if aiming for the last eight bytes of a RATS tag. → Very short freespace blocks. It's not very likely to happen.
  • New command: prot. [...] → Getting rid of memory leaks in patches using more than 32KB freespace, for example the 32x32 Character Tilemap Kit.
  • autoclean now refuses to protect anything that isn't a label, [...] → May catch some strange mistakes. Not likely, but not impossible either.
  • autoclean now refuses to protect a label at the end of a freespace block, [...] → Not likely to be useful, but I don't want anyone to run into nasty surprises.
  • After reading the xkas documentation a bit, I noticed that labels may be defined as Main(), not just Main:. [...] → I want all differences to xkas documented. It's not really a change.
  • The biggest change: Asar can now be built as a DLL file. [...] → ASMPad
  • 'x' = $1234 is now a valid operation. [...] → It reduces the dependencies on external files, in case you care.
  • db 'x'+4 is now a valid operation. → Probably not useful, but it fits with the above one.
  • db 1/Label : Label: is now accepted, [...] → I ran into this in one of my patches. It saw labels that weren't defined yet, treated them as $000000, and tried to calculate (0-0)/(0-0) = 0/0 = error.
  • freecode and freedata can now expand the ROM if needed. → Most freespace-using patches.
  • !a equ $1234 is no longer valid. xkas has too many ugly synonyms for everything; [...] → Code cleanliness.
  • !a = abc : !{a}def is now valid operation; it's equivalent to abcdef. [...] → Very complicated codes that nobody except me uses.
  • ($12),x is an error in xkas, since that addressing mode doesn't exist. [...] → WYE stuck this into !ar as three hours ago. If I didn't tell him it's wrong, he might've tried using it, which would take a while to debug (he's one of the few Asar users around here).
The green are useful in at least one very specific situation I have found; yellow are useful only to me and/or entirely useless; blue are bugfixes (I don't want anyone to run into these bugs without knowing what's going on); the red is a removed feature. The stuff after the arrows is more detailed information on when this change may be useful.

Quote
Though, may I suggest a simpler rats tag?
Something like "startrats" and "endrats"
And since you like to take extreme precautions, maybe even labeling them so one can use separate rats tags in one file.
"startrats firstR : code : endrats firstR : org somewhere else : startrats secondR : code : endrats secondR"

I can not think of any situation where that would be superior to freecode or freedata in any way.

Edit: I must be drunk or something.
  • autoclean no longer complains if it attempts to overwrite something that isn't a valid SNES pointer.
http://bin.smwcentral.net/u/1686/asar.zip

Edit2:
  • The autoclean warning for the end of a freespace area has been fixed. Again.
  • The freespace finder no longer skips a RATS tag if it's preceeded by an unprotected 00.

<blm> zsnes users are the flatearthers of emulation
Why does a Muncher plushie get twice as many posts as this one in a sixth of the time?
  • You can now use if !condition to negate the statement. Note that you may need an extra set of parentheses due to conflicts with define syntax.
  • Parentheses can now be used inside macro arguments. (Just make sure to close them.)
  • If a relative branch is out of bounds, Asar no longer throws "labels keep moving around" errors.
  • Removed the strange size hex value warnings. They sounded like a good idea at the time, but they're just annoying.
  • Included a .NET version of asar.dll. Note that it still uses unmanaged types.
  • Asar now accepts org Label if the label is defined prior to use. (It's still not allowed to jump to a label that's defined later in the patch.)
http://bin.smwcentral.net/u/1686/asar.zip

Edit:
  • Removed more debug code
  • Fixed org Label if the label is in freespace

whee
<blm> zsnes users are the flatearthers of emulation
So, when are you going to submit this to the tools section? What is still to be done? That's really the only reason I haven't been using it.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
I'll submit it when I stop thinking up four new functions per week. I don't want to force people to download new tools too often.
The more testers, the quicker I can be sure that all bugs are dead, which leads to quicker submission to the tool section, which (for some odd reason) leads to more users. Circular dependency, yay.

And here's the new functions of this week-or-whatever:
  • if 0 now blocks label creation.
  • asar-cli.dll now exports a set of functions using .NET types instead of C types. Little information on Google + absolutely horrible syntax for changing between managed and unmanaged types + lots of misunderstandings between me and Iceguy = don't make me do that again.
  • The DLL APIs have been slightly changed with regards to initialization and stdlib.asm.
  • Asar now prints warnings and errors to stderr instead of stdout. (Emulation mode is unaffected.)
  • Repaired "branch out of bounds" errors. I wonder how I missed that.
http://bin.smwcentral.net/u/1686/asar.zip

Edit:
  • Fixed a bug that made + and - labels not be treated as labels under some circumstances.
  • Made "relative branch out of bounds" errors disappear again unless they're supposed to exist.
http://bin.smwcentral.net/u/1686/asar.zip
This is exactly the kind of bugs I want ironed out before I can submit Asar to anywhere.
(Note that asar-cli.dll::asarcli::Asar::patch is replaced with a test function. Iceguy said the old one was broken as well, and I was trying to debug it.)
<blm> zsnes users are the flatearthers of emulation
Would it be at all advantageous to include, along with the regular version, a "minimalist" version that lacks certain extra features, for the people who will never use them? I don't know how much of an effect all the new functions have on performance, but it's a thought. I suppose that might cause compatibility problems, though.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.