I found out my problem with my nametable loading wrong---apparently NESASM ignores anything after the 24th entry on any .db row. P65 does not, so it loaded my nametable fine. Has anyone else encountered this limitation of NESASM? I've looked at the available documentation for NESASM and there doesn't appear to be any mention of this limitation.
I remember some limitation with the .db statements per line, but I didn't remember that it was 24 bytes. Are your .db statements spilling into the next row of characters in the asm file? Like:
.db blah, blah blah,
blah, blah
Because I remember that causing problems. Though I would always make sure every line had a .db no matter what assembler I was using.
Personally, I would stay away from defining raw tile data with .db statements, especially if it's 1024 bytes. Tepples' name table editor or NSA on the main page will allow you to arrange tiles intuitively with a mouse rather than by typing in boring hex values. Then you can just do a simple .incbin "file.nam" and all is well.
.db blah, blah blah,
blah, blah
Because I remember that causing problems. Though I would always make sure every line had a .db no matter what assembler I was using.
Personally, I would stay away from defining raw tile data with .db statements, especially if it's 1024 bytes. Tepples' name table editor or NSA on the main page will allow you to arrange tiles intuitively with a mouse rather than by typing in boring hex values. Then you can just do a simple .incbin "file.nam" and all is well.
So, the NESASM authors were lazy and restricted the line width to something like 80 characters? Haha, that's amusing.
I'm not typing them in---it is generated by a graphics editor program I've been working on over the last few months. After I made the observation, I changed the line width to be shorter, and nesasm stopped ignoring parts of my name table =) Works perfect now.
I'm aware of incbin, but I thought it would be fun to have my graphics editor generate assembler output as well.
I'm not typing them in---it is generated by a graphics editor program I've been working on over the last few months. After I made the observation, I changed the line width to be shorter, and nesasm stopped ignoring parts of my name table =) Works perfect now.
I'm aware of incbin, but I thought it would be fun to have my graphics editor generate assembler output as well.
Oh, I understand why you'd want a program to output .db statements. It's a lot easier to edit values with them. And plus, you can arrange them like:
.db $32,$66
.db $44
.db $2F, $3F, $90
So it's not like it is in a hex editor where it's just a sea of hex digits. I made a program a while back that output .db statements which held results of math functions for my sound engine. This may have been because I don't quite have the knowledge to make programs that save data to files (I'm pretty much a noob when it comes to file interaction).
.db $32,$66
.db $44
.db $2F, $3F, $90
So it's not like it is in a hex editor where it's just a sea of hex digits. I made a program a while back that output .db statements which held results of math functions for my sound engine. This may have been because I don't quite have the knowledge to make programs that save data to files (I'm pretty much a noob when it comes to file interaction).
ZomCoder wrote:
I'm not typing them in---it is generated by a graphics editor program I've been working on over the last few months.
Why not make the editor output the data as binary instead? Iirc. nesasm has a .incbin command for including binary files, this would probably also speed up the assemble stage as it wouldn't have to parse all the .db lines.
I agree. I'm actually in the process of converting the NESASM tutorials from nintendoage.com into ASM6 format. It's actually not a terribly difficult process and it eliminates a lot of the headaches and limitations of NESASM.
See this thread for reference: http://nesdev.com/bbs/viewtopic.php?t=4822
See this thread for reference: http://nesdev.com/bbs/viewtopic.php?t=4822
Thanks for the advice. I've converted my experiment from nesasm now to asm6. It seems to be far less finicky than nesasm.
beneficii wrote:
NESASM is retarded. Get ASM6 instead:
Using a DOS/Windows-only assembler for tutorials is retarded. Use ca65 instead.
beneficii wrote:
NESASM is retarded.
I used to be anti-NESASM. I still don't use it (sticking with CA65), but I've seen some really cool projects be completed with it. I see no reason to hate on it honestly, because it's still usable. There are just a few things to keep in mind when dealing with it (i.e. db limitation). I mean, I find it harder to set up for a project with ca65, but I'm more comfortable using it at this point now, so it's kinda like The Facts of Life... you take the good, you take the bad ; )
blargg wrote:
beneficii wrote:
NESASM is retarded. Get ASM6 instead:
Using a DOS/Windows-only assembler for tutorials is retarded. Use ca65 instead.
Actually, ASM6 is very easy to adapt for other operating systems. I in fact use a Mac OS X as my primary computer, but have adapted ASM6 to work in it. I sent loopy a copy of the new source code, which allows ASM6 to work on both little-endian systems (such as DOS/Windows) and big-endian systems (Mac OS X). Here is the source:
http://sm2.beneficii.net/asm6.c
On Mac OS X, you can just make a Standard Tool on XCode and put this source in and hit compile. With this source, my (partially completed) SMB2J project assembles just fine. Other things that fit within the ASM6 syntax assemble fine too.
Roth wrote:
beneficii wrote:
NESASM is retarded.
I used to be anti-NESASM. I still don't use it (sticking with CA65), but I've seen some really cool projects be completed with it. I see no reason to hate on it honestly, because it's still usable. There are just a few things to keep in mind when dealing with it (i.e. db limitation). I mean, I find it harder to set up for a project with ca65, but I'm more comfortable using it at this point now, so it's kinda like The Facts of Life... you take the good, you take the bad ; )
That's true. I don't like CA65, just because it's difficult to set up. Also, CA65 doesn't seem to work too well with FDS games, which have their own file systmes. (I actually originally tried to use CA65 for the SMB2J disassembly before ASM6, but found there wasn't any real good way of setting the disassembly up so that it could be assembled to be just like the original game.)
If the projects are small, NESASM works. (My BKG homebrew, which was written with NESASM in mind, case in point.) But I find that ASM6 works just as well, while keeping the simplicity of NESASM, and it works better on larger projects and different types of projects, including FDS games.
The Facts of Life are true though.
beneficii wrote:
blargg wrote:
beneficii wrote:
NESASM is retarded. Get ASM6 instead:
Using a DOS/Windows-only assembler for tutorials is retarded. Use ca65 instead.
Actually, ASM6 is very easy to adapt for other operating systems. I in fact use a Mac OS X as my primary computer, but have adapted ASM6 to work in it. I sent loopy a copy of the new source code, which allows ASM6 to work on both little-endian systems (such as DOS/Windows) and big-endian systems (Mac OS X). Here is the source:
http://sm2.beneficii.net/asm6.c
On Mac OS X, you can just make a Standard Tool on XCode and put this source in and hit compile. With this source, my (partially completed) SMB2J project assembles just fine. Other things that fit within the ASM6 syntax assemble fine too.
It's been used on linux systems as well. It should compile without any modifications. The source is included in the asm6 zipfile.
beneficii wrote:
Actually, ASM6 is very easy to adapt for other operating systems. I in fact use a Mac OS X as my primary computer, but have adapted ASM6 to work in it. I sent loopy a copy of the new source code, which allows ASM6 to work on both little-endian systems (such as DOS/Windows) and big-endian systems (Mac OS X). Here is the source:
http://sm2.beneficii.net/asm6.c
On Mac OS X, you can just make a Standard Tool on XCode and put this source in and hit compile. With this source, my (partially completed) SMB2J project assembles just fine. Other things that fit within the ASM6 syntax assemble fine too.
beneficii, forgive me if this is a dumb question, but i'm intrigued at the prospect of ridding my macbook of windows, since it's there solely for the sake of NESdev.
does compiling the above source create a mac version of asm6 that i can use in the unix command line, or does the source need to be compiled each time i need to assemble my nes code? i hope that question makes sense...
i'm also interested to know what other mac-specific tools you use for development. any notable tile editors, coding environments, etc?
noattack wrote:
beneficii, forgive me if this is a dumb question, but i'm intrigued at the prospect of ridding my macbook of windows, since it's there solely for the sake of NESdev.
You might still want to keep Windows. Though you can do some stuff on the Mac OS X, it seems that there aren't really any good emulators with debuggers on the Mac. There's FCEUX, but it is only command line, and I haven't figured out how to configure input on it, so that I can actually play a game. Perhaps others around here know of some really good emulators?
Quote:
does compiling the above source create a mac version of asm6 that i can use in the unix command line, or does the source need to be compiled each time i need to assemble my nes code? i hope that question makes sense...
Yes, you can use it in terminal. Just make sure that asm6 is in the directory that you're at, then use "./asm6 [options]". No you do not need to compile it again and again; just once to get the binary.
Quote:
i'm also interested to know what other mac-specific tools you use for development. any notable tile editors, coding environments, etc?
I use XCode, which you can get free if you register at Apple. My focus has been largely the disassembly, so I have not made major use of tile editors. With a quick search I found this:
http://homepage.mac.com/squirrel2/nes_chr/
I think there's lately been a movement afoot to get hacking capabilities on the Mac, though.
beneficii wrote:
You might still want to keep Windows. Though you can do some stuff on the Mac OS X, it seems that there aren't really any good emulators with debuggers on the Mac. There's FCEUX, but it is only command line, and I haven't figured out how to configure input on it, so that I can actually play a game. Perhaps others around here know of some really good emulators?
Ah, yes, I didn't think of that. Good point.
Thanks for the info, nonetheless. I'm familiar with XCode, but haven't actually used it. Can it function as a platform-agnostic coding environment (with 6502 highlighting) or does it work solely with flavors of C? I think I should just look for a mac version of something like ConText. BBEdit comes to mind.
noattack wrote:
beneficii wrote:
You might still want to keep Windows. Though you can do some stuff on the Mac OS X, it seems that there aren't really any good emulators with debuggers on the Mac. There's FCEUX, but it is only command line, and I haven't figured out how to configure input on it, so that I can actually play a game. Perhaps others around here know of some really good emulators?
Ah, yes, I didn't think of that. Good point.
Thanks for the info, nonetheless. I'm familiar with XCode, but haven't actually used it. Can it function as a platform-agnostic coding environment (with 6502 highlighting) or does it work solely with flavors of C? I think I should just look for a mac version of something like ConText. BBEdit comes to mind.
I don't know how, but I suspect that you may be able to do that, if you search hard enough. If you find out you can, please let me know too.
The main reason i prefer anything beside NESASM is the banking system that is meant to be used for PCEngine (TG-16) development.
You see, despite the name, NESASM is just a modified assembler for the TurboGrafx-16.
Obviously there is no reason to completely slight the program, but it wont run in a 64bit environment.
I prefer ASM6. It has all the features of the more robust 6502 assemblers (like unnamed labels,) is open source (no OS limitations,) and allows some neat tricks (like embedding the header into the project, and .including the Sprite and background tiles onto the end, instead of concatenating the files.)
You see, despite the name, NESASM is just a modified assembler for the TurboGrafx-16.
Obviously there is no reason to completely slight the program, but it wont run in a 64bit environment.
I prefer ASM6. It has all the features of the more robust 6502 assemblers (like unnamed labels,) is open source (no OS limitations,) and allows some neat tricks (like embedding the header into the project, and .including the Sprite and background tiles onto the end, instead of concatenating the files.)