Contact, My Stuff

If anyone really, really needs to reach me, I have a hotmail account that starts like dougfraker2

Also, I’m on twitter @nesdoug2

I’ve been working on a game called Vigilante Ninja 2. I’ve moved the links and pictures to here…


Vigilante Ninja 2






And, here’s a speech synthesizer program for the NES I made…





Check back to the blog in the future, because I will be adding more example code, from time to time.

Thanks for visiting!




Oh, here’s some more stuff…some paintings I did about 2008-9. They are for sale if anyone is interested.


Girl with the Pixel Earring, 28″x22″, Acrylic on Canvas

Data Lisa, 28″x22″, Acrylic on Canvas



I wanted to make sure I covered everything. I barely mentioned mappers. If you want to make a game bigger than $8000 bytes, you would have to use a better mapper than NROM256. That would allow you to switch PRG-ROM banks in-game, and/or CHR-ROM banks. CC65/CA65 is the perfect tool for setting up the different banks. I wish I could provide source code for this, but I mostly work with small games. There are dozens of mappers. I think MMC3 is a good one. It allows both CHR and PRG swapping, and has a scanline counter.

How to get a game on a cart. You can get a usb / flash cart, such as the Everdrive or the PowerPak. You could also burn your own EPROM and solder them into an actual cartridge, but that’s a little bit above my skill level at the moment.

I skipped over Color Emphasis bits of register $2001. The 3 high bits are B, G, R…and they emphasize those colors by slightly darkening the other colors. Set all the bits will darken the whole screen. Here’s what the palette looks like under various color emphasis bits (Using an Emulator)…


Additional cc65 features.

Ullrich von Bassewitz has apparently added the entire C standard library, and some other functions. It seems you can multiply and divide numbers, it’s just very slow (perhaps a table of presolved answers would be faster).

If you #include “..\include\stdlib.h”

It looks like you can use calloc, malloc, free, and realloc. (I had a hard time testing these…I had to doubly define __STACK_SIZE__ and __STACKSIZE__ in the .cfg file. It seems to me like one of those is a typo, but I’ve seen it both ways.) You will also have to define the HEAP to use these functions…here’s a link that talks about setting up the HEAP…

I highly recommend that you DON’T use any heap functions. They produce the slowest code. And, C code on the NES is already notoriously slow.

Also interesting is rand (Random Numbers), srand (to seed the random number). And qsort (QuickSort).

If you #include “..\include\cc65.h”

You can use cc65_sin and cc65_cos (Sine and Cosine).

And if you #include “..\include\zlib.h”

You can use the built in decompression library. (I haven’t tested it).


