Getting started with NES programming

Too Long; Didn't Read (TL;DR)

The Nintendo Entertainment System (NES) is really old, so to make games for it you need to unlearn your Object-Oriented ways and do some swapping around of values. It's not impossible to learn and there are a ton of resources and tools to make it easier.

Go to download sections to download compilers and graphics tools to get going on the NES.


The past half year my mind has been wandering. And this time wandering into a very weird path. Developing homebrew games. Which I always thought of as a dumb hobby, but I really enjoy it. I’ve been getting to know both the Nintendo Entertainment System (NES) and the Sega Master System (SMS), both 8-bit consoles. This post will focus on the NES.

There are a lot of resources on getting started with programming on the NES. But I found it to be kind of challenging to get started with the programming environment. There’s not a whole lot that people explain about that part of getting started.

To start out with NES programming you need to have 4 things:

  • a compiler
  • and a way to work on graphics
  • a way to make sounds
  • an emulator to test your game

Technical info

I won’t give you a complete rundown of the NES. Because other people have done this already. (see Resources) The NES will read the software you will write from a cartridge. The cartridge has a Character (CHR) and a Program Rom (PRG). The CHR rom is where the graphics are stored. And the PRG where the assembled code lives.

The CHR consists of 8x8 tiles and allow you to store up to 256 tiles per CHR bank (the minimal /default setup is with 2 banks).

The NES runs with a modified MOS 6502 processor (which were also found in Commodore 64, Apple ][ and Atari 2600 and 800) and a Pixel Processing Unit (PPU).


NES games are written in Assembly language, 6502 Assembly. Which is actually not the worst assembly language to learn, it’s sort of readable and doesn’t have a lot of commands . If you’ve done Commodore 64 assembly you can actually reuse

The most popular way to get started is to get started with the NESASM compiler. Which makes total sense because it’s really easy to setup, and there are a ton of resources for it. For example the excellent Nerdy Nights tutorial.

Another way to go is to program in a more high level language, like C or JavaScript. I like that because I’m not really fast in ASM (yet), so it allows me to focus more on the logic of the program instead of focusing on remembering ASM.

For learning programming in C for the NES, it’s still convenient to understand what’s going on. I highly recommend looking at Shiru’s examples.

At the moment I’m trying to get something going in JavaScript based on emkay’s nesly. To make it easier for people to get started with NES programming. The output of nesly can be compiled with the nesasm compiler.

What cc65 does for C and nesly for JavaScript is first compile it to ASM and then the assembler compiles it to a NES PRG and CHR bank (or ROM).





Doing Graphics

For the graphics again a lot can be said. But it’s way more useful to read the great articles below. Basically all your moving parts will be made up out of 8x8 images that can only use 3 colors at a time.

The thing to keep in mind is that you’re working with spritesheets and a very limited palette. What I found most useful is to just edit these in Gimp. Gimp can show a grid, which defaults to a grid of 10x10, but you can also set it to 8x8 pixels.

Damian Yerrick, made this wonderful tool in Python to convert an indexed PNG or BMP to a CHR tileset. Perhaps one day I’ll find the courage to rewrite that in JavaScript too.

The tool can be found in his NES development template. But I also stored in my repo just to be sure I don’t lose it 😉. It comes with an indexed png, so it’s easier to start editing.

You can also use YY-CHR (windows only, also works with WINE) to edit the sprite banks immediately and save as a CHR.

Backgrounds are a bit special in NES development because they use the same sprite sheets but setting the colors is a bit harder. The most convenient way to do this is to use Shiru’s NES Screen Tool. Which exports to binary format, but it also output a C header file, if you’re into that. If you’ve used more than one palette in the background don’t forget to export the attribute table too (that is where that information is being stored).



For sound (almost) everybody agrees that Famitracker is the tool to use. However, Famitracker is windows only (NOOO!! But sure it works with WINE). But you can also use Deflemask. Or the excellent Android app 8Tones

Including it in your project is usually done by exporting to NSF files or just plain ASM.



There are a number of great emulators. I don’t think I have to tell you a whole bunch about emulators. They’re just that: emulators. Just use a bunch of them to make sure your ROM is working properly.

A small mention for FCEUX, the windows version (even under wine in linux) has great debugging tools even though it isn’t the most accurate in emulating the ROM. You look at the nametables and the mirroring (nametables define the background and the mirroring helps with scrolling games).



General info
Programming in 6502 Assembly
Programming in C
Getting setup on Debian-like Linux (e.g. ubuntu)
# nesasm
sudo mv nesasm /usr/local/bin/nesasm

# cc65
echo "Add sources"
sudo echo "deb stable contrib" >> /etc/apt/sources.list
sudo echo "deb-src stable contrib" >> /etc/apt/sources.list

echo "Sign gpg key so you can download packages from this source"
gpg -a --export 2AF47E44 | sudo apt-key add -
sudo gpg --recv-key 2AF47E44

echo "Update and install packages"
sudo apt-get update
sudo apt-get install cc65 cc65-nes
sudo apt-get install nestopia fceux

Words by fritzvd

comments powered by Disqus