The Complete Beginner's Guide to NES Development

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

User avatar
quexxon
Posts: 7
Joined: Thu Apr 05, 2012 11:48 am
Location: South Carolina (USA)

The Complete Beginner's Guide to NES Development

Post by quexxon » Wed Apr 11, 2012 9:06 am

Hello everyone, I'm a long time reader of this forum and first time poster. For a while now I've been considering what unique contribution I might be able to make to this community. I've been taking stock of the few weak areas that exist in the brilliant repository of information that is the nesdev community, and trying to synchronize some of those weaknesses with my particular skill set. I'm only a mediocre programmer, so offering original advice to anyone other than absolute beginners is probably best left to the more skillful. I have no experience with reverse engineering, so any contribution on that front is really out of the question. What I do have, however, is a certain precise, clear, and logical command of the English language, which is a byproduct of my current educational situation and future profession, i.e., professor of theology/logic/philosophy. I also have the luxury of time, considering that the office job that pays my tuition requires very little effort and provides ample opportunity for what I have termed "real work." That being said, one of the primary weaknesses that exists within the community is the lack of a unified, comprehensive, go-to resource for complete beginners.

Invariably, when a total beginner asks for advice, they are pointed to a vast stratum of scattered resources that provide only part of the total knowledge required to get started with NES programming. In many cases, these resources further refer the reader to more necessarily prerequisite resources. The end result is that beginner is thrown into a endless loop of documentation grepping. In order to solve this problem, I propose to write a single, comprehensive, unified resource that gently guides complete beginners through every step (inasmuch as is reasonably possible; definition of "reasonably" forthcoming) of the NES development process. This guide will assume that the reader knows absolutely nothing about programming and will work from that point to provide a firm foundation in the wide array of skills and knowledge necessary to develop for the NES.

While there is certainly a large dose of practical truth to the conventional wisdom that one's first exposure to programming should not be assembly language, it is also true that this is not an impossible feat; I'm a living, breathing example of someone who only shallowly dabbled in high-level languages before truly learning to program with assembly. Furthermore, this can easily become another of those endlessly recursive loop situations. The fact is, you have to start somewhere, and you might as well start with the language that immediately enables you to reach your end goal (i.e. 6502 assembly for NES development) rather than an endless regression of stepping stones. I would also contend, from personal experience, that high level languages are often more understandable with a heavy dose of experience in assembly.

Therefore, the book will be laced throughout with a thorough introduction to the 6502 microprocessor and its associated assembly language, and will be written in a progressive tutorial style with separate elements of development (scrolling, collision detection, NMI handling, etc.) broken up into modules. Readers will be involved in hands-on development by writing two games in a step-by-step fashion, one game that will be pre-written and systematically revealed throughout the book and another complementary game that the reader will write to exercise their new skills. Besides technical skills pertaining directly to game mechanics, like those previously mentioned, the book will also guide the reader through game planning, character and story development, music, artwork, best practices, etc. In addition to the tutorial that comprises the main body of the work, there will be a series of extensive appendices which compile all available technical information concerning the NES in a unified format. This will hopefully enable the book to serve as a valuable resource for experienced developers as well as total beginners.

This is obviously a huge a undertaking, and I don't presume to have the requisite knowledge, skill, or authority to do it alone. (For the more skeptical among you who may be in doubt at this point, the length and complexity of such a project is not really an issue; I'm a grad student, so excessively copious amounts of technical writing is my daily bread.) That's why I'm presenting it here. I plan to make this book available during writing, in true open source development style. I haven't yet decided the best way to do this; I will obviously need to be able to maintain some level of control to retain a unified style and vision. My current solution is to make the brainstorming, code, and outlines for every chapter open source, and make the actual chapter text available for discussion and fact-checking rather than direct editing.

At every step of the process I will be dependent upon the knowledge of the community, and I also want to make myself accountable to the community. If this is going to be a resource that is beneficial to the widest audience, it will depend on your advice, needs, experience, and wisdom. The knowledge required to learn NES development is already here, as evidenced by the fact that this is my first post; I've been hanging around here for a while now but have never posted, or even joined the forum until a few days ago, because all my questions already have answers. The community has given and given to me, and it's time that I stopped leeching and started giving back. I will probably host the project on github (info forthcoming), but first, I'd like to get some feedback.

