The Complete Beginner's Guide to NES Development

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
The Complete Beginner's Guide to NES Development
by on (#92362)
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.

by on (#92363)
Paragraph breaks please? This post is a wall of text.
Edit: Thanks.
Re: The Complete Beginner's Guide to NES Development
by on (#92364)
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.
Re: The Complete Beginner's Guide to NES Development
by on (#92365)
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.
Re: The Complete Beginner's Guide to NES Development
by on (#92368)
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.?
Re: The Complete Beginner's Guide to NES Development
by on (#92369)
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.

by on (#92371)
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.

by on (#92373)
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.

by on (#92374)
Quote:
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. :?

by on (#92375)
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 )

by on (#92376)
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.

by on (#92377)
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.

by on (#92381)
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.

by on (#92382)
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.

Quote:
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.

by on (#92384)
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.

by on (#92391)
The workflow for ca65 isn't too different: unzip a project template suitable for the board/mapper (such as my templates for NROM and SGROM/SNROM), open main.s, and get going.

by on (#92393)
tepples wrote:
The workflow for ca65 isn't too different: unzip a project template suitable for the board/mapper (such as my templates for NROM and SGROM/SNROM), open main.s, and get going.


OT<sorta>: Any more plans for projects like these, tepples? They make great test cases for NESICIDE. :D

by on (#92397)
Kasumi wrote:
The only problem I have with NESASM these days is the label length limit,


I remember last year doing an experimental build (out of curiosity) that shows that it can be fixed but nobody got any interest in it. I don't remember where is the link though.

<sarcasm>
But let's go back to the bashing! nesasm is bad! ca65 is good! asm6 is, hmm, not nesasm so it's good!
</sarcasm>

;)

As long the tool does the job for you and you are aware of it's limitation, more power to you.

Back on topic, good luck with your project. I see some value in it.

by on (#92404)
Following is an abstract of principles to guide my writing. While many of these principles emphasize theory, I've attempted to make each praxis-oriented. I would welcome any comments, suggestions, proposed additions, requests for clarification, etc. I will post a general content outline later today.

Guiding Principles:
------------------
    - Assume nothing. This is the only way to ensure that this book is a viable resource for beginners. In practice this means that no technical term, concept, or code snippet is introduced without being thoroughly and lucidly defined, explained, commented, etc.
    - Knowledge of general programming concepts must precede a description of their 6502 implementation.
    - A diagram/table speaks a thousand words, but that doesn't mean that a thousand words should be neglected in explaining it.
    - In reference to the previous principle: Clear structure may save a few keystrokes.
    - In reference to the previous two principles: verbosity != quality
    - In reference to the previous three principles: The moral of the story is... Use as many words as necessary to provide a clear and complete description, and use no more than necessary.
    - Don't reinvent the wheel, don't be ashamed to stand on the shoulders of giants, and, likewise, give credit where credit is due.
    - In NES development, EVERYONE is a hardware person, aka, your dazzling knowledge of assembly routines will not hide your blinding ignorance of the PPU.
    - Modularization is a boon to clarity and manageability, aka, modularization is mandatory. This applies to code, documentation, and life.
    - In reference to the above: Modularity at the expense of cohesion is segregation.
    - Saving bytes/cycles matters and should be emphasized from the beginning.
    - Unnecessary complexity is a sign of arrogance, boredom, or a deficient knowledge of the topic being taught; A good teacher can make the inherently complex simple.
    - Don't delay in letting readers get their hands dirty; many people give up if they can't see that the basics are a means to an end. For a good example see Mark Pilgrim's python book.
    - Work from the macrocosm to the microcosm; it's hard to get the big picture when you start with the minutiae.
    - Abstraction can aid in memory and readability but should always follow concrete reference.
    - Adopt a standardized vocabulary where possible; use terms consistently regardless of standardization.
    - Don't be afraid to offend the reader's intelligence; one reader's intelligence is another's lack of experience.
    - Write daily, without exception and regardless of inclination.

by on (#92406)
Banshaku wrote:
I remember last year doing an experimental build (out of curiosity) that shows that it can be fixed but nobody got any interest in it. I don't remember where is the link though.

This is just like economics...the top two tend to push out the contenders until one of the two has a failing that provides an in for one of the not-top-two to come in and take its place. Same story with emulators. No matter how hard you try, it's impossible to get people to add another emulator to their two favorites, "Nintendulator and Nestopia". :D

by on (#92407)
Even harder is getting people to add another debugging emulator to their favorites, which include Nintendulator and the Windows version of FCEUX. I chose FCEUX mostly because it at least half-works in Wine (albeit with no sound and some crashiness related to closing the Hex Editor). I hope to switch once NESICIDE is "ready", as having sound, debugging, and ability to run on my Linux laptop at the same time would be my killer feature.

by on (#92408)
tepples wrote:
I hope to switch once NESICIDE is "ready", as having sound, debugging, and ability to run on my Linux laptop at the same time would be my killer feature.


Perhaps, since we're discussing English and guiding principles here, you could help me define "ready". :D

quexxon wrote:
- Work from the macrocosm to the microcosm; it's hard to get the big picture when you start with the minutiae.


It's also exceedingly hard [my opinion] to describe the big picture [being able to produce a final product, a NES game], without making reference to any of the system limitations to overcome which themselves require explanation of the quirks of the system components, etc. Perhaps another principle: Try to avoid the phrases "which will be described later" or "see chapter 59 for more detail".

A good micro-to-macrocosm explanation I usually cite is Charles Petzold's "Code: The Hidden Language of Computer Hardware and Software". In my opinion, a wonderfully constructed progression through basics of number systems, codes [Morse/Braille/etc], simple circuits [mechanical/electrical], basic computer components [CPU, RAM, I/O], all the way up to a functioning computer and on into OS/UI stuff. Each chapter "revealing" a bit more about the computer being "built" along the way.

The difference is that it's not a "how to" book. If it were, each chapter would get progressively longer, quickly turning it into a phone book.
Re: The Complete Beginner's Guide to NES Development
by on (#92410)
YESSSSS! WRITE THIS!!! A book like this would be awesome!

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.


Same exact thing with me. I don't know why it's insisted that people start learning another higher level language first. I had dabbled in so many and quickly gave up in frustration over the years. Assembly is the first thing I've ever been able to follow through and finish a project in. Now I'm moving on to learning C (with the intent on moving on to learn C++, C#, Java, etc.) and it is INFINITELY easier to pick up the stuff I'm learning than it ever has been before. Assembly has been an amazing building block.

But aside from that personal digression, whenever I see one of those "How Do I Get Started" posts in the Newbie Help Center, I usually drop in a couple links to some articles I found helpful in the beginning describing the bare, bare basics of how computers in general work. They're just some articles on howstuffworks.com that go over bits, bytes, boolean logic, binary math, etc. Perhaps that kind of materail would be helpful in an intro chapter?

I think your guiding principles on writing it seem sound, as well. Not really sure I have anything to add there. I'd like to help however possible as I'm also trying to find ways to give back now that my game's done.

by on (#92412)
Thanks to everyone for the great feedback so far!

cpow wrote:
Perhaps another principle: Try to avoid the phrases "which will be described later" or "see chapter 59 for more detail".


I agree. These sorts of constant references are typical of printed works where it is necessary to reduce repetition in order to reduce the cost involved with printing extra pages. Excessive page flipping is a totally unnecessary evil in regard to a digital book where there is no cost associated with repeating text. This problem can also be solved with a well planned, progressive structure. On the other hand, I don't see any problem with referring to an appendix as a complete reference on a certain topic. For instance, "for a complete list of 6502 instructions, their cycle lengths, and affected flags, please see Appendix B."

bigjt_2 wrote:
whenever I see one of those "How Do I Get Started" posts in the Newbie Help Center, I usually drop in a couple links to some articles I found helpful in the beginning describing the bare, bare basics of how computers in general work. They're just some articles on howstuffworks.com that go over bits, bytes, boolean logic, binary math, etc. Perhaps that kind of materail would be helpful in an intro chapter?


Chapter 00 will focus on ground level basics concerning hardware and general programming concepts. Chapter 01 will be an introduction to number systems.

Quote:
I'd like to help however possible as I'm also trying to find ways to give back now that my game's done.


Thanks! You can stay tuned to the github page for updates. Starting this weekend, I will try my best to make daily commits. You're more than welcome to join in the brainstorming, outlining, resource gathering, and writing.
Re: The Complete Beginner's Guide to NES Development
by on (#92413)
bigjt_2 wrote:
I usually drop in a couple links to some articles I found helpful in the beginning describing the bare, bare basics of how computers in general work. They're just some articles on howstuffworks.com that go over bits, bytes, boolean logic, binary math, etc. Perhaps that kind of materail would be helpful in an intro chapter?

Yeah, I've tried to cover basic digital logic and computer science topics in this page on the wiki.

by on (#92415)
quexxon wrote:
Thanks! You can stay tuned to the github page for updates. Starting this weekend, I will try my best to make daily commits. You're more than welcome to join in the brainstorming, outlining, resource gathering, and writing.


Joined.

tepples wrote:
Yeah, I've tried to cover basic digital logic and computer science topics in this page on the wiki.


Yep, this was exactly the subject matter I was talking about. That part of the wiki you created is a really nice, extensive coverage of the "pre-basics."

by on (#92416)
Quote:
Perhaps another principle: Try to avoid the phrases "which will be described later" or "see chapter 59 for more detail".

On that note, one thing I'd like to throw out there is this macroassembler thing: http://www.exifpro.com/utils.html

It's a pretty beautiful little tool for teaching straight 6502, I think. It allows you to write and run code immediately all with the same interface. The code only needs a single .org statement which is a little easier to explain than the header/NES initialization a rom would require, and there's no need for a second program to run the code. You can teach literally one instruction at a time, and have them run it through that to see exactly how it works.

It allows you to step through code and see immediate changes. So the user can see that CLC clears the carry flag. They can see how the flags are affected by cmp or whatever else.

by on (#92417)
I dislike how the nerdy nights don't go over a general register description, some functions, but no detail so that later on when you see stuff like sprite OAM, it's not like:

Code:
LDA #$00
STA OAMAddr ;Store low byte of OAM.
LDA #$02
STA OAMDma ;Store high byte of OAM.


as it's bullshit because that's not what it does. It bothers me the comments on it are basically that without labels.
Tentative Content Outline
by on (#92423)
Following is a VERY rough content outline. The first several chapters are fairly solid, I think, but there are obviously some huge gaps in later chapters; particularly following chapter 0A. Once I finish writing through chapter 08 (or the content currently labeled chapter 08 ), I will have a much better idea of what remains to be covered. Anyway, I wanted to get this posted, warts and all, to get some eyes on it and some feedback (particularly on chapters 00 through 0A; I know that the rest is a real mess). This will be the last content that I will post here, excluding notifications of major updates. All future content will be committed directly to my github repository.

The book will be structured around four learning objective modules (general programming, NES-specific programming, game development concepts, and hardware). Each chapter will begin with a table illustrating the major concepts that will be covered under each of the four learning objective modules. An item's inclusion in this table does not suggest that the item will be covered exhaustively in the respective chapter, only that it is one of the primary topics being addressed in said chapter; the same item may appear in the introductory table of several chapters. Note: None of the information in parentheses following the tentative chapter titles is even remotely exhaustive; these supplementary comments are only intended to clarify the general scope of information covered in the chapter.
    -- Chapter 00 - Mise en Place: Introductions & Definitions (What is programming, a microprocessor, a programming language, an assembler, etc.?) Sidebar: How to set up the work environment required for this book on Linux, Mac, and Windows systems.
    -- Chapter 01 - Number Systems
    -- Chapter 02 - General Programming Techniques & Digital Logic (An introduction)
    -- Chapter 03 - A Crash Course in 6502 Assembly (Basis of game introduced: I will probably use a simplified version of tepples' NROM template. This initial code example will be introduced early even though it will be completely incomprehensible given the reader's current knowledge. The code will be accompanied by the promise that the reader will be fully equipped to understand it by the end of chapter 08. Concurrently, the reader will be challenged to persevere by looking forward to this initial goal.)
    -- Chapter 04 - The Main Program Loop (Intro to concept of interrupts/Basic structure of Assembly code)
    -- Chapter 05 - Warming up the NES (Init Code/Brief intro to the concept of mappers)
    -- Chapter 06 - Putting Something on the Screen (PPU, Sprites, Nametables, Looping Techniques extended)
    -- Chapter 07 - Making Things Move (Latching controllers, basic movement)
    -- Chapter 08 - Interacting with the Environment (Collision Detection. By this point, the reader will have been introduced to every element of the initial code example. The goal here is to attempt to hold the reader's attention through the potentially tedious basics by maximizing the sense of accomplishment upfront, i.e. the reader can now totally understand the code that looked so arcane when introduced in chapter 03.)
    -- Chapter 09 - Beyond the Basics (Less common 6502 instructions, More Economic Programming Techniques)
    -- Chapter 0A - Before You Go Any Further (VBlank and other limitations, NMI handling)
    -- Chapter 0B - Ready Player 1? (The game begins in earnest. Focus on different genres, character design, story development, mechanics, etc.)
    -- Chapter 0C - Working with multiple sprites
    -- Chapter 0D - Scrolling
    -- Chapter 0E - Making a Sound (APU - Essential principles of music, digital audio, and tone generators)
    -- Chapter 0F - Saving
    -- Chapter 10 - Beyond NROM (Mappers in depth - When is a mapper necessary? Which mapper should you use and how do you use it?)
    -- Appendix A - Complete 6502 Assembly Reference (Addressing Modes, Instructions, Flags, etc.)
    -- Appendix B - NES Hardware Reference
    -- Appendix C - Tools (Other assemblers, tile editors, NTRQ/Pulsar, etc.)
    -- Appendix D - Odds & Ends (Number system conversion tables, ASCII table, etc.)
    -- Glossary
    -- Index

by on (#92425)
Personally, I wouldn't write much about mappers. When a person comes to the point of needing mappers, they should already be fairly experienced. Trying to introduce the concept of bankswitching too early will just confuse the hell out of people. IMO you should mention mappers and tell your readers what they are for, but not much more than that.
Re: Tentative Content Outline
by on (#92432)
quexxon wrote:
    -- Chapter 09 - Beyond the Basics (Less common 6502 instructions, More Economic Programming Techniques)
    -- Chapter 10 - Beyond NROM (Mappers in depth - When is a mapper necessary? Which mapper should you use and how do you use it?)


I see these as more appendix-like material rather than thrown in the middle, but that's counter to your guiding principle, so I'm just stating it as my opinion. The first game you strive to create should be basic enough that it doesn't need too many cycle-counting tricks [as you laid out in your general principles], and certainly shouldn't be bigger than 16 or 32KB.

quexxon wrote:
Sidebar: How to set up the work environment required for this book on Linux, Mac, and Windows systems.


Would such work environment perhaps include an IDE? :D

by on (#92433)
In Chapter 8, are you planning on covering background collision detection, as well? Or just sprite to sprite collision? I'm guessing the latter. It would probably be best to cover just basic collision in Chapter 8 assuming a non-scrolling game and then come back and re-cover it in Chapter 0D when you talk about scrolling. (BTW, I LOVE that you're using hex values for the chapter numbers!)

Scrolling does add some more complication to sprite and background collision. And the things you'll probably cover in Chapter 9 will be useful in scrolling collision. (e.g. using 16 bit numbers, high byte for screen number, low byte for xScroll, carry flag to inc or dec which screen the camera/objects are on once xScroll or their x coords wrap from 255 to 0 or vice versa.)

Also, are you planning on covering background compression and de-compression in your Scrolling chapter? That may be confusing to beginners, but it's essential to building a scrolling game -- unless it's a two-screen sports game or the shortest scrolling platformer you've ever played. :-D There are also infinite methods to handle background compression, so we'd probably better discuss which would be the easiest to understand for a newb who's read up through Chapter 0D, even if it's not the most efficient. We can always explain that the reader is free to explore more efficient yet harder to understand compression methods once they are done with the book.

cpow wrote:
quexxon wrote:
Sidebar: How to set up the work environment required for this book on Linux, Mac, and Windows systems.


Would such work environment perhaps include an IDE? :D


You whore. :-D Just playing, Chris. Your project well deserves some whoring because it's coo', so whore away! :-)

by on (#92435)
bigjt_2 wrote:
You whore. :-D Just playing, Chris. Your project well deserves some whoring because it's coo', so whore away! :-)

:oops:
Caught, pants down.
:shock:

Seriously, though, tepples' example projects [and a few others like Shiru's full-blown Alter Ego written in C] make for wonderful tutorial projects. I'm hoping to include parts of them as template projects for starting users. Specifically, the parts such as linker configuration that everyone [myself included, sometimes] whines about as being the roadblock-to-entry for using the CC65 toolchain.

by on (#92436)
Not sure if you will find use in adding little bubble hints or tips; but it might be useful to cater to more advanced coders who may want to include some DPCM samples and reference the DPCM and controller glitch or other glitches that the hardware has.

Also not sure your intentions or your potential readers' intentions for testing environments, but if a lot of illegal opcodes are used in your main loop in Nintendulator -- even if the message menu is closed -- your emulation will significantly degrade in speed.

Just some food for thought.

by on (#92439)
tokumaru wrote:
Personally, I wouldn't write much about mappers. When a person comes to the point of needing mappers, they should already be fairly experienced. Trying to introduce the concept of bankswitching too early will just confuse the hell out of people. IMO you should mention mappers and tell your readers what they are for, but not much more than that.


Thanks for the feedback everyone! Perhaps a more extensive coverage of mappers and bankswitching is best reserved for an appendix? I would like to include them because I want the appendix to be a reasonably "complete" go to reference.

cpow wrote:
I see these as more appendix-like material rather than thrown in the middle, but that's counter to your guiding principle, so I'm just stating it as my opinion. The first game you strive to create should be basic enough that it doesn't need too many cycle-counting tricks [as you laid out in your general principles], and certainly shouldn't be bigger than 16 or 32KB.


The first game will certainly be at or under 16KiB and will definitely not require that the reader think too much about cycle counting. However, cutting costs will be taught as a core principle of good coding rather than an advanced programmer's trick. I've heard far too many gray-haired hackers complain that the younger generation has no conception of the cost an instruction. They're correct. Counting cycles is an essential skill that reflects a practical knowledge of the targeted hardware.

Quote:
Would such work environment perhaps include an IDE?


At first, the only tools will be a text editor, an assembler, and a brain. I don't want the reader to use a time saving tool at the expense of a clear understanding of the concept being learned. I think that this is particularly the case will tile editors. However, once core concepts have been covered then other tools will certainly be introduced to save time and ease development. And, if the time is right, then a certain IDE might be a likely candidate for inclusion :wink:. All tools will need to be stable, accurate, and platform agnostic. In the appendix on tools I will include platform specific tools so that no worthy contenders get neglected, but I won't be able to recommend a tool in the main body of the text that not everyone can use (of course, this poses no problem for nesicide!).

bigjt_2 wrote:
In Chapter 8, are you planning on covering background collision detection, as well? Or just sprite to sprite collision? I'm guessing the latter. It would probably be best to cover just basic collision in Chapter 8 assuming a non-scrolling game and then come back and re-cover it in Chapter 0D when you talk about scrolling.


You are correct, chapter 08 will most likely include only sprite-to-sprite collision. Background collision will be reserved for the actual game, and a more dynamic background. Like tepples' NROM template, chapter 08 will probably just use a horizontal plane and two boundary blocks for collision detection.

Quote:
Also, are you planning on covering background compression and de-compression in your Scrolling chapter?


Yes, compression is too ubiquitous, and too useful, to be ignored.

cpow wrote:
Specifically, the parts such as linker configuration that everyone [myself included, sometimes] whines about as being the roadblock-to-entry for using the CC65 toolchain.


CC65 linker configuration will be covered at length in some chapter; this is a very handy tool!

B00daW wrote:
Not sure if you will find use in adding little bubble hints or tips; but it might be useful to cater to more advanced coders who may want to include some DPCM samples and reference the DPCM and controller glitch or other glitches that the hardware has.


As far as advanced tips go, I will probably mimic the style of old Osborne microcomputer guides, i.e. heavily-weighted text for essential topics and regular weight for deeper discussion of those topics. I will cover every every hardware "glitch" that I'm aware of (or that any kind person makes me aware of!) in the NES hardware appendix, and probably the main text as well.

by on (#92440)
Even for beginners, if its a complete guide you should cover the "beginner" mappers like UNROM. I think much more emphasis should go into game structure and design too. How to arrange a board game, platformer, scrolling shooter, etc. Could have a chapter at the end of the book for each of those with the general game concepts used?

Will also need lots more about the other apps besides assemblers like debugger/graphics/hex editors.

by on (#92441)
bunnyboy wrote:
Even for beginners, if its a complete guide you should cover the "beginner" mappers like UNROM.

If you do, I'd start with CNROM, because the concept of CHR bankswitching is easier to understand (e.g. the program doesn't crash if you do something wrong). Once you have covered that, you can proceed to PRG bankswitching, but with a fixed bank (swapping the whole 32KB of PRG is a bit hardcore for beginners, IMO).

Quote:
I think much more emphasis should go into game structure and design too. How to arrange a board game, platformer, scrolling shooter, etc. Could have a chapter at the end of the book for each of those with the general game concepts used?

Agreed. After introducing the basic concepts (sprites, maps, collision, physics, etc.) you could have sections for specific game types, detailing how those concepts would be applied in each case.

by on (#92443)
Speaking as an assembly illiterate beginner I'd really like to see this work start with C. I've seen many assembly based tutorials and, in the end, I still feel like the examples are blocks of arbitrary code. cpow has written an excellent IDE for NES cc65 development. Higher level languages should be the gateway drug to assembly.

If this could be steered towards NESICIDE and cc65 I'd gladly play guinea pig/baseline student for this.
Re: Tentative Content Outline
by on (#92451)
quexxon wrote:
-- Appendix C - Tools (Other assemblers, tile editors, NTRQ/Pulsar, etc.)

How NTRQ/Pulsar are related to homebrew development? Anyone managed to use them to make music for homebrews?
Re: Tentative Content Outline
by on (#92604)
quexxon wrote:
- Write daily, without exception and regardless of inclination.


Quote:
Apr 13, 2012

Update README
5549e5278b Browse code
quexxon authored 5 days ago

Apr 11, 2012

first commit
7bc83b63df Browse code
quexxon authored 7 days ago



:cry:

Fail.

by on (#92612)
I admit it would be mildly amusing if this were all an elaborate hoax.

by on (#92613)
He probably realized that, as the least experienced of all, my opinion to completely rewrite his tutorial for NESICIDE and cc65 was priority ONE.

As anyone who has worked with EDLIN knows it can take weeks to replace each instance of the word "assembly" with "C".

by on (#92618)
slobu wrote:
He probably realized that, as the least experienced of all, my opinion to completely rewrite his tutorial for NESICIDE and cc65 was priority ONE.

The suggestion to use the CC65 toolchain was only partly slanted toward the *possibility* of adding C-language tutorial material to the work. Many have used the assembler/linker (ca65/ld65) alone without a hint of actual C code.

The suggestion to use NESICIDE was pretty selfish. :shock:

slobu wrote:
As anyone who has worked with EDLIN knows it can take weeks to replace each instance of the word "assembly" with "C".


Just use "source code" then it doesn't matter.

by on (#92629)
cpow wrote:
slobu wrote:
He probably realized that, as the least experienced of all, my opinion to completely rewrite his tutorial for NESICIDE and cc65 was priority ONE.

The suggestion to use the CC65 toolchain was only partly slanted toward the *possibility* of adding C-language tutorial material to the work. Many have used the assembler/linker (ca65/ld65) alone without a hint of actual C code.

The suggestion to use NESICIDE was pretty selfish. :shock:

slobu wrote:
As anyone who has worked with EDLIN knows it can take weeks to replace each instance of the word "assembly" with "C".


Just use "source code" then it doesn't matter.


Sorry, was being facetious. Sometimes joking around doesn't translate well via text.

I was being serious about starting with a higher level language to ease the beginner in. I've seen enough ASM programming tutorials for ASM programmers written by ASM programmers. While people may have some familiarity with ASM when the NES came out C and other higher level languages are now the norm.

It sounds like he's too far along to change gears. Regardless, the more tutorials on NES development the better I say.

by on (#92632)
slobu wrote:
It sounds like he's too far along to change gears.

Too far along? There's nothing but the README on github.

I too was being facetious and poking fun at the broken promise [daily updates]. I am very much looking forward to reading/helping--hell, I'd even volunteer to take over the project if it has truly been abandoned [though, taking over isn't the right term since I'd be inheriting a set of principles, not a partially completed product]. So part of my facetiousness was jumping in only five days after the promise was made to point out that it had already been broken. I know perfectly well from my own experience that we all have busy lives...so it was meant as a joke/prod. :lol:

by on (#92822)
404
:(

by on (#92829)
I guess this project didn't go very far, huh?

by on (#92834)
tokumaru wrote:
I guess this project didn't go very far, huh?

I'd love to take it up myself. I'm not much of a writer, though, or at least I don't think I am. I have trouble finding the sweet spot between writing too much detail to cause boredom and writing not enough to cause disinterest. Even have that problem in casual conversation...

I actually started thinking about how best to convey the reader through the experience. I think it'd be great to make an adventure tale out of making a NES game. I would love to be able to weave the lessons into a sort of parallel adventure where you're reading about some character's activities and at the same time learning things. Each chapter (level, really), would provide opportunities to gather experience points, items, etc., useful in later levels. Viscious code snippets snip and spit at you from the page!

But then I get stopped by the inevitable. Why spend time writing about the 6502 innards...it's been done before. Why spend time writing about computers, assemblers, or code constructs -- it's been done before. In general, except for the PPU, APU, and mapper technical detail, all of the NES has been described just about anywhere else...so why not just create a document full of links to prior art.

The answer...probably...is that if I [or anyone] *did* spend the time writing a Complete guide, it'd be read by a few, maybe a lot if you're lucky. Even something like "Racing The Beam" I'm sure has a paltry readership compared to oh...I don't know..."Hunger Games". It'd be a fun adventure in the creating and in the feedback from those that might actually read the finished work. But in reality would anyone wanting to create a NES game pick up such a work and read it cover-to-cover? Not I...I'm an engineer. I need Google, and that's about all.

by on (#92838)
cpow wrote:
Why spend time writing about the 6502 innards...it's been done before. [...] In general, except for the PPU, APU, and mapper technical detail, all of the NES has been described just about anywhere else...so why not just create a document full of links to prior art.

Good point. But the CPU examples in the old 6502 books would need to be adapted to use NES I/O rather than Apple II, Commodore 64, or Atari 400 I/O. That raises copyright issues if the old 6502 books aren't freely licensed.

by on (#92843)
tepples wrote:
That raises copyright issues if the old 6502 books aren't freely licensed.


It falls into all the outs for 'fair use' though. Educational, partial use, non-fiction, and no effect on the market. Not to say there couldn't still be a problem but it seems pretty safe.

by on (#92890)
Bob Rost is usually pretty permissive about adapting his work
http://bobrost.com/nes/

Maybe changing the coursework to use NESICIDE and cc65 would be a good idea.

by on (#92895)
slobu wrote:
Bob Rost is usually pretty permissive about adapting his work
http://bobrost.com/nes/

Maybe changing the coursework to use NESICIDE and cc65 would be a good idea.


Problem with that is...it's coursework. The lecture slides are mostly high level discussion and administrivia, which hopefully was filled in with a deluge of technical discussion during class hours - or the students definitely didn't get what they paid for!