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

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

Post by tepples » Wed Apr 11, 2012 7:31 pm

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.

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

Post by cpow » Wed Apr 11, 2012 7:42 pm

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

User avatar
Banshaku
Posts: 2393
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Post by Banshaku » Wed Apr 11, 2012 9:18 pm

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.

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

Post by quexxon » Thu Apr 12, 2012 5:44 am

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.

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

Post by cpow » Thu Apr 12, 2012 5:46 am

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

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

Post by tepples » Thu Apr 12, 2012 5:56 am

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.

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

Post by cpow » Thu Apr 12, 2012 8:01 am

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.

User avatar
bigjt_2
Posts: 82
Joined: Wed Feb 10, 2010 4:00 pm
Location: Indianapolis, IN

Re: The Complete Beginner's Guide to NES Development

Post by bigjt_2 » Thu Apr 12, 2012 10:02 am

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.

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

Post by quexxon » Thu Apr 12, 2012 12:23 pm

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.
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.
Last edited by quexxon on Thu Apr 12, 2012 10:58 pm, edited 1 time in total.

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

Re: The Complete Beginner's Guide to NES Development

Post by tepples » Thu Apr 12, 2012 12:29 pm

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.

User avatar
bigjt_2
Posts: 82
Joined: Wed Feb 10, 2010 4:00 pm
Location: Indianapolis, IN

Post by bigjt_2 » Thu Apr 12, 2012 2:42 pm

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."

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

Post by Kasumi » Thu Apr 12, 2012 3:40 pm

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.

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

Post by 3gengames » Thu Apr 12, 2012 3:45 pm

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: Select all

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.

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

Tentative Content Outline

Post by quexxon » Thu Apr 12, 2012 10:07 pm

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

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

Post by tokumaru » Fri Apr 13, 2012 12:04 am

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.

Post Reply