Any advice about the content and process of this project, or whether the project is even wanted/needed, will be greatly appreciated. Thanks so much to the whole community for the role that you've played in my development as a programmer; I hope that this project can serve as a true sign of my gratitude. Stay posted for a broad project outline and a list of guiding principles.
Last edited by quexxon on Wed Apr 11, 2012 1:47 pm, edited 2 times in total.

User avatar
Dwedit
Posts: 4354
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Post by Dwedit » Wed Apr 11, 2012 9:15 am

Paragraph breaks please? This post is a wall of text.
Edit: Thanks.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
tokumaru
Posts: 11862
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: The Complete Beginner's Guide to NES Development

Post by tokumaru » Wed Apr 11, 2012 9:51 am

I'm OK with you writing an introductory book, as long as you use paragraphs! :lol: Just kidding, since your english is very good I'll assume that something happened during a copy/paste procedure that killed your paragraphs.
quexxon wrote:While there is certainly a large dose of practical truth to the conventional wisdom that one's first exposure to programming should not be assembly language, it is also true that this is not an impossible feat; I'm a living, breathing example of someone who only shallowly dabbled in high-level languages before truly learning to program with assembly.
A lot of people have indeed started with assembly, but I really wouldn't recommend it. There are certain things we learn from high level languages (specially object-oriented ones) that are extremely useful for developing games. Newbies who jump straight into assembly might even be able to make working code, but it will often be a big mess of unmaintainable spaghetti code, as opposed to well structured modular code someone experienced with object-orientation would produce. This kind of messy code eventually blows up on their faces because of all the complexity and lack of organization, and they are never able to finish the games because of this.
I would also contend, from personal experience, that high level languages are often more understandable with a heavy dose of experience in assembly.
I find it important that a person who plans on working with assembly has contact with high level languages, even if it's after learning some assembly. Hopefully, the high level language will help them see what they were doing wrong before, and realize that there are certain "rules" that make everything easier and more maintainable.

Maybe you can have blocks of pseudo-code in the book, detailing how certain parts of the game will work before implementing that same logic in assembly. That way you can still convey the notion of loops, decision blocks, objects, etc. without having to teach an specific high-level language. This will teach people to design their programs in a better structured way, and how to properly represent those structures in assembly.
Therefore, the book will be laced throughout with a thorough introduction to the 6502 microprocessor and its associated assembly language, and will be written in a progressive tutorial style with separate elements of development (scrolling, collision detection, NMI handling, etc.) broken up into modules. Readers will be involved in hands-on development by writing two games in a step-by-step fashion, one game that will be pre-written and systematically reveal throughout the book and another complementary game that the reader will write to exercise their new skills.
I like this idea. Although I have decided to "master" the 6502 before writing any game code (i.e. I first made sure I understood what each instruction did before attempting to put them together in a meaningful way), I imagine that jumping right into practical examples might be more intuitive.

Unlike the Atari 2600, the NES isn't so dependent on instruction timing, and isn't so limited that non-obvious tricks are practically a requirement. The logic is more important than the technical details, except for interfacing with the PPU and APU, but if you keep those to a minimum at the beginning it should be OK.
At every step of the process I will be dependent upon the knowledge of the community, and I also want to make myself accountable to the community.
I'll try to help as much as I can.
Any advice about the content and process of this project, or whether the project is even wanted/needed, will be greatly appreciated.
I'm not sure if it's needed (new NES games are not a basic necessity in life), but it's definitely wanted. Every once in a while people show up here wanting to make NES games, and we always have to go through the basic initiation ritual, and more often than not the newbies just vanish in frustration. It would be much easier on them and on us if we had the book you're describing. Newbies would have solid initial guidance, and support from the community once they really need it.
Last edited by tokumaru on Wed Apr 11, 2012 9:58 am, edited 1 time in total.

User avatar
cpow
NESICIDE developer
Posts: 1097
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Re: The Complete Beginner's Guide to NES Development

Post by cpow » Wed Apr 11, 2012 9:52 am

quexxon wrote:Stay posted for a broad project outline and a list of guiding principles.
If it gets beyond this it'll be a worthy venture. I'd enjoy contributing whatever I can.

But my guess is you'll realize the reason most people hyperlink prior work, such as the technical manuals for the 6502, or technical detail of the NES components available online. Most decide it's not worth their time or effort rewriting it to fit their ideal style.

