As if anybody needed any more reasons to stay away from NESASM... this cracked me up. I'm going to have to optimize the label lengths of my music engine data exporter to get NESASM compatibility. :''''(
foo.asm
Code:
.inesprg 1
.ineschr 1
.inesmap 0
.inesmir 1
.bank 0
.org $C000
abcdefghijklmnopqrstuvwxyzabcdefNESASM:
.byte 1
abcdefghijklmnopqrstuvwxyzabcdefSUCKS:
.byte 2
Result:
Code:
NES Assembler (v3.01)
pass 1
#[1] foo.asm
9 00:C001 abcdefghijklmnopqrstuvwxyzabcdefSUCKS:
Label multiply defined!
# 1 error(s)
At least it's reporting the error instead of producing a corrupt binary, which is a step up from previous versions!
The error is that the label is multiple defined, instead of saying something like "label too long".
I hate long labels anyways, but the real problem with NESASM is his stupid banking system.
Bregalad wrote:
The error is that the label is multiple defined, instead of saying something like "label too long".
True. But we can at least deduce that the reason why it thinks the labels are repeated is because it can only see the first X characters. A newbie would hardly deduce that, though.
Quote:
I hate long labels anyways
Some people don't, and it would be nice if they could use the kind of label they like. I mean, I understand why this kind of limitation existed in the past, since computers had little memory and processing power, but with today's computers there's really no excuse.
Quote:
but the real problem with NESASM is his stupid banking system.
I find it stupid too. It just adds an unnecessary layer of complication. The only real advantage that NESASM offers over, say, ASM6, are the commands used to define iNES header parameters. But this is such a tiny unimportant thing that doesn't come near to justifying the use of NESASM.
NESASM>ASM6. It has way more options inside of it, no need for external bullshit like your headers in a BIN file you include later. If that was added to ASM6 I'd use it, but it doesn't. That's more important than +/- labels to me. And the banking is bogus and should be selectable in size if anything, but it isn't a game breaker. It makes it 100x easier from going to something like MMC1 to MMC3 with 8KB banks.
And I make long and descriptive labels, but still, those are stupid long.
And anyway, I'm sure it wouldn't be hard to make the labels be longer.
I think it's time that someone, maybe myself, just bite the bullet and make the hands down best assembler. It'd be good for somebody like me learning the instruction set better. Anyone have insight about how hard it is to making an assembler compared to a game? I suck at C though, if I did it it'd probably be in javascript. :/
3gengames wrote:
no need for external bullshit like your headers in a BIN file you include later.
In any assembler you can just define the header with a few .db statements INSIDE the source file... you know that, right? A BIN file isn't required in any assembler. Check my
ASM6 templates for an example.
Quote:
That's more important than +/- labels to me.
So something that you only do once at the beginning of development is more important than label management, something you'll do all the way through? OK.
Quote:
I think it's time that someone, maybe myself, just bite the bullet and make the hands down best assembler.
Quote:
if I did it it'd probably be in javascript. :/
What? The expressions "hands down best assembler" and "JavaScript" are mutually exclusive.
3gengames wrote:
I think it's time that someone, maybe myself, just bite the bullet and make the hands down best assembler. It'd be good for somebody like me learning the instruction set better. Anyone have insight about how hard it is to making an assembler compared to a game? I suck at C though, if I did it it'd probably be in javascript. :/
There's no such thing as "the hands down best assembler". If you think so, you're as delusional as I was when I set out to create one.
As for insight into how hard it is to make an assembler. Making an assembler is crazy easy. Making an assembler that has a lot of useful features your users will *demand* once they realize what you've created is nothing more than a table-lookup-and-replace-"LDA #nn"-with-"A9 nn" a.k.a. "dumb-as-a-bucket-of-bolts" assembler, is *harder than hell*.
Javascript??? Where to begin...ummm don't.
Decide how much time you want to spend writing your lexical analyzer and your grammatical parser. If the answer to both of those is "my what?", then learn flex/bison, or one of the other compiler creation tools. Good luck with that...they'll get you most of the way there if you can stomach the twists and turns that shift/reduce and reduce/reduce conflicts cause. If you decide to write either in C yourself, beware the tangled spaghetti web you'll create as you try to realize each and every syntactic twist of the language in your functional model.
Decide on the list of features of "the hands down best assembler". Your list will never be complete, and your users will never be happy that their "it has to be able to do this..." feature isn't anywhere near the top of your burn-down list.
Yeah, but it'd be better to have it just a C utility like every other one. And yeah it is, I don't use them that much and find not having them as not much of a big deal, mainly because I've never had the probably, but still, I don't care about those.
And what do you mean exactly by that staement mutually exclusive?
I tried to use ASM6 and it is so barbaric feeling compared to NESASM3, weather a better feature that you use a lot or not.
tokumaru wrote:
What? The expressions "hands down best assembler" and "JavaScript" are mutually exclusive.
Ahhh, there's the phrase I was looking for.
Even though I don't use it I guess CA65 *is* the hands down best assembler you are looking for. It has literally infinite features.
The only problem is that it's hard to set up an environment to assemble something, but you only do it once per project.
And trust me , +/- labels are very important, because it's impossible to find a new name for every small inner loop of your programs.
Bregalad wrote:
Even though I don't use it I guess CA65 *is* the hands down best assembler you are looking for. It has literally infinite features.
The only problem is that it's hard to set up an environment to assemble something, but you only do it once per project.
And trust me , +/- labels are very important, because it's impossible to find a new name for every small inner loop of your programs.
Is there a default template to see how that looks? And, that's why I use a decent number of subroutines, and once finished editing, rename thhe first 2 letters capitals and that no other routine has, using the same label twice has never been a problem. It has been for RAM variable, but not program for me.
You don't need to find new names to small inner loop labels if an assembler has local labels. Pretty much all the popular assemblers has them, including NESASM.
I wrote 10K+ lines of code with NESASM and had no problems with lack of long labels and +/- labels. So NESASM isn't that bad, or any bad, actually.
Shiru wrote:
You don't need to find new names to small inner loop labels if an assembler has local labels. Pretty much all the popular assemblers has them, including NESASM.
I wrote 10K+ lines of code with NESASM and had no problems with lack of long labels and +/- labels. So NESASM isn't that bad, or any bad, actually.
Dude, that's something I didn't even know about, I'll be using those for loops now.
And yes, I don't think people that don't use it should say anything. Use NESASM3 for one full game and then I'd probably allow you to smash it for being the worst thing ever.
I use local labels such as _loop, _next, _end all the time, and I also use loads of +/-, and I even often have to use ++/-- or even sometimes +++/--- along with labels such as _loop2, _loop3 etc...
This is one of the major annoyance of programing : FINDING DAMN LABELS (including variable names and subroutine's name)
It's also a major source of bug. For example it's not rare to mess up and branch to _loop2 instead of _loop3
And +/- labels can be that confusing too. Especially if you abuse them and go like 3 of them deep in a small space.
And that's why I rename all subroutines in seperate files with their own 2 letter beginning that also makes sense, with a name attached. Either you can find the subroutines file in 2 seconds and find it just as quick, or find it the main file with 1 text search. And your text editor should have a FIND feature, it's not that hard to use. At least it shouldn't be...
Instead of writing the "hands down best assembler", I actually feel like writing the "hands down best tutorial", that doesn't use NESASM. I really think that the only reason NESASM has a strong following is because it's used in popular tutorials. Once people get their first programs working with it, they see no reason to switch assemblers.
But it's a fact that NESASM has a number of troublesome bugs, which have already been discussed to death in this forum, and thefox just found another one. Can it be used to make great games? Sure it can. Even an hex editor can be used to make great games, but that doesn't necessarily make it a good tool for the job.
I think that a good tutorial introducing another assembler could change this, because people wouldn't get attached to NESASM in the first place. I'm not sure which assembler would be the best one though. Even though I'm an ASM6 fan, I don't go around yelling that it's the best thing ever, and I can admit that there are other good assemblers out there, even though I don't use them, unlike 3gengames who blindly defends NESASM just because that's all he can use. Saying things like "NESASM>ASM6" just because you can't get a program to do what you want is stupid.
tokumaru wrote:
Instead of writing the "hands down best assembler", I actually feel like writing the "hands down best tutorial", that doesn't use NESASM. I really think that the only reason NESASM has a strong following is because it's used in popular tutorials. Once people get their first programs working with it, they see no reason to switch assemblers.
This is why I started putting together example projects for NESICIDE based on CC65-compilable ROMs that tepples and Shiru have put together. I don't know where clueless is regarding public release of his Yars Revenge port--but if it were ever to be released there's a NESICIDE project already for it. So there's already two great games and three or more great minimalist demo projects from tepples.
Unfortunately I'm not able to focus long enough to get a good textual tutorial put together. I was hoping to generate some progression of tutorials based on a similar progression of example projects. Then we could write the "Teach Yourself NES Programming in 21 Days" book and have it come with a CD full of projects to be used to learn each day's concept and expand upon prior days concepts.
For being beaten to death, I still know of 0 bugs in the current version of NESASM.
And yeah, you can stay on your assembler. But I like the way NESASM3 works, syntax, etc. If +/- labels could be added and a new assembler that worked like that but just something different? I mean, like I said, how hard it is to write an assembler?
3gengames wrote:
I still know of 0 bugs in the current version of NESASM.
This thread is about a bug, so the fact that you are posting in it means you know of at least one. Whether it affects you or not doesn't change the fact that it exists.
Quote:
And yeah, you can stay on your assembler.
Sure I can, and so can you. That's the good thing about free will. But I'm pretty sure that you didn't pick NESASM because you tried many assemblers and came to the conclusion that it was the best. You probably followed someone's suggestion (in a tutorial or not) or just went with the one you were able to get working first, and are stuck with it since.
Label limitation is a bug? News to me. It's just a limitation. [To the OP.]
Label lenght limitation is surely not a bug, it is a limitation. Old assemblers had it way more strict, like 8 or even less symbols in a label.
Despite I've asked people about bugs in NESASM and searched in the forum, no one reported anything certain. The info was like 'someone had a bug long ago', that's it. I personally found just one actual bug, and it was a minor one:
Shiru wrote:
A NESASM bug finally was noticed by me in this project. It does not report ROM overflow in some cases, producing not working ROM without any warnings. If you move some data around, it starts to show an error.
3gengames wrote:
I mean, like I said, how hard it is to write an assembler?
I answered on the previous page...
Shiru wrote:
Label lenght limitation is surely not a bug, it is a limitation. Old assemblers had it way more strict, like 8 or even less symbols in a label.
Despite I've asked people about bugs in NESASM and searched in the forum, no one reported anything certain. The info was like 'someone had a bug long ago', that's it. I personally found just one actual bug, and it was a minor one:
Shiru wrote:
A NESASM bug finally was noticed by me in this project. It does not report ROM overflow in some cases, producing not working ROM without any warnings. If you move some data around, it starts to show an error.
Yes, and now if you go outside a bank at all it'll throw errors of all the outside instructions. So technically that's been fixed.
And, okay cpow. I don't see how any part of it would be. And I only said javascript because I've found text handling in C to be a bitch. And then marking labels to points in the ROM and seeing if they've already been declared. Do you just make on big ass text array of all labels pre defined and check for if two equal and are being declared in one loop looking up a huge array of text variables? Honestly, I think everything else would be dead simple except that one functionality detail. If the community wants a better assembler, we have the knowledge and ability to do it, I'd happily do my best to help with it. In fact, if I can get Dev-C++ on my computer at school, I'll try my best at it, as I need to learn C more anyway. Don't really have much left to say except you guys should probably use NESASM. I think you'd change opinions. Whoever says it's a BAD assembler is just dwelling on the past.
3gengames wrote:
only said javascript because I've found text handling in C to be a bitch. And then marking labels to points in the ROM and seeing if they've already been declared. Do you just make on big ass text array of all labels pre defined and check for if two equal and are being declared in one loop looking up a huge array of text variables?
No, you borrow an existing hash table or aatree implementation.
3gengames wrote:
And, okay cpow. I don't see how any part of it would be. And I only said javascript because I've found text handling in C to be a bitch.
That's why I suggested one of the widely-available compiler-generators. They do the majority of the text handling for you. But you have to create your own symbol table, etc.
3gengames wrote:
And then marking labels to points in the ROM and seeing if they've already been declared. Do you just make on big ass text array of all labels pre defined and check for if two equal and are being declared in one loop looking up a huge array of text variables? Honestly, I think everything else would be dead simple except that one functionality detail.
A symbol table is more, much more, than a "big ass text array of all labels".
There seems to be a giant rug you're sweeping "everything else" under. Expression evaluation? Optimizations (addressing mode promotions, etc.)? Macros? Enumerations? Segments (for banking)? File inclusion directives?
3gengames wrote:
If the community wants a better assembler, we have the knowledge and ability to do it, I'd happily do my best to help with it.
I agree with Tokumaru. We don't need more assemblers, we just need a comprehensive tutorial package using the best assembler available.
3gengames wrote:
In fact, if I can get Dev-C++ on my computer at school, I'll try my best at it, as I need to learn C more anyway. Don't really have much left to
Writing the "hands down best assembler" probably isn't the second project you'll want to tackle on your path to learning C. Start with "hello world"...
I only use + and - labels for labels within a routine. I find myself using a lot of ++ and +++ labels as well, but it's not hard to manage. I also have my code organized fairly well (or at least I try), so finding a label isn't hard. Everything falls into "Code" or "Data". Within "Code", I have all code separated by game mode, so that's either like "TitleScreen", "Cutscene", "Game", etc. It's the same with Data, too. Then within those categories, everything is categorized into even smaller subcategories until you reach an individual object or routine. So this label:
Data.Cutscene.IntroScene.Frame1.SpriteMap
Points to the sprite map of "frame 1" in the "intro scene", which is categorized under the "cutscene" group of the data section. Using this notation really helps organizing everything so you don't have some label like "loadsprites" or something ambiguous.
Looking at this, I see I will definitely stay away from NESASM, as there is no way in hell it would tolerate that label.
Shiru wrote:
Label lenght limitation is surely not a bug, it is a limitation.
Fine, it's not a bug. An undocumented limitation is as annoying as a bug though.
3gengames wrote:
And I make long and descriptive labels, but still, those are stupid long.
And anyway, I'm sure it wouldn't be hard to make the labels be longer.
My labels in this case were in this form (computer generated):
<prefix>_<name of the song>_chnX_orders
I don't think this is stupid long. 32 is a stupid limit for a label name, something like 256 I could understand, but 32 is too short. Even in that case the assembler should give a warning, not just cut the string like nothing happened.
Quote:
I think it's time that someone, maybe myself, just bite the bullet and make the hands down best assembler. It'd be good for somebody like me learning the instruction set better. Anyone have insight about how hard it is to making an assembler compared to a game? I suck at C though, if I did it it'd probably be in javascript. :/
Good luck with that. CC65/CA65 has been in development over 10 years, and still has a ways to go.
Bregalad wrote:
And trust me , +/- labels are very important, because it's impossible to find a new name for every small inner loop of your programs.
In CA65 this isn't super important, because you can wrap your subroutines in .proc/.endproc:
Code:
.proc doStuff
foo:
nop
jmp foo
.endproc
.proc doOtherStuff
foo:
nop
jmp foo
.endproc
The above code compiles fine, and the labels inside the .proc can be also accessed outside with doStuff::foo and doOtherStuff::foo. If you need to use the same label more than once inside the subroutine, you can wrap that part of the code in .scope/.endscope (anonymous or named, however you like it).
Shiru wrote:
I wrote 10K+ lines of code with NESASM and had no problems with lack of long labels and +/- labels. So NESASM isn't that bad, or any bad, actually.
It isn't bad by itself, but compared to the best assemblers.
3gengames wrote:
And yes, I don't think people that don't use it should say anything. Use NESASM3 for one full game and then I'd probably allow you to smash it for being the worst thing ever.
I actually used it for the first time since reading the GBAGuy tutorials when I was getting started 5-6 years ago. It didn't take me more than half an hour to stumble on this bug, which I don't think is a good sign.
3gengames wrote:
For being beaten to death, I still know of 0 bugs in the current version of NESASM.
It is not just about bugs (besides, our definition of what's considered a bug clearly is different). It's about things like having to use non-standard syntax for indirect addressing (lda [foo], y), having to manually use < to signify zero page addressing (lda <foo), inconsistent syntax (lda <foo works, but ".byte <foo" doesn't), and yes, label limitations.
3gengames wrote:
Don't really have much left to say except you guys should probably use NESASM. I think you'd change opinions. Whoever says it's a BAD assembler is just dwelling on the past.
Like I said, NESASM isn't that bad by itself, but why use it when there are far better alternatives available.
EDIT: Noticed a missing parenthesis.
The label limitation thing is something I would classify as a "bug". Why? Because NESASM is incorrectly telling you that the same label has been defined twice rather than telling you the label is simply too long for it to handle.
And making an assembler with all the currently supported features around is super hard. These are just some things that you'll need to support:
If statements/for loops
Data defined by logic
Inline arithmetic
Macros (that accept arguments too)
File inclusion
Nameless labels
Defining and Undefining label names
For a slightly ridiculous example, you need to support something similar to the following code:
Code:
.DEFINE ArrayInRAM $500 + 31 + %00000001
.DEFINE Sane 0
.DEFINE Insane sin(90)
.DEFINE Programmer Insane
.IF Programmer == Sane
.DEFINE TempVar $21
sta TempVar
.ELSEIF Programmer != NOT(Insane)
.DEFINE someVariableThatsReallyReallyLongAndShouldBeSeenAsNonZeroPage $0021
.DEFINE Plus4 4
sta (someVariableThatsReallyReallyLongAndShouldBeSeenAsNonZeroPage + (Plus4 /2 - sin(89)))
.ENDIF
.UNDEFINE Sane, Insane, Programmer
jmp +
++
-
rts
+
CopyArray Table1, ArrayInRAM, 128
beq -
Table1:
for(x=0;x<90;x++)
{
.db x
}
.incbin "../Data/Tables/file.bin"
.MACRO CopyArray ARGS PointerA, PointerB, NumOfBytes
ldx #NumOfBytes
-
lda PointerA, x
sta PointerB, x
dex
bne -
.ENDMACRO
People do things in code you wouldn't think need to be supported. For example, some people might want to load a value in ZP with the lda #$XXXX instruction, which takes 1 more byte and 1 more cycle. Oh, and don't forget trigonometry! Sin, Cosine, and Tangent functions should be available, with options to convert the resulting values to 8 or 16 bits.
Then there's the thing of nameless labels inside of macros. When someone does a - inside a macro, anything outside of that macro should ignore that - sign. I'm pretty sure WLA doesn't even support this.
There are just so many things to think about when going into developing an assembler that people will like to use. It seems not-too-hard at first, but yeah. After a while you'll probably find yourself right-clicking on that project folder, clicking "delete", and starting over because it became too much of a mess.
Anybody want to guess what binary is produced by NESASM v3.1 with the following code (I'm guessing this is the same bug/feature that Shiru mentioned):
Code:
.bank 0
.org $8000
.byte 1, 2, 3, 4
.org $A000
.byte 5, 6, 7, 8
---
Naturally, the result is 8K of code (+ the iNES header) with the following contents:
Code:
05 06 07 08 FF FF FF FF ... (FF padding to 8K)
Q.E.D.
So when a bank overflows the assembler silently wraps back and overwrites the beginning of it? Niiiiice!
This code is too complex for NESASM to handle:
Code:
.bank 0
.org $8000
foo = bar
bar:
.byte 1
Result:
Code:
NES Assembler (v3.1)
pass 1
pass 2
#[1] foo.asm
3 00:8000 foo = bar
Internal error[1]!
# 1 error(s)
Extra points for the helpful error message.
I stil haven't heard much reason not to use asm6 over nesasm though. Whilst nesasm has less bugs then in the past it was proved pretty easily that its not exactly helpfull with some of it's "limitations" (straight up bug in my eyes since it doesn't give you the correct information and puts you on a wild goose chase)
The only argument I heard is having to include a bin file for a header...which was disproved pretty fast. (since you can .db them in)
thefox wrote:
This code is too complex for NESASM to handle:
Code:
.bank 0
.org $8000
foo = bar
bar:
.byte 1
Result:
Code:
NES Assembler (v3.1)
pass 1
pass 2
#[1] foo.asm
3 00:8000 foo = bar
Internal error[1]!
# 1 error(s)
Extra points for the helpful error message.
Were you just trying to create an alias for the "bar" label that you called "foo"?
Yeah, and whatever the case, I have to agree that the error message is stunningly informative. Perhaps the error happened because you defined the label after the "foo" part.
Have you tried moving your constant out of your program's code? IMO, that's a case of controlling your program flow, your constant declarations shouldn't be in the middle of code EVER. Put it outside, like before the .rsset and after the header declarations.
The only real problem with ASM6 is that due to its memory model, it can't check for stupid programmer mistakes when you jump from code on one bank to code in another bank in the same memory address range.
So your code in Bank 0 at $8000 can try to call code in Bank 1 at $8000, and nothing will try to stop it.
It's probably a bad idea to try to stop this anyway, since you might be making code intended to be copied to RAM.
There are also a few issues with INCBIN. INCBIN accepts 3 arguments, a filename, and optionally, a source address and length. The filename is not quoted. But when you use a filename, source address, and length, it treats the first comma as part of the filename, unless you add an extra space before the comma.
And you can't use INCBIN as part of a macro. Boo!
I don't think the assembler should stop you from doing that. The assembler should and does allow you to access labels from any bank, in any bank. And after all, a label is just an alias for an address. Thus, two labels in separate banks both defined at $8000 should both be interpreted as just the number $8000.
If anything, the assembler should just warn you. I can see though in a scheme where a lot of bankswitching is involved, you may be switching the bank the PC is currently in depending on your set up. Take this code for example:
Code:
.bank 0
.org $8000
bankswitch:
;blah bankswitching code
.end
.bank 1
.org $8000
;idendical blah bankswitching code
....
jmp bankswitch
The label "bankswitch" can only be defined once. In this case, the label should point to the same thing in each bank, so it's good that it allows for this.
Celius wrote:
Were you just trying to create an alias for the "bar" label that you called "foo"?
The actual case was something like this:
Code:
foo = bar + 123
bar:
lda #123
nop
; etc
The problem is (as far as I understand it) NESASM doesn't seem like to forward references in symbol assignments. You can forward reference symbols with stuff like "lda bar" before bar is defined though, so the limitation doesn't make much sense.
3gengames wrote:
Have you tried moving your constant out of your program's code? IMO, that's a case of controlling your program flow, your constant declarations shouldn't be in the middle of code EVER. Put it outside, like before the .rsset and after the header declarations.
Why? (It doesn't fix the problem anyways, BTW.)
EDIT: Replied to 3gengames
Dwedit wrote:
There are also a few issues with INCBIN. INCBIN accepts 3 arguments, a filename, and optionally, a source address and length. The filename is not quoted. But when you use a filename, source address, and length, it treats the first comma as part of the filename, unless you add an extra space before the comma.
You should say "doesn't have to be quoted", but it can be. In this case, you should quote it.
I guess label lenght limitation is not a bug, but the fact the assembler doesn't give a warning or something when a label is too long IS a bug.
NESASM was also written like 10+ years ago and was never updated. It's as outdated as Nesticle if you ask me. Yes I started NES development writing with NESASM and testing with Nesticle... but now I use WLA-DX and test on a Power Pak and this is way better.
That being said there is 2 problem I have with WLA-DX :
1) It is complicated to make a piece of code in ROM that you copy and execute in RAM, you have to re-define all internal labels manually.
2) The assembler FORCES you to use a fixed "ROM" size, padding the end with zeroes, and doesn't have provisions for disk based systems such as the FDS or C64 where you don't want to pad the end of your files with 0s.
I'm pretty sure CC65 has solutions to both issues, the only reason I still use WLA is because I started my project with it and it's complicated to change in the middle of a project.
I think Bregalad brings up a good comparison: Nesticle and NESASM.
3gengames wrote:
Have you tried moving your constant out of your program's code? IMO, that's a case of controlling your program flow, your constant declarations shouldn't be in the middle of code EVER. Put it outside, like before the .rsset and after the header declarations.
I agree this makes for cleaner code, but it shouldn't affect functionality. An assembler shouldn't decide to comprehend variable declarations exclusively and then interpret code. If you have a bunch of different files included in one main file, and each of those files include their own variable declarations, that's completely logical. When the assembler links these files into one giant piece, it will most certainly be looking at variable declarations mixed in with code.
It's funny how people have the time to argument how bad the assembler is when the actual solution would be to find "why" it is limited to this and fix the problem.
If you look in the code, labels are of type "struct t_symbol". The name of the symbol is of size "SBOLSZ", which is a define. That define is 32 bytes. You update the size, recompile and you make some people happy, end of story. (they are defined in defs.h)
It took less than 5 minutes to find where it was. Of course there could be more impact and proper code review/regression should be done to make sure there is no hard coded length check. If I had the compiler/environment ready, I would do it.
My point is, it's quite silly to argument for such trivial things. Everyone will like their first or whatever assembler, no matter what. Even one guy is trying to
port that assembler to java!.
edit:
Here's
version 3.1.1 experimental, not regression tested, just recompiled with different length, which is now 256.
There is a few "magic numbers" in the code where 32 is used and could have impact on labels or other things. Since I don't have much time to test it, I will see if I can check someday. Source code included. Makefile works without dev-cpp, just GCC MinGW is fine (or it seems after downling MinGW).
It's a very quick & dirty hack so you use at your own risk.
edit2:
I will lose my webpage soon because of moving and not using that internet provider anymore. I need to figure out where to transfer the few files I have.
edit3:
I went through some code review of all magic numbers "32". Only one had impact, inside macro.c. The name variable inside macro_look was hard coded to 32 when t_macro name was using SBOLSZ. Now it's using SBOLSZ for size. It could be considered in a beta stage but without any testing. Any testing, especially "thefox" about his own project, would be appreciated.
My motto, don't try to fight, accommodate people. We are a community, we should help each other. Why not?
Bregalad wrote:
I use local labels such as _loop, _next, _end all the time, and I also use loads of +/-, and I even often have to use ++/-- or even sometimes +++/--- along with labels such as _loop2, _loop3 etc...
This is one of the major annoyance of programing : FINDING DAMN LABELS (including variable names and subroutine's name)
It's also a major source of bug. For example it's not rare to mess up and branch to _loop2 instead of _loop3
I find that makes for poor readability for code. It takes but a second to use anything else as a local label. As simple as .1 or .LL01 or whatever. Much easier to track with your eyes. Single instances of +/- aren't too bad, but not terribly important to have. It's just the ++/-- , +++/---, and ++++/----- etc that look terrible.
I will always prefer +/- instead of any other nameless label because they don't clash with the actual label names when I'm browsing through all of them. Also, I never follow "+" with a ":" for this reason.
In Asm6, local labels are useless since + and - labels kill them.
Dwedit wrote:
In Asm6, local labels are useless since + and - labels kill them.
Yeah, I was kinda disappointed with that.
So you're saying a feature is useless because there's a better feature for it....and that's a BAD thing?
Local labels are better than +-. If you have a subroutine with like 20 labels, you'd prefer to have internal labels local to this subroutine (to not interfere with other code and to not think up 20 globally unique names) than 20 unnamed labels that will be like +++++++.
Nope, you can have 20 times a single + or - if they're not nested.
I know, that's why it is not ++++++++++++++++++++ in my previous post.
With +/- I go up to 3 levels deep, never more than that, and only in small blocks of code (i.e. I never jump more than, say, 10 lines). If the code is large and requires this kind of branching, it's probably complex enough to be broken up into smaller pieces with more descriptive labels between them (in which case I use labels starting with + or -, but with actual names following).
Jeroen wrote:
So you're saying a feature is useless because there's a better feature for it....and that's a BAD thing?
Well, there's one case when local labels are better than +/-, which is when you need to reference a label both before and after the place where it is. With local labels you can do this:
Code:
jmp .MyLabel
.MyLabel:
beq .MyLabel
But since you can't interleave local labels with + and -, you end up giving up on them and doing this:
Code:
jmp +MyLabel
+MyLabel:
-MyLabel:
beq -MyLabel
Which looks kinda stupid. This is basically the only reason I would like to be able to interleave both types of labels.
I guess fixing the label length, which was the main purpose of that thread, didn't get any interest after all.
I can always try to dive into asm6 code regarding the anonymous/local label issue but I will need samples to be able to test the issue properly.
Banshaku wrote:
I guess fixing the label length, which was the main purpose of that thread, didn't get any interest after all.
I guess that's because NESASM fanboys don't care about its limitations! =)
Banshaku wrote:
I can always try to dive into asm6 code regarding the anonymous/local label issue but I will need samples to be able to test the issue properly.
It's on my to-do list which is ever growing. The code's not pretty to look at, I really ought to overhaul it one of these days...
Dwedit wrote:
There are also a few issues with INCBIN. INCBIN accepts 3 arguments, a filename, and optionally, a source address and length. The filename is not quoted. But when you use a filename, source address, and length, it treats the first comma as part of the filename, unless you add an extra space before the comma.
And you can't use INCBIN as part of a macro. Boo!
Putting the filename in quotes solves your first problem. I played around with the macro thing and I think I see what you mean.
tokumaru wrote:
I guess that's because NESASM fanboys don't care about its limitations! =)
Yeah, they must be hardcore masochist that enjoy the pain!... or maybe not
Hope somebody find it useful actually. I didn't have time to test but the fix was quite simple actually. It seems stable enough. I would need a big project to test it against to make sure it didn't break anything.
@Loopy
If it's already on your to-do list then I guess I should wait. I just felt like helping and doing some "quick fix" when the scope is not too wide for business code and similar to the one I just did, it still something I can do once in a while.
I checked my NESASM code (two actual games), and longest label was 24 chars, unique enough far before it. Masochism is using labels that longer than 32 chars and first 32 chars are the same. If someone has labels that long and uniform, he needs better assembler for sure, with local labels and modules (i.e. local labels accessible through module and non-local label name, module.subroutine.internallabel).
Quote:
Masochism is using labels that longer than 32 chars and first 32 chars are the same
I have to agree with this one.
Yet using NESASM is also kind of masochist, so much this compiler is outdated when there is other maintained compilers available. Because it says "NES" in the name doesn't mean it's THE way to compile NES program (which some people seems to be thinking).
For me it is 'if it ain't broken, don't fix' case. I used NESASM to make quick tests initially, just because I found it first, and it provided fast start (no need to write header). Then I just continued to use it and made few larger projects having no real problems with it at all. If there would be some actual problem in process, I'd just moved to other assembler, but as this takes some time to adapt source, no problems and no profit from using other assembler (no features needed for a project that could save time), why waste time changing horses? After first large project there was other reason to not move - codebase that was made and could be reused.
When it became really necessary to move to other assembler (Alter Ego), I moved easily, although it took some effort to move part of codebase (i.e. FamiTone, code conversion was done with a custom tool).
How to obsolte NESASM: rename Asm6 into NesAsm6 and add features for automatic header creation.
Shiru wrote:
How to obsolte NESASM: rename Asm6 into NesAsm6 and add features for automatic header creation.
Hahahaha Nice suggestion!
But really, do people actually think it's hard to build the iNES header with .db statements? It's just a few bitshifts harder than what NESASM offers...
It is not hard when you know how to do it, when you already have an experience. If you just a newcomer, it is hard, actually - you need to figure out that you need header, you need to find docs on it, you need to write correct header without being sure you doing it right. So either autogeneration of header or just provided ready-made template with header could help greatly at starting point.
tokumaru: Building an iNES header might be a job for a macro pack.
Shiru: That's what I'm doing in my
NES project templates for ca65.
Banshaku wrote:
It's funny how people have the time to argument how bad the assembler is when the actual solution would be to find "why" it is limited to this and fix the problem.
It wouldn't have helped much in my case, the code was generated by a program (my music tracker) which I was planning to release, so making a special build of NESASM for myself wouldn't have fixed all the other "broken" versions of NESASM in the wild. I ended up changing the code generation to generate shorter labels, but I was little bit annoyed to have to do this just to satisfy NESASM's needs...
Besides, this thread wasn't really about the issue itself, but just bashing NESASM for fun.
I noticed this limit.Once.Seriously, I don't see any problem with that.
(The real problem is that "lda $00== AD 00 00" instead of "A5 00" when I'm making timing related code).
You can force NESASM to use ZP access when needed.
lda $00 is actually lda $0000, but lda <$00 is ZP.
Hm, that is useful info.Till now I used ".db $A5,$00" to load it in ZP.Your solution looks nicer.
Thanks, Shiru.
tepples wrote:
tokumaru: Building an iNES header might be a job for a macro pack.
True. With a macro, making a header can be as easy as in NESASM.
thefox wrote:
Besides, this thread wasn't really about the issue itself, but just bashing NESASM for fun.
So I guess that makes me a "nesasm basher" teaser then?