Language…
7 users online: Daizo Dee Von, Darolac, E623, Green, Guido_Keller, krizeth, Zavok - Guests: 233 - Bots: 251
Users: 64,795 (2,377 active)
Latest user: mathew

Asar: Under new management

(Edit: Tool renamed by request from Sind.)

For the last month, I have been working on a replacement for xkas. The goals with the project are no undocumented bugs, no bugs that will appear without intentionally trying to trigger them (that make-a-define-longer bug is annoying), removing all difficulties from using xkas (we've got an ungodly amount of threads asking how to set freespace and so on), and adding all features I've seen requested multiple times (for example parentheses and a freespace finder).

The features I expect everyone to like are the following:
  • Parentheses can be used, which allows some previously impossible statements and makes some others much less horrible.
  • Defines can be made longer without risk for crashes. This makes it much easier to implement Hijack Everywhere. I included a version of it in the ZIP file.
  • An if statement has been included, to get rid of the need for including those rep -1 tricks. They're ugly.
  • Freespace can be set automatically (it even includes a simple way to reclaim freespace used by older versions of the patch).
For the rest of the (known) changes, see changes.txt. Note that it's not finished yet - the command line switches mentioned in the usage aren't implemented, and it doesn't care about stdlib.asm yet. I want some feedback before submitting it to the tool section.

You can download it here. Please mangle it as much as possible and report all bugs here.

EDIT:
Tool now maintained by RPG Hacker and others. You can keep updated and contribute to development on GitHub:
https://github.com/RPGHacker/asar

another edit: You can get the latest beta version of Asar from here: exe, dll
These should be permalinks but if they break then yell at randomdude999
<blm> zsnes users are the flatearthers of emulation
ANOTHER assembler?!?! This is unexpected...at least, for me it is.

Well, I have a few questions:

- How exactly do you pronounce "a.as"? TRASM, chasm, and bass are obvious, and xkas can be pronounced as "ex-kass", but...
- Is a.as cross-platform?
- This may be obvious, but are all the xkas06-related bugs listed in your profile fixed in a.as?
- What command-line switches? I didn't see them mentioned anywhere.
- Do you plan on supporting any other architectures besides 65816 ASM (such as SPC-700 ASM)?
- Is there an option to disable the SMW ROM verification? You said that it wouldn't be a problem for homebrewers, but what about SMAS hackers and the like?
- Is it "autoclear" or "autoclean"? The documentation used them interchangeably.

In any case, this is pretty sweet, I must say. It's almost like a middle ground between xkas06 and bass, except without the odd bugs of the former or the funky formatting of the latter (no offense to byuu, but how could I not mention that?). Once you have completed it, I'd be more than willing to assist in a conversion project.

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by imamelia
How exactly do you pronounce "a.as"? TRASM, chasm, and bass are obvious, and xkas can be pronounced as "ex-kass", but...


I always say ex-kaz... but anyway I assume it's ay-as, either that or just ignore the period.

...

...

ass!

Originally posted by imamelia
Once you have completed it, I'd be more than willing to assist in a conversion project.


Conversion project? I thought it was a replacement for xkas. It shouldn't need a conversion project should it?

Originally posted by imamelia
Is there an option to disable the SMW ROM verification? You said that it wouldn't be a problem for homebrewers, but what about SMAS hackers and the like?


I agree with this. In addition, I don't know why hirom support was removed, and the free space finder should be written so the user can specify the area of the rom to check. Even if your primary concern is SMW roms, I think making the assembler as general as possible is a good idea. I question some of the way the freespace finder works in general really. It's a good feature, but I think it should be done in a way that is more general, even if it means no autoclear. Autoclear is probably best done by automatically creating before/after patches like antixkas and keeping logs of what gets applied. Or maybe that's what happens, I donno.

I am not sure I like the idea of forced address optimization. I think the size used should ALWAYS be the size inputed, at least as an option. If someone says LDA $000019 it should be a long address regardless if it could be smaller. It is not the assembler's job to optimize for you. Then again, I guess that's what .b .w and .l are for.

I probably nitpick more, but it seems neat anyway.
Your layout has been removed.
Originally posted by imamelia
ANOTHER assembler?!?!

...what, do you think we have too many?
I can remove xkas from the tool section if it makes you happier.

Quote
This is unexpected...at least, for me it is.

Yeah, I haven't really been public with it. I didn't want to get people's hope up and then disappoint them.

Quote
- How exactly do you pronounce "a.as"? TRASM, chasm, and bass are obvious, and xkas can be pronounced as "ex-kass", but...

I just read out each character ("ay dot ay ess"), but I don't really care if someone does it differently.

Quote
- Is a.as cross-platform?

Yes, it will work fine on Linux. I've run it under Valgrind many times.
I don't know if it works on Macs, but I don't see any reason why it'd break.

Quote
- This may be obvious, but are all the xkas06-related bugs listed in your profile fixed in a.as?

It's a ground-up rewrite. I don't think they've reappeared.

Quote
- What command-line switches? I didn't see them mentioned anywhere.

Type "aas a b c" on the command line and it'll appear.
Either way, they've been implemented for the next version.

Quote
- Do you plan on supporting any other architectures besides 65816 ASM (such as SPC-700 ASM)?

It's not in my idea list, but I guess I could try if you give me an opcode list.

Quote
- Is there an option to disable the SMW ROM verification? You said that it wouldn't be a problem for homebrewers, but what about SMAS hackers and the like?

-v on the command line (when I release the next version), or just double click it and say "y" when it asks what to do.
I should probably create a "defaults.txt" file that can override some of a.as's defaults ... or maybe I should put that in stdlib.asm?

Quote
- Is it "autoclear" or "autoclean"? The documentation used them interchangeably.

The official name is autoclean. *fixes documentation*
...actually, I might as well make both valid. It's easy enough to get confused.

Originally posted by KilloZapit
I always say ex-kaz... but anyway I assume it's ay-as, either that or just ignore the period.

...

...

ass!

Very funny.

Quote
Conversion project? I thought it was a replacement for xkas. It shouldn't need a conversion project should it?

Just because it's xkas-like doesn't mean the smartest way to use it is giving it unmodified xkas patches. Some of the patches has no need for any of the new features, but 80% of them uses freespace, and there's no point not using this freespace finder (as I said earlier, I don't know how many crashes we've had from people trying to shoehorn stuff into 7-byte freespaces).
Besides, some of the more obscure xkas tricks will break (see changelog for details).

Quote
I don't know why hirom support was removed

It messes up the "you crossed a bank border" error, and would require editing various other codes.
...Whatever, I guess I could try. Find a table telling which areas point to ROM and which points elsewhere, and find at least one situation where this would be useful, and I'll see if I can do it.

Guess: Nobody would've noticed if I didn't put it in the changelog.

Quote
and the free space finder should be written so the user can specify the area of the rom to check

...uh? What do you mean and how would that be useful?

Quote
even if it means no autoclear

ROM space waste = bad. I will not remove autoclean.

Quote
Autoclear is probably best done by automatically creating before/after patches like antixkas and keeping logs of what gets applied.

It deletes the RATS tag and its contents.

Quote
I am not sure I like the idea of forced address optimization.

The only optimization a.as does that xkas doesn't do is 24bit->16bit label access, which I have seen users complain about xkas doing weirdly. Optimizing $000019 to $19 would indeed be dumb.
Might as well edit the changelog so it's unambigous.
<blm> zsnes users are the flatearthers of emulation
Originally posted by Alcaro
Originally posted by imamelia
ANOTHER assembler?!?!

...what, do you think we have too many?
I can remove xkas from the tool section if it makes you happier.

Don't do that, though maybe putting the * mark in front of a.as and not xkas would be best.

Originally posted by Alcaro
Quote
- Do you plan on supporting any other architectures besides 65816 ASM (such as SPC-700 ASM)?

It's not in my idea list, but I guess I could try if you give me an opcode list.

Maybe doing what bass does and just have user definable lists would work better for that, but then that would probably take more work then it's worth.

Originally posted by Alcaro
Quote
- Is there an option to disable the SMW ROM verification? You said that it wouldn't be a problem for homebrewers, but what about SMAS hackers and the like?

-v on the command line (when I release the next version), or just double click it and say "y" when it asks what to do.
I should probably create a "defaults.txt" file that can override some of a.as's defaults ... or maybe I should put that in stdlib.asm?

How does it check anyway? Internal rom name? It might be best to move it to a setting in something like stdlib.asm but honestly the whole stdlib.asm idea sounds kinda iffy. I mean, it's a nice idea to include some shared code library, but I think it's better if the user has to explicitly include it.

Also that reminds me that I am not sure if I like including files in the current included file's path. I don't think most programing languages work that way, and old xkas didn't. It's just bound to cause confusion. I see the point of it, but I think it's too much of a bother. I guess you could have it both ways where if it fails to find the file one way it checks the other.

Originally posted by Alcaro
Quote
Conversion project? I thought it was a replacement for xkas. It shouldn't need a conversion project should it?

Just because it's xkas-like doesn't mean the smartest way to use it is giving it unmodified xkas patches. Some of the patches has no need for any of the new features, but 80% of them uses freespace, and there's no point not using this freespace finder (as I said earlier, I don't know how many crashes we've had from people trying to shoehorn stuff into 7-byte freespaces).
Besides, some of the more obscure xkas tricks will break (see changelog for details).

I am mostly apprehensive about forced conversion to a unfinished and unproven new program. Suddenly replacing working patches with ones that require a new program that has not yet reached the level of acceptance or even has a finalized feature set is a bad idea. As for xkas tricks, does anyone actually use them? I mean seriously I never heard of most of the odd practices you talk about in the changelog and the ones I did hear about are pretty silly.

Originally posted by Alcaro
Quote
I don't know why hirom support was removed

It messes up the "you crossed a bank border" error, and would require editing various other codes.
...Whatever, I guess I could try. Find a table telling which areas point to ROM and which points elsewhere, and find at least one situation where this would be useful, and I'll see if I can do it.

Guess: Nobody would've noticed if I didn't put it in the changelog.

It might be a good idea to look into using bsnes's XML mappings actually. I think there are default loram/hiram maps and also exloram and more exotic maps would be supported by default. Other then that, here is a doc that tries to explain the mappings.

As for a situation where it would be useful, it's for homebrew or non-smw hacking of course.

Originally posted by Alcaro
Quote
and the free space finder should be written so the user can specify the area of the rom to check

...uh? What do you mean and how would that be useful?

If you are checking the rom for unprotected freespace using RATS tags, surly it doesn't look in the original SMW code/data. Unless you actually search for empty space by areas filled with zero or something. Either way, it's generally a good idea to restrict searches in areas of the rom you know are not used. Most SMW programs just know the size of the original rom and mark all space beyond that as free too look for freespace in. I just ask for a way to specify where that space begins, and optionally where it ends might be useful too.

Originally posted by Alcaro
Quote
even if it means no autoclear

ROM space waste = bad. I will not remove autoclean.

Quote
Autoclear is probably best done by automatically creating before/after patches like antixkas and keeping logs of what gets applied.

It deletes the RATS tag and its contents.

It's just that the freespace finder and autoclean don't really seem like assembler functions. They seem like an attempt of making a "patchtool" in the same tradition of spritetool and blocktool. Which honestly, is fine with me I guess. I even suggested a similar sort of approach with Tessera.

The trouble I see with that approach though, is that patches are NOT reverted or cleaned. If you fiddle with patches and hijacks when repatching the same asm, you still run into a situation where you can't trust exactly what you are doing. It might be a good idea to add a way to check an addresses's contents to make sure it is what the patch expects it is, but I am not sure how to do that and allow the same patch to be applied multiple times without failing.

It just seems like it would be much easier to manage if the assembler keept all of the writes it did when patching a file (a romname.patchname.log file maybe) and reversed it.

Honestly, if people would just keep their rom clean and patch fresh to a copy every time they change anything like I do, half of this wouldn't be a problem... but that's obviously not how people do things so eh.

Though I am sort of curious how the freespace finder and autoclean work. I assume the finder takes a block of code and finds where to best put it, writing the rats stuff automatically with some signature that is used to find it again, right?

Originally posted by Alcaro
Quote
I am not sure I like the idea of forced address optimization.

The only optimization a.as does that xkas doesn't do is 24bit->16bit label access, which I have seen users complain about xkas doing weirdly. Optimizing $000019 to $19 would indeed be dumb.
Might as well edit the changelog so it's unambigous.

So it only effects jumps within the same bank and stuff like that?
Your layout has been removed.
Originally posted by KilloZapit
Also that reminds me that I am not sure if I like including files in the current included file's path. I don't think most programing languages work that way

Yes, they do. #include "red/red.h" will include the file "red.h" the in the directory "red" as relative to the current file's position, and an include within "red.h" would look for that include in it's directory. If it didn't work like that, #include <Python.h> wouldn't work.

Originally posted by KilloZapit
and old xkas didn't

Yes, and it was the cause of a lot of annoyance (Namely that you couldn't "install" xkas because it had to be run in the directory with the file, which meant you needed a whole lot of copies).
Originally posted by KilloZapit
Originally posted by Alcaro
Originally posted by imamelia
ANOTHER assembler?!?!

...what, do you think we have too many?
I can remove xkas from the tool section if it makes you happier.

Don't do that, though maybe putting the * mark in front of a.as and not xkas would be best.

That comment wasn't seriously meant, but you're right in that we should only have one featured assembler.

Quote
Originally posted by Alcaro
Quote
- Do you plan on supporting any other architectures besides 65816 ASM (such as SPC-700 ASM)?

It's not in my idea list, but I guess I could try if you give me an opcode list.

Maybe doing what bass does and just have user definable lists would work better for that, but then that would probably take more work then it's worth.

bass doesn't allow user-defined opcode tables. Are you thinking of something else?
If you're thinking of allowing multiple architectures with the same tool, that's the only solution I'm going to consider.

Quote
Originally posted by Alcaro
Quote
- Is there an option to disable the SMW ROM verification? You said that it wouldn't be a problem for homebrewers, but what about SMAS hackers and the like?

-v on the command line (when I release the next version), or just double click it and say "y" when it asks what to do.
I should probably create a "defaults.txt" file that can override some of a.as's defaults ... or maybe I should put that in stdlib.asm?

How does it check anyway? Internal rom name?

Correct.
Guess: You're going to find a reason why this is a horrible idea.

Quote
It might be best to move it to a setting in something like stdlib.asm but honestly the whole stdlib.asm idea sounds kinda iffy. I mean, it's a nice idea to include some shared code library, but I think it's better if the user has to explicitly include it.

...and the advantage of a shared library if it's not universally accessible is...?
If you don't like it, leave it blank and use db _sqrt(9) as much as you want.

Quote
Also that reminds me that I am not sure if I like including files in the current included file's path. I don't think most programing languages work that way, and old xkas didn't. It's just bound to cause confusion. I see the point of it, but I think it's too much of a bother. I guess you could have it both ways where if it fails to find the file one way it checks the other.

...how does including a file from a folder other than the one with the current file make sense?
If anything, the macro handling is screwy, but doing it the other way (relative to the caller) would be just as screwy.

Quote
Originally posted by Alcaro
Quote
Conversion project? I thought it was a replacement for xkas. It shouldn't need a conversion project should it?

Just because it's xkas-like doesn't mean the smartest way to use it is giving it unmodified xkas patches. Some of the patches has no need for any of the new features, but 80% of them uses freespace, and there's no point not using this freespace finder (as I said earlier, I don't know how many crashes we've had from people trying to shoehorn stuff into 7-byte freespaces).
Besides, some of the more obscure xkas tricks will break (see changelog for details).

I am mostly apprehensive about forced conversion to a unfinished and unproven new program. Suddenly replacing working patches with ones that require a new program that has not yet reached the level of acceptance or even has a finalized feature set is a bad idea.

That's why I'm posting this here instead of submitting it to the tool section. When (if) everyone here agrees that this is superior to xkas, I'll ask for opinions in Announcements. I don't want to repeat the Addmusic fiasco.

Quote
As for xkas tricks, does anyone actually use them? I mean seriously I never heard of most of the odd practices you talk about in the changelog and the ones I did hear about are pretty silly.

The ones in my known bugs list are nothing anyone would run into, but the define resize bug has genuinely blocked some stuff I wanted to do, and both me and RPG Hacker uses the rep -1 trick.

Quote
Originally posted by Alcaro
Quote
I don't know why hirom support was removed

It messes up the "you crossed a bank border" error, and would require editing various other codes.
...Whatever, I guess I could try. Find a table telling which areas point to ROM and which points elsewhere, and find at least one situation where this would be useful, and I'll see if I can do it.

Guess: Nobody would've noticed if I didn't put it in the changelog.

It might be a good idea to look into using bsnes's XML mappings actually. I think there are default loram/hiram maps and also exloram and more exotic maps would be supported by default. Other then that, here is a doc that tries to explain the mappings.

Good point.
...except it's called LoROM, not LoRaM

Quote
As for a situation where it would be useful, it's for homebrew or non-smw hacking of course.

Good point. I'll see how much breakage I'll get if I do that.

Quote
Originally posted by Alcaro
Quote
and the free space finder should be written so the user can specify the area of the rom to check

...uh? What do you mean and how would that be useful?

If you are checking the rom for unprotected freespace using RATS tags, surly it doesn't look in the original SMW code/data. Unless you actually search for empty space by areas filled with zero or something. Either way, it's generally a good idea to restrict searches in areas of the rom you know are not used. Most SMW programs just know the size of the original rom and mark all space beyond that as free too look for freespace in. I just ask for a way to specify where that space begins, and optionally where it ends might be useful too.

I look for an all-00 and RATS-free area in bank $10 or higher. It should work for all non-256KB ROMs, and I'm pretty sure that's all of them.

Originally posted by Alcaro
Quote
Autoclear is probably best done by automatically creating before/after patches like antixkas and keeping logs of what gets applied.

It deletes the RATS tag and its contents.

It's just that the freespace finder and autoclean don't really seem like assembler functions. They seem like an attempt of making a "patchtool" in the same tradition of spritetool and blocktool. Which honestly, is fine with me I guess. I even suggested a similar sort of approach with Tessera.</div></div>
The primary intent is to make it easier for the user.

Quote
The trouble I see with that approach though, is that patches are NOT reverted or cleaned. If you fiddle with patches and hijacks when repatching the same asm, you still run into a situation where you can't trust exactly what you are doing. It might be a good idea to add a way to check an addresses's contents to make sure it is what the patch expects it is, but I am not sure how to do that and allow the same patch to be applied multiple times without failing.

Except patches ARE cleaned. That's exactly what autoclean does.
If you want to know where it is, I kept print pc from xkas.

Quote
It just seems like it would be much easier to manage if the assembler keept all of the writes it did when patching a file (a romname.patchname.log file maybe) and reversed it.

I see no reason why a JSL from a known location wouldn't be enough to find it.
Freespace blocks only referenced from inside other freespaces would indeed be annoying, but it's solvable with a bunch of dl's at the start of the main freespace and some read3()s.

Quote
Honestly, if people would just keep their rom clean and patch fresh to a copy every time they change anything like I do, half of this wouldn't be a problem... but that's obviously not how people do things so eh.

I do like that.
...But yeah, 99% of us does not do like that.

Quote
Though I am sort of curious how the freespace finder and autoclean work. I assume the finder takes a block of code and finds where to best put it, writing the rats stuff automatically with some signature that is used to find it again, right?

It does contain a RATS tag, but it does not contain a signature. I consider autoclean enough to find it again.

Quote
Originally posted by Alcaro
Quote
I am not sure I like the idea of forced address optimization.

The only optimization a.as does that xkas doesn't do is 24bit->16bit label access, which I have seen users complain about xkas doing weirdly. Optimizing $000019 to $19 would indeed be dumb.
Might as well edit the changelog so it's unambigous.

So it only effects jumps within the same bank and stuff like that?

I have no multisize jump opcodes (not even JMP.l).
However, it does what you describe for LDA/etc.

Honestly, I'm not sure if you're interested in helping this project at all. Half of your ideas just seem totally counterproductive (allowing memory leaks or forcing people to keep using slogger everywhere? Not gonna happen.), and I'm not entirely sure if the rest are useful in any serious context.

Edit: Fixed some odd broken BBCode. I wonder why it jumped down to my signature like that.
<blm> zsnes users are the flatearthers of emulation
I guess "neat" is all I can say at the moment ._.
It certainly did come as a surprise :V


Also: Here's something useless I just thought of: definitions math!
I have absolutely no idea what this could be used for, or if it would be any useful at all, but I'll throw it out there anyways =D
Basically, definitions math would be a way to change definitions mid-code.
For example, if you have
Code
!asdf = #$24

++!asdf 30

!asdf would now equal 50(or $32 if you will)

The only place I can actually see this being used is together with if functions, since you otherwise can simply use !asdf+30.

And then I don't have anything of actual value to add, though I'll admit I find a.as to be a horrible name <.<
Originally posted by Sind
!asdf = #$24

++!asdf 30

I can't figure out how $2430 or $24+30 would be 50, but I'll add !asdf += +1 to append some stuff to a define if it makes you happier (actually, I've been doing this a few times in my own patches, for example Hijack Everywhere). ++!asdf 30 just looks weird.

Quote
though I'll admit I find a.as to be a horrible name <.<

I couldn't think of a better name, but yeah, it is a bit weird.

(Note that the rest of this post was written before seeing Sind's post.)
Might as well release this one.
Changelog:
• It now looks for and assembles stdlib.asm. However, it prints an error if it doesn't find it (I think it even refuses to continue assembling anything, I'll make it fail more gracefully in the next version).
• Expected ROM title can now be set, see stdlib.asm for details. It defaults to SUPER MARIOWORLD if omitted, and it may not be set outside of stdlib.asm.
• A 64-bit version has been included. I don't know why it's twice the size of the 32bit one, nor do I know which is faster. They're supposed to act identically.
• Both autoclean and autoclear works now. They act identically.
• Probably a bunch of minor details I'm forgetting.
<blm> zsnes users are the flatearthers of emulation
Err, yes, I meant #$14

As for name ideas: maybe "alcas", "Asar", "asmA", or just for shits and giggles, "org-ASM"
Originally posted by Sind
Err, yes, I meant #$14

Then it would indeed be 50.
Either way, the feature has been added. It'll appear in the next release.

Hm. Here's a similar idea.
Code
!a = 1
!a = eval(!a+1)
!a = eval(!a+1)
!a = eval(!a+1)
;At this point, !a is exactly "4". No "1+1+1+1" or something like that.

Should I allow this?

And the name ideas, sorted after how much I like the ideas, from worst to best:
Quote
org-ASM

It was funny the first 10 times. It is not funny the 100th time, and if I do pick that one, it will not be funny the 1000th time either.

Quote
alcas

Too similar to my nick. It makes me sound like a megalomanic attention whore, or something like that.
...which technically is true, but I don't want to show that in too obvious ways.

Quote
asmA

Sounds dumb somehow.

Quote
Asar

But I like this one. If I like it tomorrow (likely), the official name of this tool is Asar.
<blm> zsnes users are the flatearthers of emulation
Originally posted by HuFlungDu
Originally posted by KilloZapit
Also that reminds me that I am not sure if I like including files in the current included file's path. I don't think most programing languages work that way

Yes, they do. #include "red/red.h" will include the file "red.h" the in the directory "red" as relative to the current file's position, and an include within "red.h" would look for that include in it's directory. If it didn't work like that, #include <Python.h> wouldn't work.


Most programing languages have multiple search paths and multiple files. Of course in C++ a .cpp file will search the current directory but I don't think a included .h file would. Python I have no idea. But an include directive mostly just dumps whatever is in the included file into the current file. That's why it searches the root file, because as far as the assembler knows, that's the current file. If that should change it should search both at least.

Originally posted by HuFlungDu
Originally posted by KilloZapit
and old xkas didn't

Yes, and it was the cause of a lot of annoyance (Namely that you couldn't "install" xkas because it had to be run in the directory with the file, which meant you needed a whole lot of copies).


I have no idea what you are talking about here. If your saying it will only search the path where the xkas.exe is, that is definitely a problem. But that's not what I am talking about. I am talking about include changing the directory. Really it's a nitpick, but it's one that is bound to have unforeseen consequences.

Originally posted by Alcaro
If you're thinking of allowing multiple architectures with the same tool, that's the only solution I'm going to consider.

Well yeah. Doesn't bass use user-defined opcode tables for that?

Originally posted by Alcaro

Quote
How does it check anyway? Internal rom name?

Correct.
Guess: You're going to find a reason why this is a horrible idea.

Well, LM does allow you to change the internal rom name, but it's so rarely used I think it's mostly an acceptable way to do it. I think a way to set what name to check for is a good idea though.

Originally posted by Alcaro
Quote
It might be best to move it to a setting in something like stdlib.asm but honestly the whole stdlib.asm idea sounds kinda iffy. I mean, it's a nice idea to include some shared code library, but I think it's better if the user has to explicitly include it.

...and the advantage of a shared library if it's not universally accessible is...?
If you don't like it, leave it blank and use db _sqrt(9) as much as you want.

My reasoning is this: If it's a user defined library, which it looks like it is, people are bound to add code to it and it will need to be distributed with patches, which totally defeats the point of having a standard library because everyone is using a different one. If it's not a user defined file, and is filled with things people might find handy but most will never use, it's just going to take up extra time to parse that people don't need to waste. I mean, it's a nice idea to have a shared library in some projects, but that is what the include function is for. On the other hand, stdlib.asm is a good place to put default any assembler settings that can be overwritten later, like what rom name to check for, freespace settings, what arch to use, or stuff like that.

Originally posted by Alcaro
Quote
Also that reminds me that I am not sure if I like including files in the current included file's path. I don't think most programing languages work that way, and old xkas didn't. It's just bound to cause confusion. I see the point of it, but I think it's too much of a bother. I guess you could have it both ways where if it fails to find the file one way it checks the other.

...how does including a file from a folder other than the one with the current file make sense?
If anything, the macro handling is screwy, but doing it the other way (relative to the caller) would be just as screwy.

It's just that in my experience included files usually are not treated as a different file from the one that included it accept for error reporting. Really the difference is moot, but I for one use paths that expect it. It isn't really a big deal though, I don't have that many nested includes anyway. It's just something to think about.

Originally posted by Alcaro
I look for an all-00 and RATS-free area in bank $10 or higher. It should work for all non-256KB ROMs, and I'm pretty sure that's all of them.

I am not sure if most utils actually bother with zero filling though, but that is probably not that big of a deal as a number of tools don't check if free space is zero filled either.

Originally posted by Alcaro
Quote
The trouble I see with that approach though, is that patches are NOT reverted or cleaned. If you fiddle with patches and hijacks when repatching the same asm, you still run into a situation where you can't trust exactly what you are doing. It might be a good idea to add a way to check an addresses's contents to make sure it is what the patch expects it is, but I am not sure how to do that and allow the same patch to be applied multiple times without failing.

Except patches ARE cleaned. That's exactly what autoclean does.
If you want to know where it is, I kept print pc from xkas.

Oh? So it does keep track of all changes to a file? I am not sure what print pc has to do with it.

Originally posted by Alcaro
Quote
It just seems like it would be much easier to manage if the assembler keept all of the writes it did when patching a file (a romname.patchname.log file maybe) and reversed it.

I see no reason why a JSL from a known location wouldn't be enough to find it.
Freespace blocks only referenced from inside other freespaces would indeed be annoying, but it's solvable with a bunch of dl's at the start of the main freespace and some read3()s.

So do you mark JSL's somehow then? What about JML? Keep track of the labels in freespace? I am not sure why, if autoclean reverses patches, it doesn't reverse freespace too though. Unless autoclean just copies from the original rom or something.

Originally posted by Alcaro
I have no multisize jump opcodes (not even JMP.l).
However, it does what you describe for LDA/etc.
But only for labels? It seems to me assuming what data bank you are in is a bad idea. There are times it's just easier to load from a explicit bank then mess around with them. But again, I guess that's what .l is for.

Originally posted by Alcaro
Honestly, I'm not sure if you're interested in helping this project at all. Half of your ideas just seem totally counterproductive (allowing memory leaks or forcing people to keep using slogger everywhere? Not gonna happen.), and I'm not entirely sure if the rest are useful in any serious context.

I think I just have different goals in mind. I have no idea what memory leaks have to do with it though, and I do not at all think freespace finding is a bad idea.

I am just a bit confused and unsure about your methods, because they are different from the way I would do it. And maybe the way I would do it is not the best way. From what I can figure out, you use labels in patches (in the context of patching the original code) to find out where the freespace is, and delete it, which is fine on it's own, but leaves the patches in the rom (which mostly get overwritten anyway to be fair). Then you say autoclean takes care of these patches (I assume in the same context), but the only way for autoclean to do that is to remember what was patched last time (because you can add and delete patches) and if it remembers that, why dosn't it remember what it put in freespace?

If you think I am being needlessly negative and nitpicky it's only because I care about such things. These are great features, but I think you are doing them in a slightly problematic way.
Your layout has been removed.
Originally posted by KilloZapit
Originally posted by HuFlungDu
Originally posted by KilloZapit
Also that reminds me that I am not sure if I like including files in the current included file's path. I don't think most programing languages work that way

Yes, they do. #include "red/red.h" will include the file "red.h" the in the directory "red" as relative to the current file's position, and an include within "red.h" would look for that include in it's directory. If it didn't work like that, #include <Python.h> wouldn't work.


Most programing languages have multiple search paths and multiple files. Of course in C++ a .cpp file will search the current directory but I don't think a included .h file would. Python I have no idea. But an include directive mostly just dumps whatever is in the included file into the current file. That's why it searches the root file, because as far as the assembler knows, that's the current file. If that should change it should search both at least.

Originally posted by HuFlungDu
Originally posted by KilloZapit
and old xkas didn't

Yes, and it was the cause of a lot of annoyance (Namely that you couldn't "install" xkas because it had to be run in the directory with the file, which meant you needed a whole lot of copies).


I have no idea what you are talking about here. If your saying it will only search the path where the xkas.exe is, that is definitely a problem. But that's not what I am talking about. I am talking about include changing the directory. Really it's a nitpick, but it's one that is bound to have unforeseen consequences.

I checked how C++ does it. The result is that #include is relative to the current directory, not the directory with the C++ file. Test it yourself if you don't trust me.
If C++, HuFlungDu and myself says the same thing, then I belive we're right. Your idea may make sense for you, but it does not make sense to me.
Let's just conclude that we disagree and leave it at that.

Quote
Originally posted by Alcaro
If you're thinking of allowing multiple architectures with the same tool, that's the only solution I'm going to consider.

Well yeah. Doesn't bass use user-defined opcode tables for that?

...what? First imamelia thinks that, and now you think that too?
Tell me how this is user-defined in any way.

Quote
Originally posted by Alcaro
Quote
How does it check anyway? Internal rom name?

Correct.
Guess: You're going to find a reason why this is a horrible idea.

Well, LM does allow you to change the internal rom name, but it's so rarely used I think it's mostly an acceptable way to do it. I think a way to set what name to check for is a good idea though.

Yes, that is an acceptable compromise. I implemented that yesterday (the default is still SUPER MARIOWORLD, but it's documented in stdlib.asm so that shouldn't be a problem).

Quote
Originally posted by Alcaro
Quote
It might be best to move it to a setting in something like stdlib.asm but honestly the whole stdlib.asm idea sounds kinda iffy. I mean, it's a nice idea to include some shared code library, but I think it's better if the user has to explicitly include it.

...and the advantage of a shared library if it's not universally accessible is...?
If you don't like it, leave it blank and use db _sqrt(9) as much as you want.

My reasoning is this: If it's a user defined library, which it looks like it is, people are bound to add code to it and it will need to be distributed with patches, which totally defeats the point of having a standard library because everyone is using a different one. If it's not a user defined file, and is filled with things people might find handy but most will never use, it's just going to take up extra time to parse that people don't need to waste. I mean, it's a nice idea to have a shared library in some projects, but that is what the include function is for. On the other hand, stdlib.asm is a good place to put default any assembler settings that can be overwritten later, like what rom name to check for, freespace settings, what arch to use, or stuff like that.

So what you're saying is person A adds code A to file 1, person B adds code B to file 1, person C wants to use one patch made by person A (requires file A) and one by person B (requires file B), and neither file A nor file B accepts anything made by the other?
That could indeed be annoying. Proposed solution: Official stdlibs are released only by a trusted user working off the latest one.

Quote
Originally posted by Alcaro
Quote
Also that reminds me that I am not sure if I like including files in the current included file's path. I don't think most programing languages work that way, and old xkas didn't. It's just bound to cause confusion. I see the point of it, but I think it's too much of a bother. I guess you could have it both ways where if it fails to find the file one way it checks the other.

...how does including a file from a folder other than the one with the current file make sense?
If anything, the macro handling is screwy, but doing it the other way (relative to the caller) would be just as screwy.

It's just that in my experience included files usually are not treated as a different file from the one that included it accept for error reporting. Really the difference is moot, but I for one use paths that expect it. It isn't really a big deal though, I don't have that many nested includes anyway. It's just something to think about.

Answered earlier.

Quote
Originally posted by Alcaro
I look for an all-00 and RATS-free area in bank $10 or higher. It should work for all non-256KB ROMs, and I'm pretty sure that's all of them.

I am not sure if most utils actually bother with zero filling though, but that is probably not that big of a deal as a number of tools don't check if free space is zero filled either.

I consider all tools that don't check for 00s horribly broken.
You don't need to agree, but I find it better to skip a usable freespace than breaking something. Besides, unprotected and unused areas are very rare - much rarer than protected and unused ones or unprotected and used.

Quote
Originally posted by Alcaro
Quote
The trouble I see with that approach though, is that patches are NOT reverted or cleaned. If you fiddle with patches and hijacks when repatching the same asm, you still run into a situation where you can't trust exactly what you are doing. It might be a good idea to add a way to check an addresses's contents to make sure it is what the patch expects it is, but I am not sure how to do that and allow the same patch to be applied multiple times without failing.

Except patches ARE cleaned. That's exactly what autoclean does.
If you want to know where it is, I kept print pc from xkas.

Oh? So it does keep track of all changes to a file? I am not sure what print pc has to do with it.

print pc is irrelevant. It just tells the user where in the ROM it is, it doesn't do anything this tool cares about. I just added it since some users like it.
(It can be used for debugging freespace overruns (if you're replacing a routine and not using expanded-area freespace), but that's not relevant. (Besides, warnpc is better.))

Quote
Originally posted by Alcaro
Quote
It just seems like it would be much easier to manage if the assembler keept all of the writes it did when patching a file (a romname.patchname.log file maybe) and reversed it.

I see no reason why a JSL from a known location wouldn't be enough to find it.
Freespace blocks only referenced from inside other freespaces would indeed be annoying, but it's solvable with a bunch of dl's at the start of the main freespace and some read3()s.

So do you mark JSL's somehow then? What about JML? Keep track of the labels in freespace? I am not sure why, if autoclean reverses patches, it doesn't reverse freespace too though. Unless autoclean just copies from the original rom or something.

For the 1/0th time, it does not add any housekeeping data in the ROM. Both JSL and JML will work fine for this.
...urgh. I'll just draw some crappy tables.
Let's assume the ROM is 64 bytes. The first 16 bytes are the original ROM, and the next 48 are freespace that this tool looks in.
A5 19 85 80 AF F6 06 00 20 FF FF 1A 1A 3A 3A 6B
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

(I know it's garbage, but that's not relevant.)
The patch wants to place a JSL at the start of the ROM.
Code
org $008000
autoclean JSL Mymain

freecode
Mymain:
LDA $19
INC A
STA $80
STZ $19
RTL

The assembler sees an autoclean, but there's no JSL in the ROM, so it ignores it and assembles the JSL normally.

22 18 80 00 AF F6 06 00 20 FF FF 1A 1A 3A 3A 6B
53 54 41 52 07 00 F8 FF A5 19 1A 86 80 64 19 6B
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


Now the user wants to edit and reinsert the patch.
Code
org $008000
autoclean JSL Mymain

freecode
Mymain:
LDA $19
INC A
STA $80
STZ $14
RTL

Now, the assembler sees that the autoclean contains a JSL - and the ROM does as well! It responds by removing (00ing out) the RATS tag and its contents. It does not try to repair the JSL, it just assumes it'll get reoverwritten. It's not designed to be 100% failproof.
22 18 80 00 AF F6 06 00 20 FF FF 1A 1A 3A 3A 6B
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Then it assembles the patch. (In reality, I think it may ignore autocleaned freespaces (it'll use them next time), but that shouldn't matter.)
The resulting ROM is as follows:
22 18 80 00 AF F6 06 00 20 FF FF 1A 1A 3A 3A 6B
53 54 41 52 07 00 F8 FF A5 19 1A 86 80 64 14 6B
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00


There, that should be unambigous.

Quote
Originally posted by Alcaro
I have no multisize jump opcodes (not even JMP.l).
However, it does what you describe for LDA/etc.

But only for labels? It seems to me assuming what data bank you are in is a bad idea. There are times it's just easier to load from a explicit bank then mess around with them. But again, I guess that's what .l is for.

If you're going to use B!=K, then you will indeed need .l. I've seen lots of complaints on xkas doing this weirdly, so I'm going to fix it.
I did indeed get a few odd bugs from fixing this, but two .l's is a smaller pain than 40 .w's or unoptimal code.

Quote
Originally posted by Alcaro
Honestly, I'm not sure if you're interested in helping this project at all. Half of your ideas just seem totally counterproductive (allowing memory leaks or forcing people to keep using slogger everywhere? Not gonna happen.), and I'm not entirely sure if the rest are useful in any serious context.

I think I just have different goals in mind. I have no idea what memory leaks have to do with it though, and I do not at all think freespace finding is a bad idea.

If we take our nonsense ROM from before, remove the autoclean from the patch, and reassemble it, it'd look like this:
22 28 80 00 AF F6 06 00 20 FF FF 1A 1A 3A 3A 6B
53 54 41 52 07 00 F8 FF A5 19 1A 86 80 64 19 6B
53 54 41 52 07 00 F8 FF A5 19 1A 86 80 64 14 6B
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Note that there's 16 bytes wasted here. This is known as a memory leak (or freespace leak in this case, since it's not RAM). While wasting 33% of the ROM space with one patch is unlikely in any serious context, it could add up if you're inserting large patches many times.

Quote
I am just a bit confused and unsure about your methods, because they are different from the way I would do it. And maybe the way I would do it is not the best way. From what I can figure out, you use labels in patches (in the context of patching the original code) to find out where the freespace is, and delete it, which is fine on it's own, but leaves the patches in the rom (which mostly get overwritten anyway to be fair). Then you say autoclean takes care of these patches (I assume in the same context), but the only way for autoclean to do that is to remember what was patched last time (because you can add and delete patches) and if it remembers that, why dosn't it remember what it put in freespace?

As I said earlier, it's not 100% bulletproof. If you remove a hijack, you'll have a few broken bytes in your ROM, but most patch makers know how to solve that anyways (patch makers usually use temporary ROMs anyways).

Quote
If you think I am being needlessly negative and nitpicky it's only because I care about such things. These are great features, but I think you are doing them in a slightly problematic way.

Yeah, I guess weird comments are better than no comments. To paraphrase someone I can't find on Google:
"Are people complaining about what you do? Good, that means they care about your project. It is only when they get silent that you should start worrying, for then they have given up hope on you."



I also belive it's time to release a new version of this tool. (Well, technically it isn't, but I want it released before I go to bed. Don't worry, I'll cut down on the daily releases when it's more done.)
Here it is.
Changes:
  • !a += +1 has been implemented.
  • If you type "freespace", the tool gives a more detailed error message that "Unknown command."
  • A bug related to using pushpc inside a freespace has been fixed. That bug destroyed half of the point of pushpc.
  • The tool has been renamed to Asar. Pronounciation: The first A is short, and the second is long (as in "Bazaar", except without the B). I don't care if the S is pronounced as S or Z, pick the one that fits best with your tongue. This pronounciation applies in Swedish as well.

Planned for tomorrow:
  • Rewrite parts of the length handler, so JML.w can be blocked.
  • Add a command to disable the label size optimizer, if I can figure out how to do that without breaking .w-only commands.
  • Allow LDA $9E,y (repoint to LDA.w), but print a warning for that.
  • Make a command to allow a define as "expand all defines in this string, then run the math parser and give me results" instead of "here's a string that may contain defines, enter an infinite loop if it contains yourself" (see my previous post for details), if I can find any unsucky syntax for that.

<blm> zsnes users are the flatearthers of emulation
Originally posted by KilloZapit
Most programing languages have multiple search paths and multiple files. Of course in C++ a .cpp file will search the current directory but I don't think a included .h file would. Python I have no idea. But an include directive mostly just dumps whatever is in the included file into the current file. That's why it searches the root file, because as far as the assembler knows, that's the current file. If that should change it should search both at least.

Python.h is within /usr/include, so it can be included from any directory using <file.h> notation. However, the top of Python.h contains the code '#include "patchlevel.h"', which means it will only look for that within the current directory. If the directory didn't change to /usr/include, that line wouldn't work without you having patchlevel.h in the directory with your C file.

Originally posted by KilloZapit
Originally posted by HuFlungDu
Originally posted by KilloZapit
and old xkas didn't

Yes, and it was the cause of a lot of annoyance (Namely that you couldn't "install" xkas because it had to be run in the directory with the file, which meant you needed a whole lot of copies).


I have no idea what you are talking about here. If your saying it will only search the path where the xkas.exe is, that is definitely a problem. But that's not what I am talking about. I am talking about include changing the directory. Really it's a nitpick, but it's one that is bound to have unforeseen consequences.

That is how xkas is, also an include should change the directories, since I can't imagine any reason you would want all the includes to have to reference their own includes in relation to the original file. In my homebrew setup, I have a main file who's sole purpose is to include all the other files (for easy assembly). It includes all the other ones (which are in different folders), which themselves may also need includes. So, for instance, there's the video folder. The main has "incsrc video/video.asm", and video.asm contains the line "incbin graphics/graphics.bin". I don't want to have to put "incbin video/graphics/graphics.bin" for that, it doesn't even make any sense, since there is no video folder within the folder that "video.asm" is in. See what I'm saying?

Originally posted by KilloZapit
Originally posted by Alcaro
If you're thinking of allowing multiple architectures with the same tool, that's the only solution I'm going to consider.

Well yeah. Doesn't bass use user-defined opcode tables for that?

No, the defining is all done in pure C++ code, you just compile a different module to add a new architecture.

Quote
Originally posted by Alcaro

Quote
How does it check anyway? Internal rom name?

Correct.
Guess: You're going to find a reason why this is a horrible idea.

Well, LM does allow you to change the internal rom name, but it's so rarely used I think it's mostly an acceptable way to do it. I think a way to set what name to check for is a good idea though.

While you can change the internal ROM name, you can only do it after your ROM is locked, not really an issue, since you aren't really going to want to patch stuff after your ROM is locked anyways.
Okay, so I broke that deadline due to getting sick. Yay.

Here's version 0.3 or 0.4 or something.
Changes:
  • LDA $9E,y is now treated as LDA $009E,y, but it prints a warning.
  • Unknown command errors have been made saner. The old method was some sort of debug code.
  • Carriage returns are now ignored on Linux.
  • New command: set. It can set various options, including expected ROM title (the romtitle command has been removed), if the .l->.w optimizer should be active, and if warnings should be shown. See stdlib.asm for details.
  • Assembling blank patches on nonexistent ROMs or ROMs with length zero has been fixed.
  • Asar can now automatically (try to) add colons where it thinks they should be. Note that this is disabled by default and not recommended for anything serious (I don't think its accuracy is perfect). Don't use it if you don't have a very good reason to.
  • I have added a sandbox mode, which disables all reading from external files (incsrc/incbin/table). As with the colon adder, it should be avoided unless you've got a very good reason (for example running it from an IRC bot). (Note that you'll want a time limit if you're running it from an IRC bot, or someone can go rep 2000000000 : NOP or !a = a!a : !a and freeze your bot.)
Planned for future versions because I want to go to bed now:
  • inconce: Acts like incsrc, but only if the relevant file hasn't been included earlier in this pass. If the file has been included, it does nothing.
  • Edit some stuff so I can block JML.w and warn on LDA $7E0019.
  • Allow expanding all defines and setting another define to this, if someone else can find an unsucky syntax for it.
  • SPC700 support, if you guys can decide which opcode list I should use. Should I clone bass-smp-canonical, or should I make something else?

...those posts are starting to feel more like uninteresting status updates than anything else. Does anyone have anything else to add (for example, has anyone tested the more popular patches in our section yet?), or should I make a thread in Announcements about an official switch?

I had planned on making a rule thread for the Trash Can with this post, but after starting on a draft, I noticed that it'd be a bit too empty, so I'll just toss it at this thread instead.
<blm> zsnes users are the flatearthers of emulation
I swear I made another post here at some point. Was it deleted?

Anyway I basically said that I thought autoclean was a global thing, and it makes a lot more sense now that I know it marks opcodes like that. I also wanted to know if autoclean works with JML and if it works if the label is not at the start of a freespace block (might be a good idea if it handled accidentally autocleaning multiple addresses which are in the same freespace actually).

Other then that, I just want to thank you for your time. I really don't have any other complaints/questions. I think this project Is really neat, and I hope it does well.

Edit: Also, I forget if it is already in, but I am wondering if a command line option to not actually write to a file or the ability to write to nul or /dev/null would be helpful for tools like spritetool that insert code, but since the assembler can find it's own freespace it's probably unnecessary.

In fact, it would probably greatly simplify a spritetool to let Asar do all the patching. How a sprite tool and Asar would work together might be something worth thinking about. I am almost wondering if making a Asar library would be useful, so tools can assemble code without calling external programs. But then, external programs can be upgraded easier.
Your layout has been removed.
Originally posted by KilloZapit
I swear I made another post here at some point. Was it deleted?

I don't think anyone deletes posts around here (unless they're obvious spam, which I highly doubt yours was). My theory is that you got a ninja protection warning and closed the tab before noticing that your post didn't appear.

Quote
Anyway I basically said that I thought autoclean was a global thing, and it makes a lot more sense now that I know it marks opcodes like that.

Yeah, cleaning up hijacks was never planned. It's mainly to protect against waste if the same patch is applied twice on the same ROM (or if a very similar patch is applied, like LevelASM).

Quote
I also wanted to know if autoclean works with JML and if it works if the label is not at the start of a freespace block (might be a good idea if it handled accidentally autocleaning multiple addresses which are in the same freespace actually).

That'll work fine. Point it to anywhere inside a RATS tag or a RATS protected area, and it'll find the start and kill it. autoclean JML is treated identically to autoclean JSL (except, obviously, that it looks for and adds 5C instead of 22).
Several autocleans aiming for the same RATS tag will let the second one see that there is no RATS tag on that area, so it'll ignore it and assemble the JSL normally.
I suggest placing autoclean on all JSLs and JMLs. More than one does no harm, and it's a safeguard if you remove one of them.

Quote
Also, I forget if it is already in, but I am wondering if a command line option to not actually write to a file or the ability to write to nul or /dev/null would be helpful for tools like spritetool that insert code, but since the assembler can find it's own freespace it's probably unnecessary.

asar patch.asm /dev/null
No point overcomplicating it.

...actually, it might actually be useful in some contexts. *adds to checklist*
Note that it'll still need a random file to think it'll apply the patch to (libsmw doesn't like nonexistent files). Solution: Give it some random file you've got nearby (for example the patch) and it'll not modify it.

Quote
In fact, it would probably greatly simplify a spritetool to let Asar do all the patching. How a sprite tool and Asar would work together might be something worth thinking about.

I'd actually oppose that. Indirect autocleans could get messy, and letting the spritetool handle freespace would make it easier to allow updating one sprite while not updating another. I suggest copying libsmw from Asar and using that for freespace finding.
...but the ability to print freespace sizes could indeed be useful. *adds to to-do checklist*
*add dependency list to checklist as well*

Quote
I am almost wondering if making a Asar library would be useful, so tools can assemble code without calling external programs.

I can't see any point in doing this, and it sounds pretty annoying too. Everyone else is happy with calling the assembler externally, why drop a working solution?

...wait, half of the answers to that question could be used to declare Asar useless as well.

Quote
But then, external programs can be upgraded easier.

Nothing's stopping external DLL files from being upgraded.
If you mean linking it statically ... let's just release it under some kind of copyleft licence to force anyone who wants to use it to make his project open source. That'll force upgradability to stay.

On the other hand, keeping it as an EXE isn't a guarantee that it'll remain upgradable. Proof: This funny tool.

Originally posted by wiiqwertyuiop
words

That's exactly the opposite of what I asked for. I have access to several SPC700 opcode tables, and that is the problem: I have more than one, and they're not identical. (No, supporting multiple SPC700 syntaxes is not an option, it'll just become painful.)
If nobody says anything else until tomorrow, I'll just copy bass-spc700-canonical.
<blm> zsnes users are the flatearthers of emulation
Originally posted by Alcaro
Originally posted by KilloZapit
I swear I made another post here at some point. Was it deleted?

I don't think anyone deletes posts around here (unless they're obvious spam, which I highly doubt yours was). My theory is that you got a ninja protection warning and closed the tab before noticing that your post didn't appear.

I didn't think anyone deleted it on purpose or anything. But yeah that's a likely explanation, although I thought I remember it being posted. Oh well.

Originally posted by Alcaro
Quote
I also wanted to know if autoclean works with JML and if it works if the label is not at the start of a freespace block (might be a good idea if it handled accidentally autocleaning multiple addresses which are in the same freespace actually).

That'll work fine. Point it to anywhere inside a RATS tag or a RATS protected area, and it'll find the start and kill it. autoclean JML is treated identically to autoclean JSL (except, obviously, that it looks for and adds 5C instead of 22).
Several autocleans aiming for the same RATS tag will let the second one see that there is no RATS tag on that area, so it'll ignore it and assemble the JSL normally.
I suggest placing autoclean on all JSLs and JMLs. More than one does no harm, and it's a safeguard if you remove one of them.

Also just read in the changelog it works dl too, which is neat. I suppose technically you could simply match the opcode used if you wanted to support stuff like LDA.l <label>,x or any other long addressing, but I guess that would be a little pointless.

As a side note, I currently use the original level area for all my asm, so I will probably make much more use out of pushpc/pullpc (and maybe warnpc). However if I want to use the VWF Patch I will probably need lots of freespace anyway. It does offer a problem though, because it expects to need a whole bank to it's self to avoid crossing bank boundaries. I assume the freespace finder avoids crossing banks?

Actually now that I think about it, how do you handle pushpc/pullpc inside freespace? I imagine it might be difficult to do right, though it's probably simple if it pushes the offset to whatever buffer freespace would write to. Maybe I should browse the source or something sometime to see how it actually works.

Originally posted by Alcaro
Quote
Also, I forget if it is already in, but I am wondering if a command line option to not actually write to a file or the ability to write to nul or /dev/null would be helpful for tools like spritetool that insert code, but since the assembler can find it's own freespace it's probably unnecessary.

asar patch.asm /dev/null
No point overcomplicating it.

...actually, it might actually be useful in some contexts. *adds to checklist*
Note that it'll still need a random file to think it'll apply the patch to (libsmw doesn't like nonexistent files). Solution: Give it some random file you've got nearby (for example the patch) and it'll not modify it.

Technically nul (which is the dos/windows version BTW, I don't think many people know dos has such devices) and /dev/null are files. The whole point is that you can use them in place of one. But I have no idea if that is true in all contexts, such as for random access.

Originally posted by Alcaro
Quote
In fact, it would probably greatly simplify a spritetool to let Asar do all the patching. How a sprite tool and Asar would work together might be something worth thinking about.

I'd actually oppose that. Indirect autocleans could get messy, and letting the spritetool handle freespace would make it easier to allow updating one sprite while not updating another. I suggest copying libsmw from Asar and using that for freespace finding.
...but the ability to print freespace sizes could indeed be useful. *adds to to-do checklist*
*add dependency list to checklist as well*

It's just that Tessera for example, is so asm heavy that I wonder sometimes if it might be easier for a spritetool to create .asm files for asar to insert instead of asar creating binary files for the tool to insert. I never really thought of updating one sprite while not updating another, I didn't think any spritetools did that.

Originally posted by Alcaro
Quote
I am almost wondering if making a Asar library would be useful, so tools can assemble code without calling external programs.

I can't see any point in doing this, and it sounds pretty annoying too. Everyone else is happy with calling the assembler externally, why drop a working solution?

...wait, half of the answers to that question could be used to declare Asar useless as well.

Quote
But then, external programs can be upgraded easier.

Nothing's stopping external DLL files from being upgraded.
If you mean linking it statically ... let's just release it under some kind of copyleft licence to force anyone who wants to use it to make his project open source. That'll force upgradability to stay.

On the other hand, keeping it as an EXE isn't a guarantee that it'll remain upgradable. Proof: This funny tool.

I have a few different opinions on this:

1. A statically linked library may allow more control over a tool's specific language. It may insure both that features witch are not useful or even contrary too a tool's function can be removed and more useful ones can be added. It also insures that upgrading or changing the assembler won't break things for that tool. I sill agree a sort of copyleft license is good for rapid bugfixing and development in any case. The difference here is each project can have a central maintainer that controls all the code.

2. A external program has the opposite effect. If a tool relies on an external program, it doesn't have much control over it. And this can of course be a good thing because the two projects don't have to be updated at the same rate. Right now the xkas in the spritetools could be replaced with asar, and you would get all the benefits and all the problems associated with doing that.

3. A dynamically linked library is really not much more then a external program that you can't use without another program, but may be easier to integrate with another program. Really in this case I don't see much point in using one. I don't think it offers any benefit over calling a program.

Originally posted by Alcaro
Originally posted by wiiqwertyuiop
words

That's exactly the opposite of what I asked for. I have access to several SPC700 opcode tables, and that is the problem: I have more than one, and they're not identical. (No, supporting multiple SPC700 syntaxes is not an option, it'll just become painful.)
If nobody says anything else until tomorrow, I'll just copy bass-spc700-canonical.


No official sony/nintendo documents on the subject?

Also: Am I missing a tag? There seems to be an error in this post but I don't know why.

Mod edit: Fixed HTML filter error.
Your layout has been removed.
Originally posted by KilloZapit
Originally posted by Alcaro
Quote
I also wanted to know if autoclean works with JML and if it works if the label is not at the start of a freespace block (might be a good idea if it handled accidentally autocleaning multiple addresses which are in the same freespace actually).

That'll work fine. Point it to anywhere inside a RATS tag or a RATS protected area, and it'll find the start and kill it. autoclean JML is treated identically to autoclean JSL (except, obviously, that it looks for and adds 5C instead of 22).
Several autocleans aiming for the same RATS tag will let the second one see that there is no RATS tag on that area, so it'll ignore it and assemble the JSL normally.
I suggest placing autoclean on all JSLs and JMLs. More than one does no harm, and it's a safeguard if you remove one of them.

Also just read in the changelog it works dl too, which is neat. I suppose technically you could simply match the opcode used if you wanted to support stuff like LDA.l <label>,x or any other long addressing, but I guess that would be a little pointless.

Pointless indeed. autoclean does not share any code with the standard assembler, so I decided to drop the most useless ones.
Workaround if you're REALLY sure you need it: db $BF : autoclean dl Label

Quote
As a side note, I currently use the original level area for all my asm, so I will probably make much more use out of pushpc/pullpc (and maybe warnpc).

However if I want to use the VWF Patch I will probably need lots of freespace anyway. It does offer a problem though, because it expects to need a whole bank to it's self to avoid crossing bank boundaries. I assume the freespace finder avoids crossing banks?

Of course it does. The RATS tag may cross banks, but the content may not.

Quote
Actually now that I think about it, how do you handle pushpc/pullpc inside freespace? I imagine it might be difficult to do right, though it's probably simple if it pushes the offset to whatever buffer freespace would write to. Maybe I should browse the source or something sometime to see how it actually works.

Yeah, I ran into some pretty anooying bugs with that. Took an hour or something to fix.
Solution: I just push current freespace size/etc to the same stack I send the current position to.
(Random note: I think you can use freecode/freedata inside a pushpc block if you want to. Might be useful for mixing one freedata block and one freecode block.)

Quote
Originally posted by Alcaro
Quote
Also, I forget if it is already in, but I am wondering if a command line option to not actually write to a file or the ability to write to nul or /dev/null would be helpful for tools like spritetool that insert code, but since the assembler can find it's own freespace it's probably unnecessary.

asar patch.asm /dev/null
No point overcomplicating it.

...actually, it might actually be useful in some contexts. *adds to checklist*
Note that it'll still need a random file to think it'll apply the patch to (libsmw doesn't like nonexistent files). Solution: Give it some random file you've got nearby (for example the patch) and it'll not modify it.

Technically nul (which is the dos/windows version BTW, I don't think many people know dos has such devices) and /dev/null are files. The whole point is that you can use them in place of one. But I have no idea if that is true in all contexts, such as for random access.

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.

Quote
Originally posted by Alcaro
Quote
In fact, it would probably greatly simplify a spritetool to let Asar do all the patching. How a sprite tool and Asar would work together might be something worth thinking about.

I'd actually oppose that. Indirect autocleans could get messy, and letting the spritetool handle freespace would make it easier to allow updating one sprite while not updating another. I suggest copying libsmw from Asar and using that for freespace finding.
...but the ability to print freespace sizes could indeed be useful. *adds to to-do checklist*
*add dependency list to checklist as well*

It's just that Tessera for example, is so asm heavy that I wonder sometimes if it might be easier for a spritetool to create .asm files for asar to insert instead of asar creating binary files for the tool to insert. I never really thought of updating one sprite while not updating another, I didn't think any spritetools did that.

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.

Quote
Originally posted by Alcaro
Quote
I am almost wondering if making a Asar library would be useful, so tools can assemble code without calling external programs.

I can't see any point in doing this, and it sounds pretty annoying too. Everyone else is happy with calling the assembler externally, why drop a working solution?

...wait, half of the answers to that question could be used to declare Asar useless as well.

Quote
But then, external programs can be upgraded easier.

Nothing's stopping external DLL files from being upgraded.
If you mean linking it statically ... let's just release it under some kind of copyleft licence to force anyone who wants to use it to make his project open source. That'll force upgradability to stay.

On the other hand, keeping it as an EXE isn't a guarantee that it'll remain upgradable. Proof: This funny tool.

I have a few different opinions on this:

1. A statically linked library may allow more control over a tool's specific language. It may insure both that features witch are not useful or even contrary too a tool's function can be removed and more useful ones can be added. It also insures that upgrading or changing the assembler won't break things for that tool. I sill agree a sort of copyleft license is good for rapid bugfixing and development in any case. The difference here is each project can have a central maintainer that controls all the code.

2. A external program has the opposite effect. If a tool relies on an external program, it doesn't have much control over it. And this can of course be a good thing because the two projects don't have to be updated at the same rate. Right now the xkas in the spritetools could be replaced with asar, and you would get all the benefits and all the problems associated with doing that.

3. A dynamically linked library is really not much more then a external program that you can't use without another program, but may be easier to integrate with another program. Really in this case I don't see much point in using one. I don't think it offers any benefit over calling a program.

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.

Quote
Originally posted by Alcaro
Originally posted by wiiqwertyuiop
words

That's exactly the opposite of what I asked for. I have access to several SPC700 opcode tables, and that is the problem: I have more than one, and they're not identical. (No, supporting multiple SPC700 syntaxes is not an option, it'll just become painful.)
If nobody says anything else until tomorrow, I'll just copy bass-spc700-canonical.


No official sony/nintendo documents on the subject?

...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.

Quote
Also: Am I missing a tag? There seems to be an error in this post but I don't know why.

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.
<blm> zsnes users are the flatearthers of emulation