If your goal is merely to document, not to learn-so-you-can-go-and-do-it-yourself, then you might have a better chance than most that come here looking for how to make their own game.

Good luck.

User avatar
quexxon
Posts: 7
Joined: Thu Apr 05, 2012 11:48 am
Location: South Carolina (USA)

Re: The Complete Beginner's Guide to NES Development

Post by quexxon » Wed Apr 11, 2012 11:14 am

tokumaru wrote:I find it important that a person who plans on working with assembly has contact with high level languages, even if it's after learning some assembly. Hopefully, the high level language will help them see what they were doing wrong before, and realize that there are certain "rules" that make everything easier and more maintainable.

Maybe you can have blocks of pseudo-code in the book, detailing how certain parts of the game will work before implementing that same logic in assembly. That way you can still convey the notion of loops, decision blocks, objects, etc. without having to teach an specific high-level language. This will teach people to design their programs in a better structured way, and how to properly represent those structures in assembly.
Using pseudo code is a good idea. I certainly agree that an understanding of object-oriented programming can help to clarify code and keep a project maintainable. I believe that one good way to incorporate the ideas of higher level languages might be to focus on general programming techniques as they apply to all languages (possibly presented in python-like pseudo code) and then demonstrate how these techniques can be implemented in assembly code. This way the student is learning how to think like a programmer as they learn 6502 assembly.

One thorny problem, that I'm looking to iron out from the get-go, is which assembler to use for the examples in the book. I believe that beginners may have an easier time understanding asm6 and its rather compact syntax. On the other hand, I believe that something like ca65 with, its more expansive set of directives, macros, and its associated linker, will probably be more useful in the long run, even if a little more difficult to begin with. Both of these assemblers have the advantage of being platform agnostic. Any ideas, pros/cons, other contenders, etc.?

User avatar
cpow
NESICIDE developer
Posts: 1097
Joined: Mon Oct 13, 2008 7:55 pm
Location: Minneapolis, MN
Contact:

Re: The Complete Beginner's Guide to NES Development

Post by cpow » Wed Apr 11, 2012 11:26 am

quexxon wrote: One thorny problem, that I'm looking to iron out from the get-go, is which assembler to use for the examples in the book. I believe that beginners may have an easier time understanding asm6 and its rather compact syntax. On the other hand, I believe that something like ca65 with, its more expansive set of directives, macros, and its associated linker, will probably be more useful in the long run, even if a little more difficult to begin with. Both of these assemblers have the advantage of being platform agnostic. Any ideas, pros/cons, other contenders, etc.?
I'd use the CC65 toolchain--it's got complete online documentation and is still supported/updated by the author. Plus then you're not shutting the door on those that believe C has a place in NES.

User avatar
tokumaru
Posts: 11862
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Wed Apr 11, 2012 12:15 pm

As much as I like ASM6 (and I still use it for everything), CA65 is probably the better choice for this.

ASM6 is very convenient and easy to use, since it's a single executable file that can generate NES ROMs in a one step, but I understand that at some point people might need features it doesn't offer, so it might be better to just start with CA65.

3gengames
Formerly 65024U
Posts: 2277
Joined: Sat Mar 27, 2010 12:57 pm

Post by 3gengames » Wed Apr 11, 2012 12:57 pm

So many people use NESASM3, it's one of the big ones too. I love it, IMO is probably the best overall assembler out there for NES as that's what it's for and you don't have to piece everything together with confusing syntax to have the output correct like ASM6.

User avatar
Kasumi
Posts: 1292
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi » Wed Apr 11, 2012 2:01 pm

I would also contend, from personal experience, that high level languages are often more understandable with a heavy dose of experience in assembly.
I think this is the case as well. I think it's much easier to learn what assembly is actually doing, (at least for 6502. Some others can be pretty convoluted) but it's harder to make "cool stuff" in it. It's not for a learner who wants immediate output like Hello World, but it is much easier to learn and much less abstract.

In any case, admirable goal. I've also wanted to write a 6502 guide that would teach everything one needs to know except basic math and how to read. But whenever I decide I have time to put into it, I just end up working on my NES game. :?

User avatar
Jeroen
Posts: 1033
Joined: Tue Jul 03, 2007 1:49 pm

