Hi all. I'm just like anyone that has loved playing NES games since their creation and would love nothing more to make my own as a hobby. I've programmed in C++, BASIC in the BlitzMax IDE, and some assembly using PCSpim (MIPS if you've got a Linux box). I've attempted making my own games with object-oriented languages but never assembly.
My goal is to start out programming NES ROMs that would work on an emulator and then maybe eventually learn how to get them on a cartridge like a PowerPak. I'm very enthusiastic and motivated but I cannot for the life of me sort out what I need to learn and in what order to learn it. I've tried following some tutorials but I always feel like nothing starts from the ground up or they're glossing over details too much. This seems like a great place to start, and so I'm hoping to get some advice from the seasoned veterans here on where to begin and how to progress.
New to this, where do I begin?
Moderator: Moderators
Did you tried GBA Guy's Tutorial?
http://patater.com/gbaguy/nesasm.htm
Everything is nicely written.
Unfortunelly,there's only one mapper-NROM.
But if you don't plan a long game then it's perfect.
http://patater.com/gbaguy/nesasm.htm
Everything is nicely written.
Unfortunelly,there's only one mapper-NROM.
But if you don't plan a long game then it's perfect.
I actually have tried going through this (this is in fact the only tutorial I've tried to follow) and found that I am not using something that he included correctly or it just doesn't work. I've tried to compile his sample code and I keep getting outlandish errors. Turns out GBAGuy has also disappeared from the internet.
Yeah, please stop recommending GBA Guy's tutorials. From reading them it is clear that he didn't have a good understanding of the platform. His "classes" are full of "I don't know this", "I don't know that", "just do it like this but I don't know why", which shows that he doesn't know what he's talking about. Most of his programs don't work on real hardware because they are all wrong.
Note that I'm not attacking the guy, I'm sure he had the best intentions while writing the tutorials, but he didn't have enough knowledge to do it, so if you want to be a good programmer you shouldn't start learning from code that is just plain wrong.
Note that I'm not attacking the guy, I'm sure he had the best intentions while writing the tutorials, but he didn't have enough knowledge to do it, so if you want to be a good programmer you shouldn't start learning from code that is just plain wrong.
So I made it to Day 5 of his tutorial (Link HERE) and tried compiling the code he has on that page using the exact same files as instructed (so our.pal, our.asm, our.bkg, and our.spr are all in the same folder as nesasm.exe) and upon doing a change directory in DOS to the nesasm folder and typing "nesasm our.asm", the assembler clearly tries to run but it says "Can not open input file 'our.asm'!"
Do you also need something more visual?muffins wrote:Apparently I need something more basic.
NES programs are commonly distributed in a format originally defined by a now obsolete emulator called iNES. (See iNES on the wiki.) There are three parts to an iNES file: a 16-byte header, the PRG ROM (connected to the CPU), and the CHR ROM (connected to the PPU).
He's talking about how to make a valid NES file, the structure your file has to obey for it to be recognized as a NES program by emulators. NES ROMs have a 16-byte header that describes them, followed by the program ROM banks, followed by the CHR-ROM banks, if any (there is no CHR-ROM data in games that use CHR-RAM). Most of that section is about properly setting up the header.muffins wrote:"Organizing the iNES file"
Games are interactive programs, which means that they have to constantly process input and update the simulated world (move characters, things like that). Since this is a continuous and repetitive process, this logic stays inside a loop, which repeats over and over again."The Main Loop"
The "main loop" is where all game-related logic is. It runs once per frame, so that every frame you can read input, react to that input, move the game entities around (little steps at a time), check for collisions and react to them, prepare background and sprite updates, and so on.
Thanks for the continued help, all 
Something more visual would certainly be nice because a lot of the terminology is meaningless to me if I can't directly relate it to how it fits in with the NES or the game.
I understand what a game is and how one is made using higher-level languages (since I've made a couple basic ones) and I know basics of assembly insofar as a basic instruction set involving logic gates, branches and jumps for program flow, and stores and loads to move data back and forth between memory and the processor. I am by no means a hardcore programmer; I've just dabbled in it and related my undergraduate work in mathematics (my major) and physics (minor) to the programming in order to produce a simple game. I just have no idea how all of this fits in with assembly language and the NES.
I'm currently reading through bunnyboy's NES ASM tutorial and it is the perfect level of reading for me though I feel like I won't be able to do much with it as far as making a game goes once I'm done.
Something more visual would certainly be nice because a lot of the terminology is meaningless to me if I can't directly relate it to how it fits in with the NES or the game. I understand what a game is and how one is made using higher-level languages (since I've made a couple basic ones) and I know basics of assembly insofar as a basic instruction set involving logic gates, branches and jumps for program flow, and stores and loads to move data back and forth between memory and the processor. I am by no means a hardcore programmer; I've just dabbled in it and related my undergraduate work in mathematics (my major) and physics (minor) to the programming in order to produce a simple game. I just have no idea how all of this fits in with assembly language and the NES.
I'm currently reading through bunnyboy's NES ASM tutorial and it is the perfect level of reading for me though I feel like I won't be able to do much with it as far as making a game goes once I'm done.
-
MetalSlime
- Posts: 186
- Joined: Tue Aug 19, 2008 11:01 pm
- Location: Japan
Here's how I learned NES programming:
I started with bunnyboy's Nerdy Nights tutorials. They are really good at teaching the basics and explaining some confusing things like attributes. I even printed them out so that I'd have them handy to use for reference. I recommend these tutorials to everybody starting out.
After finishing the tutorials, I played around writing my own programs and asking questions here whenever I got stuck. The stuff I wrote was really sloppy and bad, but this stage was really important for me because I got really familiar with 6502 assembly and the NES hardware. You have to get your hands dirty. During this time I also read every new thread posted here in the Nesdev and Newbie forums, even if I didn't understand everything people were talking about at the time. I found that over time more and more of the stuff I read on the forums "clicked".
Once I became familiar with 6502 and the NES hardware, I started tracing commercial games in FCEUXD's debugger to see how the pros did things and this really helped me with organization and writing cleaner code.
Disch's NMI/Frame document was also a big eye opener for me, but it's intermediate/advanced so you should save it until you've mastered the basics of 6502 and the PPU.
I started with bunnyboy's Nerdy Nights tutorials. They are really good at teaching the basics and explaining some confusing things like attributes. I even printed them out so that I'd have them handy to use for reference. I recommend these tutorials to everybody starting out.
After finishing the tutorials, I played around writing my own programs and asking questions here whenever I got stuck. The stuff I wrote was really sloppy and bad, but this stage was really important for me because I got really familiar with 6502 assembly and the NES hardware. You have to get your hands dirty. During this time I also read every new thread posted here in the Nesdev and Newbie forums, even if I didn't understand everything people were talking about at the time. I found that over time more and more of the stuff I read on the forums "clicked".
Once I became familiar with 6502 and the NES hardware, I started tracing commercial games in FCEUXD's debugger to see how the pros did things and this really helped me with organization and writing cleaner code.
Disch's NMI/Frame document was also a big eye opener for me, but it's intermediate/advanced so you should save it until you've mastered the basics of 6502 and the PPU.