I have been screwing around with 6502 for around a year but have never attempted to make anything (other than a few basic 'games) and found the GBAGuy's tutorial to be on par. Now that I am actually trying to do something, I have come to find out that his tutorials are quite horrible and that the NESASM compiler, even the newest version I could find, just plain sucks. If anyone could point me in the direction of a good tut or two that features the ASM6 compiler and has a short, sweet and to the point lesson on it, I would be quite appreciative.
i've found that Bunnyboy's 'Nerdy Nights' tutorial is pretty nice (i think most would agree?), but that focuses on NESASM as well. i'm wondering if it might be helpful if someone could outline the differences between the specific syntax that the popular assemblers use, so that you could easily use ASM6 (for example) with the NN tutorial? or maybe make a few different versions of that tutorial to deal with each of the popular assemblers?
also, why isn't that tutorial hosted here as well as at NintendoAge?
I actually found a link to the NN tutorials and am on lesson 3 at the moment. It hasn't actually started talking about any 6502 assembly, but I have read nothing but good things on this forum about the NN tutorials so I am still hoping it is the answer to my 'prayers'. Although I must agree, a NESASM - ASM6 conversion tutorial would help me since I learned most of my NES 6502 with NESASM.
Here you have a post related to this topic:
http://nesdev.com/bbs/viewtopic.php?t=6160
I'm begining too and still have to take the step to make the conversion between NESASM and ASM6
So that would be an interesting tutorial, since everyone seem to begin with NESASM, and at a certain point, start getting problems and stuff.
There's one thing NESASM does differently that's helpful when starting out, it makes an iNES header. With any other assembler you have to make your own header.
In the template posted in that link you can see the header included there, but you can also do what I do and just assemble to a .PRG file then use a "copy /b header+rom.prg rom.nes" to make the iNES file (I like this because I need the .PRG file to run on the NES). If you wanted to be lazy (or aren't familiar yet with editing bitfields, converting binary to hex, etc.), you can edit any ROM's header in an emulator (Nestopia is one that supports this), then use a hex editor to cut out the first 16 bytes and save that to have your header. A hex editor is a tool one should learn to use eventually.
I see where NESASM finds its niche for now. I guess when I get more comfortable with 6502 I will start using that, but if I have to add my own header then working on a game would suck since I reassemble then so many times (I have an incessant need to check every change I make to make problem solving easier).
Quote:
A hex editor is a tool one should learn to use eventually.
I guess I am lucky there. I have been modding NES games for a good time now so I know the ins and outs of a hex editor and when I started with 6502, I had pretty much every dev tool minus an assembler just sitting on my hard drive.
67726e wrote:
(I have an incessant need to check every change I make to make problem solving easier).
I'm like that too, but I don't worry about how many steps are there in the creation of the ROM because it's possible to put it all in a batch file.
For example, to create level maps I use an application I made that generates the level data from images, so I can save the images and run a batch file that first calls my level converter and then assembles the ROM using the resulting data, and it can even fire the emulator with the ROM in the end. To me it's just a double click.
Quote:
it's possible to put it all in a batch file.
Gah! I never think of some mundane thing like that. My mind jumps straight to some freaking complex C++ program and I say I am sure as heck not writing that anytime soon. I guess I need to dust off my bookshelf and refresh the part of my brain that has the batch in it.
Or if you're more inclined with higher level languages, you may be tempted to do a make file. This is what I use for ca65 assembler.
I'm with Banshaku.
GNU Make has a few advantages over a batch file, especially if you use an assembler with an "object file" mentality like ca65:
- With a makefile, only those things that need to get rebuilt get rebuilt. You specify what files depends on what other files, and Make does a topological sort on them and then builds a plan based on file modification dates.
- make -j2 so that one process can compile while the other blocks on disk I/O.
- make -j3 so that both cores of a dual-core CPU can compile while a third process blocks on disk I/O.
- Pattern rules. For example, if the commands to assemble most of your .s files are the same except for filenames, you can capture this similarity.
- Specify multiple targets. For example, a single makefile can handle making the data conversion tools, making the executable, making the unit test executable, making the documentation, and making the zipfile, and arguments to 'make' tell which targets shall be built.
- It automatically halts on syntax errors without having to 'if errorlevel 1 goto End' all the time.
If you have MSYS, you have GNU Make. If you have devkitARM or devkitPPC from other Nintendo console homebrew scenes, you have devkitPro MSYS.
I toyed with creating a dependency generator for 6502 programs so that tepples first point, "only things that need to get rebuilt get rebuilt" could be true for my project. It worked out ok, but I eventually decided the size of my project and the speed with which it builds from clean didn't really warrant the extra step. I'm not even sure I really need make. I discovered -j2 recently as well though, and it turned my half-second compile into an almost instantaneous compile.
But does this half second include converting and compressing your graphic tiles, DPCM samples, and the like?
I suppose it could, if I wanted to. My approach to generating graphics and level data has been to write GUI apps which, once you've created assets you'd like to use in a game, you hit "generate," and it places output files into a specified path. Once I've done this, I usually go into notepad++ and hit "F10" to clean, make and run my ROM (F10 is hooked up to an NppExec script). If I wanted to, I suppose I could invoke make and an emulator from my graphics and level editors. I don't anticipate this would add to the build time at all. For now though I don't mind "visiting" my graphics and level editors and returning to notepad++ to build/run. I think the times where I desire the quickest response are when I am fixing a strange bug, adding a new feature or tweaking some gameplay feature. Adding a new graphics or sound asset usually doesn't require frequent rebuilds.
Gradualore wrote:
Adding a new graphics or sound asset usually doesn't require frequent rebuilds.
It does if you're going through a cycle of tweak the asset, play test, tweak the asset, play test.
My general rule of thumb has been if I find myself in a cycle that involves a lot of wasted time, I ought to optimize it. So far this has been minimal with asset creation for this project. If this ever becomes more exaggerated, I'm certain I'll add some sort of build/run feature from my editors as well.
on topic: Michael Martin's NES 101 tutorial (available on main page) uses the P65 assembler (it is a perl script that actually comes with the tutorial). I found it somewhat similar to Asm6. I think if you got familiar with that tutorial converting his code to asm6 would be a snap.
I want to initiate in this nes assembler world, but my experiences are with 8088 assembler. Where I could get a 6502 assembler programming tutorial from the "Hello Wolrd" Beginning to be Able to make a Accion NES game.