Post by Jeroen » Wed Apr 11, 2012 2:03 pm

I've discussed this before with you, 3gen, and I stil don't know what "confusing syntax" you mean. Sure if doesnt have header support built in directly...but its hardly like asm6 requires a mountain of extra code to get running...some .orgs and .base and you're covered. (after that its pretty much nesasm...but without doing stuff without telling you :P )

User avatar
tokumaru
Posts: 11862
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Wed Apr 11, 2012 2:14 pm

3gengames, I know that you use NESASM and it's great for you, but sometimes you have to admit that what you use isn't necessarily the best, like I did with ASM6. I will not stop using ASM6, but I know that CA65 is better.

Apart from the ridiculous bugs that have been found in NESASM (some of which have been fixed, but IMO their mere existence proves how flawed the foundation of that assembler is), it has a terrible flaw: different syntax from ALL other 6502 assemblers (such as using "[]" for indirection, instead of "()"), which makes it harder to switch from it to something else later on.

Seriously, NESASM looks so good to you because it just worked for you. It's the first assembler you learned to use, so it's simply obvious that everything that's different from it will seem "confusing" to you. Programming for ASM6 is just as simple as it is for NESASM, they are just a bit different. Is it confusing just because it doesn't use NES-specific words such as "ines" and "bank"? I assure you that all the functionality (and more) is there, things just have different names. EDIT: Basically what Jeroen said.

Anyway, neither ASM6 nor NESASM are polished enough to be considered professional tools, but it looks like CA65 is, and apparently it's still worked on regularly, which makes it the obvious choice. NESASM works for you and this is great, but you have to stop advertising it like it was the best thing ever.

tepples
Posts: 22054
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Wed Apr 11, 2012 2:18 pm

What color will you paint the bike shed?

Let's get the tutorial done (and freely licensed) with one assembler, and then someone can convert it to another assembler later. And I agree that Python is a good model for pseudocode examples, not to mention a good language for implementing tools such as image file to CHR data converters.

User avatar
Kasumi
Posts: 1292
Joined: Wed Apr 02, 2008 2:09 pm

Post by Kasumi » Wed Apr 11, 2012 3:32 pm

tokumaru wrote: it has a terrible flaw: different syntax from ALL other 6502 assemblers (such as using "[]" for indirection, instead of "()"), which makes it harder to switch from it to something else later on.
I've said before this is no longer true.
edit: Wait it is! I'm man enough to admit when I'm wrong. I'll edit that old post too! Crap, I've been spreading bad information. Just double checked, it assembles to $B9 instead of $B1. I'll edit that old post too, since it may be found by others. Sorry, sorry, sorry. Nesasm loses again. Found out why I thought it was right, too. What I changed in my program was near something that should have been $B9, so I looked at the wrong thing to see what was changing. No excuse though. Doubly corrected.

But, even with that being true I don't believe one should judge a program based on bugs of old versions (ASM6 hasn't always been perfect, either.), especially when the maintainer of the current builds is entirely different from the person that introduced the flaws. There are plenty of valid beefs to have with NESASM in that first linked topic/post, though. :P The only problem I have with NESASM these days is the label length limit, but I'd still throw my vote to ASM6 for the tutorial, especially since I'm wrong about the syntax thing. That is definitely a problem for anyone who wants to migrate to or from anything else.

User avatar
quexxon
Posts: 7
Joined: Thu Apr 05, 2012 11:48 am
Location: South Carolina (USA)

Post by quexxon » Wed Apr 11, 2012 4:08 pm

tepples wrote:What color will you paint the bike shed?
Point taken; ca65 it is. I created a github repository today (no content yet, but all future updates will occur there; I will still make milestone updates and ask questions here.). I will post an abstract of principles and a provisional content outline tomorrow, and will try to commit the bulk of the first chapter by the end of the week.
Let's get the tutorial done (and freely licensed) with one assembler, and then someone can convert it to another assembler later.
The entire work will be licensed under the GNU FDL.

User avatar
MottZilla
Posts: 2832
Joined: Wed Dec 06, 2006 8:18 pm

Post by MottZilla » Wed Apr 11, 2012 5:31 pm

I personally like and use ASM6. I also like xkas for the SNES. So much easier to just open a window and type up some code and get going.

Post Reply