I also never covered the IRQ. It works like NMI. It’s an interrupt that stops the normal code, and jumps to the code (defined by the IRQ vector, at FFFE-FFFF). There are 3 main ways to encounter an IRQ…

  1. if the code encounters a BRK instruction (opcode #00)
  2. music channel IRQ is turned on, and DMC sample ends
  3. mapper generated IRQ, like MMC3’s scanline counter

Only the mapper generated ones seem useful to me, as this could reliably change many PPU settings midframe with great precision…or swap tiles midframe, so you can have different tiles at the top of the screen from the bottom. Etc.


One last note. Some emulators cut off the top and bottom 8 pixels. The NES produces the full 240 pixel high image, but due to the way old TVs projected their image, they would tend to cut off 8-16 pixels off the top and bottom of the screen. Newer TVs might not cut any pixels off the top or bottom. Long story short, don’t put anything important on the top or bottom 16 pixels of the screen.

And that’s all I can think of right now. Go make some games. I bet you can make something better than I just did.

Oh, I thought of one more important thing I forgot to mention. Reading from the PPU works the same as writing to the PPU. Write the upper PPU address to $2006, lower PPU address to $2006, then READ from $2007 (LDA $2007). But, one important detail. The first read from the PPU is garbage*. The next read will be from the address you specified. The next after that will be one to the RIGHT. Etc. I didn’t design the NES, so you’d have to ask the engineers why this is so. And, like writing, you can only read from the PPU during V-blank or while rendering is OFF.

*This is true everywhere except for the palettes…PPU addresses $3F00-$3FFF. The first read will be true.

21. Credits and Thanks

I would like to thank everyone who helped me learn NES programming, especially the people at

I learned a lot from the example code for cc65 written by Shiru. I’ve used a few bits and pieces of code from his example files. Also the Famitone2 code and NES Screen Tool were written by Shiru. Check out his games on his website…

(scroll down to NES/Famicom) or check out the cc65 examples yourself…

(click on “these small example programs”).

And, two of his games are available (or soon will be) for sale from GreetingCarts (Retroscribe) here…

Or here, maybe…


Also, I want to thank THEFOX for his help when I was getting started using cc65. And also for the cc65 example code I found on his website (but isn’t there anymore ?).

Well, anyway, you can still play his game, Streemerz.

I also want to thank Rainwarrior for his Coltrane demo, which was written for cc65. You can find the example code on his website…

Also, be sure to check out his Lizard Game (soon to be finished, I believe).

Thanks to everyone.

Now, if I can only figure out how to program a SNES game…


20. Game Coding 3


Finally, I’ve finished rewriting all of this.

Let’s run down what happens each frame…

I moved the ‘set scroll, wait for sprite-zero hit, change scroll’ to the NMI code. Then we…

1. Get Input

2. Push all sprites (in buffer) offscreen, then put Sprite Zero back in

3. If Master_Delay goes from 1 to 0 on this frame, init new wave of enemies

  • I’m using memcpy to transfer enemy data from ROM to RAM

4. Check to see if we just finished the wave (All enemies have Y value of zero)

5. Check to see if we’re injured (lot’s of hitbox checks for every active enemy ship and bullet vs hero ship). Lives-1 if yes, and draw the ship as an explosion for a little bit (marked with an injury timer).

6. Move the ship (based on button presses)

7. Check to see if our bullets are hitting the enemy ships (give them Y = 0 if yes, and spawn an explosion).

8. Draw all the active sprite objects (by putting their data into the OAM buffer).

9. Play music (this could be done in the NMI code)

10. Update the scoreboard (in ASM…the NMI code will push it to the PPU).

11. Handle switching to Pause Mode (START pressed)

12. Handle dying (Lives rolled past zero to 0xff)


Then I wrote the pattern system. At the start of each wave, it sets starting positions and a delay for each ship. Each frame, it goes to a specific pattern code, and moves the ships based on either their position, a count, or a move list. It will stay in a wave until every ship has a Y value of zero…either because they moved offscreen or were shot. Once all the ships have a Y value zero, it sets a short delay (Master_Delay), then starts the next wave. Until we run out of waves, and start the Boss Mode…

Boss mode is pretty straightforward…the boss has a list of moves, and a health. Bullets hitting the boss decrease the health until zero, and we trigger the boss death (shaking and noise sound fx), and then jump into Victory Mode.

I added a final Continue screen, in case someone wants to keep going. It just resets the game as usual, but it saves the ‘lives’ and ‘scores’ when it erases the RAM.

Hopefully, someone out there can learn something from this example code. Feel free to build on this code and make a bigger / better version of it. Thanks for reading.




19. Game Coding 2



Now, I’ve rewritten all this…

Bullets are also defined by structs.

struct BULLET {
unsigned char Y; // y = 0 = off
unsigned char Y_sub;
unsigned char tile;
unsigned char attrib;
unsigned char X;
unsigned char X_sub;
unsigned char Y_speed; // high nibble = speed, low = sub
unsigned char X_speed;

And, most importantly, I’ve redesigned how sprites are drawn on the screen. It’s done dynamically each frame. First, I move all sprites (in the OAM buffer, RAM addresses $200-$2ff) offscreen (Y coordinate > $f0). Then I draw the Sprite Zero, then each active sprite object is put into the buffer. I’m varying the order that they are added to the buffer each frame, so that they flicker.

And, now I’m using NES screen tool to generate metasprite data. I wasn’t 100% happy with the code provided in Shiru’s example code…so I rewrote it all. Specifically, if the metasprite starts to go offscreen, it won’t be half on the right and half on the left. The rightmost sprites will be pushed offscreen (to the bottom). It’s far less efficient code, but it looks nicer. Also, I wrote it so that any metasprite can be flipped horizontally (and possibly vertically). Then, to convert the ‘save metasprite bank’ output to a format that will work well with my system…I wrote a python script to reformat it. It only works with 1 metasprite at a time, and you still have to manually type the reversed x coordinates. That’s because metasprites don’t have a standard width.

Anyway, it’s now easier to make and edit metasprites.

In the example code, down = spawn some bullets. Select = spawn some ships. You can see that I’m testing Horizontal flipping on one of the 3/4 enemies.

I also added a much more efficient hitbox code, in ASM, now that we are increasing the number of sprite object collision tests.




18. Game Coding

First thing is to get a skeleton of the game working. Title screen loads. Press ‘start’ moves to Game Mode. Press ‘start’ sets Pause Mode. ‘Start’ again goes back to Game Mode.

I opened Photoshop, and made a quick sketch of Title Sceen and Game Mode. Then I designed the Title by playing with fonts…Arial Black seems ok. I gave it some ‘perspective’, added a few filters, and resized it to 128 pixels wide. Converted to 4 color (color/mode/index/custom). Cut and paste it into YY-CHR.


The ship, I just sketched in YY-CHR. And some BG stars. Then I opened up NES Screen Tool, and randomly placed some stars, and saved nametable as RLE compressed C header. Similarly with the Title Screen, I arranged the text and Title, and saved that nametable as RLE in C.


Then I added some code to load the screens and switch between them with Start button presses. I also added ‘Game Over Mode’ and ‘Victory Mode’. And, I’m testing them by tying them to the Select button (to be removed later). I’m also testing some Sound Fx that I made, tying them to some other button presses (Up/Down/B/A)…again, to be removed later. I just want to make sure they work.

For some reason I made all of my sound fx with the noise channel. Maybe this is a bad idea. Oh well.

At this point I got ahead of myself, and added the music. Usually, I wait till the very end to add music. I highly recommend waiting till the end, especially if it’s a very long project, because you will get REALLY sick of hearing the same 1 minute song loop OVER and OVER and OVER.

I just happened to be in a music writing mood, and so I added it right away. Again, I used Famitracker and Famitone2. (See earlier post).

At this point, I added a HUD (the scoreboard), which is updated every frame with a new score. The scoreboard is actually written on the opposite nametable at startup. We will be using a sprite zero hit to switch nametables midframe.

Then, I put the ship in, and gave it some basic Left/Right movement physics. It moves a little slippery (you keep moving even if buttons aren’t pressed), which I thought is appropriate for space. This can be changed later, if gameplay is odd.

Finally, I added the sprite zero hit and vertical scrolling. Switching nametables midframe is no trouble…just write it to $2000. If we were also changing H scroll, we would just need to write to $2005. But, I was doing the more complicated V scroll change. This is the rain dance you have to do to switch V scroll midframe…

Vert_scroll2 = ((Vert_scroll & 0xF8) << 2);
Sprite_Zero(); //wait for sprite zero hit
SCROLL = Vert_scroll;
PPU_ADDRESS = Vert_scroll2;

I ran into some problems here, and had to do more debugging. It would work fine for a few seconds, then glitch, then it would screw up the sprite zero hit. I had to investigate. In FCEUX, debugger, I set breakpoints to writes to $2000, 2005, 2006, just to make sure.

They were writing the correct numbers. But, then I noticed that the first write to set the top of the screen (which should have happened during V-blank) was happening at Scanline 40! Oh, the music that I added was doing its update in the NMI routine…before anything else was happening. And, it was taking long enough (occasionally) to not get to all the other stuff that needs to happen during V-blank, until well into rendering the screen. (This was code from another game that I cut/pasted in…poorly). And, it was missing the Sprite Zero hit. It didn’t actually crash the game, it was just setting it up WAY TOO late.

I moved the music update to go last on my list of things to do each frame, and it was working perfectly now.

After all that, I’m going to take a break.

Here’s how the different modes work…

void main (void){
  while (1) { // infinite loop
    while (GameMode == TITLE_MODE){ 
    // Title Mode code
    while (GameMode == RUN_GAME_MODE){ 
    // Game Mode code
    while (GameMode == PAUSE_MODE){ 
    // Pause Mode code
    while (GameMode == GAME_OVER_MODE){ 
    // Game Over code
    while (GameMode == VICTORY_MODE){ 
    // Victory Mode code

See you next time. Here’s the code I have so far.


Update: I’ve rewritten much of this. Now all sprite objects are going to be defined by structs…

struct ENEMY {
unsigned char anime; // for drawing object to screen
unsigned char dir; // direction, for flipping 0 = L
unsigned char Y; // top side
unsigned char X; // left side
unsigned char delay; // wait to start moves
unsigned char type; // type of object
unsigned char move; // which move to do
unsigned char count; // how far along on the move are we

(I changed type a little later to bullet_type, to define what bullet pattern to use, only in spacy4.c code)

And, I’m going to have a series of ‘waves’, where the ship movement pattern and type will be set at the start of the wave.

17. Planning a Game

We’re going to make a simple space shooter game.

Vertically scroll, shoot lasers, avoid the enemy ships.

First, we are going to set up several game “states”

  1. Title Screen
  2. Game Mode
  3. Pause Mode
  4. Game Over
  5. Boss Fight Mode
  6. Victory Mode

Here is our outline of the game code…

  1. Initialize
  2. Draw Title Screen
  3. Start Title Loop
    1. Get Input (wait for Start)
    2. Play Music
  4. Draw Game Screen
  5. Start Game Loop
    1. Get Input
    2. Move your ship
    3. Spawn Ships
    4. Move enemy ships and bullets
    5. Collisions
    6. Play Music
  6. If Run out of Lives, Draw Game Over Screen
  7. -Play Game Over Music
  8. -Loop Back to Title
  9. If reach end, Start Boss Fight Mode
  10. If win, Start Victory Mode, Draw Victory Screen
  11. -and play Victory Music

First, create some graphics for the game.

Then, write some music.

I’m going to get the title screen working, with music, then I’ll get the Game Mode working.

I decided to use a Sprite Zero Hit to split screen the Scoreboard and the action, which will be vertically scrolling. Here’s a quick sketch I did in Photoshop…


I also decided to use Sprites for some of the text, like ‘Pause’ and ‘Game Over’. I thought that would be easiest.

Let’s get started, I’ll show you some code next time…I’m still trying to stick to the ‘make a game entirely in C’ concept, and this is just example code, so it won’t be too fancy.