Previous week: number systems and core programming ideas

This week: general overview of the NES architecture with the major components covered. All general purpose computers are arranged the same way with a place to store code (ROM), a place to store variables (RAM), and a processor to run code (CPU). The NES also adds another processor to generate the graphics (PPU) and a section of the CPU to generate audio (APU). Everything here is very general and will have more details than you want in the next few weeks.

NES System Architecture

KB - Memory size is listed in KiloBytes or KB. 1KB = 1024 bytes. Everything is powers of 2, so 2^10 = 1024 is used instead of 1000. If the capitalization is different, the meaning can change. Kb is Kilobits. Divide Kb by 8 to get KB, because 1 byte = 8 bits.

ROM - Read Only Memory, holds data that cannot be changed. This is where the game code or graphics is stored on the cart.

RAM - Random Access Memory, holds data that can be read and written. When power is removed, the chip is erased. A battery can be used to keep power and data valid.

PRG - Program memory, the code for the game

CHR - Character memory, the data for graphics

CPU - Central Processing Unit, the main processor chip

PPU - Picture Processing Unit, the graphics chip

APU - Audio Processing Unit, the sound chip inside the CPU



System Overview

The NES includes a custom 6502 based CPU with the APU and controller handling inside one chip, and a PPU that displays graphics in another chip. Your code instructions run on the CPU and sends out commands to the APU and PPU. The NOAC (NES On A Chip) clones like the Yobo and NEX put all of these parts onto one chip.




There is only 2KB of RAM connected to the CPU for storing variables, and 2KB of RAM connected to the PPU for holding two TV screens of background graphics. Some carts add extra CPU RAM, called Work RAM or WRAM. If a cart needs to store saved games, this WRAM will have a battery attached to make sure it isn't erased. A few carts add extra PPU RAM to hold four screens of background graphics at once. This is not common. The rest of this tutorial will not use WRAM or four screen RAM.

Each cart includes at least three chips. One holds the program code (PRG), another holds the character graphics (CHR), and the last is the lockout. The graphics chip can be RAM instead of ROM, which means the game code would copy graphics from the PRG ROM chip to the CHR RAM. PRG is always a ROM chip.


Lockout Chip
Inside the NES and the cart are also two lockout chips. The lockout chip controls resetting the console. First the NES lockout sends out a stream ID, 0-15. The cart lockout records this number. Then both lockout chips run a complex equation using that number and send the results to each other. Both chips know what the other is supposed to send so they both know when something is wrong. If that happens the system enters the continuous reseting loop. This is the screen flashing you see with a dirty cart.

When you cut pin 4 of the NES lockout chip, you are making it think it is inside the cart. It sits there waiting for the ID from the NES which never happens, so the system is never reset. If you were to completely remove the NES lockout chip the system would not work because it controls the reset button.

Most lockout defeaters used by the unlicensed game companies used large voltage spikes sent from the cart to the NES lockout. When timed right those would crash the NES lockout, preventing it from resetting the system. Nintendo slowly added protection against those on the NES board. Next time you open your NES, check the board for the revision number. Right in the middle it will say NES-CPU- then a number. That number is the revision. If you have 05 it is an early one. 07 and 09 added some lockout protection. 11 was the last version with the most lockout protection. Almost all unlicensed carts that use lockout defeaters will not work on a NES-CPU-11 system.


CPU Overview
The NES CPU is a modified 6502, an 8 bit data processor similar to the Apple 2, Atari 2600, C64, and many other systems. By the time the Famicom was created it was underpowered for a computer but great for a game system.

The CPU has a 16 bit address bus which can access up to 64KB of memory. 2^16 = 65536, or 64KB. Included in that memory space is the 2KB of CPU RAM, ports to access PPU/APU/controllers, WRAM (if on the cart), and 32KB for PRG ROM. The 16 bit addresses are written in hex, so they become 4 digits starting with a $ symbol. For example the internal RAM is at $0000-0800. $0800 = 2048 or 2KB. 32KB quickly became too small for games, which is why memory mappers were used. Those mappers can swap in different banks of PRG code or CHR graphics. Mappers like the MMC3 allowed up to 512KB of PRG, and 256KB of CHR. There is no limit to the memory size if you create a new mapper chip, but 128KB PRG and 64KB CHR was the most common size.




PPU Overview
The NES PPU is a custom chip that does all the graphics display. It includes internal RAM for sprites and the color palette. There is RAM on the NES board that holds the background, and all actual graphics are fetched from the cart CHR memory.

Your program does not run on the PPU, the PPU always goes through the same display order. You only set some options like colors and scrolling. The PPU processes one TV scanline at a time. First the sprites are fetched from the cart CHR memory. If there are more than 8 sprites on the scanline the rest are ignored. This is why some games like Super Dodge Ball will blink when there is lots happening on screen. After the sprites the background is fetched from CHR memory. When all the scanlines are done there is a period when no graphics are sent out. This is called VBlank and is the only time graphics updates can be done. PAL has a longer VBlank time (when the TV cathode ray gun is going back to the top of the screen) which allows more time for graphics updates. Some PAL games and demos do not run on NTSC systems because of this difference in VBlank time. Both the NTSC and PAL systems have a resolution of 256x240 pixels, but the top and bottom 8 rows are typically cut off by the NTSC TV resulting in 256x224. TV variations will cut off an additional 0-8 rows, so you should allow for a border before drawing important information.

NTSC runs at 60Hz and PAL runs at 50Hz. Running an NTSC game on a PAL system will be slower because of this timing difference. Sounds will also be slower.






Graphics System Overview

Tiles
All graphics are made up of 8x8 pixel tiles. Large characters like Mario are made from multiple 8x8 tiles. All the backgrounds are also made from these tiles. The tile system means less memory is needed (was expensive at the time) but also means that things like bitmap pictures and 3d graphics aren't really possible. To see all the tiles in a game, download Tile Molester and open up your .NES file. Scroll down until you see graphics that don't look like static. You can see that small tiles are arranged by the game to make large images.
Sprites
The PPU has enough memory for 64 sprites, or things that move around on screen like Mario. Only 8 sprites per scanline are allowed, any more than that will be ignored. This is where the flickering comes from in some games when there are too many objects on screen.
Background
This is the landscape graphics, which scrolls all at once. The sprites can either be displayed in front or behind the background. The screen is big enough for 32x30 background tiles, and there is enough internal RAM to hold 2 screens. When games scroll the background graphics are updated off screen before they are scrolled on screen.
Pattern Tables
These are where the actual tile data is stored. It is either ROM or RAM on the cart. Each pattern table holds 256 tiles. One table is used for backgrounds, and the other for sprites. All graphics currently on screen must be in these tables.
Attribute Tables
These tables set the color information in 2x2 tile sections. This means that a 16x16 pixel area can only have 4 different colors selected from the palette.
Palettes
These two areas hold the color information, one for the background and one for sprites. Each palette has 16 colors.

To display a tile on screen, the pixel color index is taken from the Pattern Table and the Attribute Table. That index is then looked up in the Palette to get the actual color.




To see all the graphics, download the FCEUXD SP emulator. Open up your .NES game and choose PPU Viewer from the Tools menu. This will show you all the active background tiles, all the active sprite tiles, and the color palettes. Then choose Name Table Viewer from the Tools menu. This will show you the backgrounds as they will appear on screen. If you choose a game that scrolls like SMB you can see the off screen background sections being updated.


NEXT WEEK: CPU details, start of 6502 assembly programming

How do dual-backgrounds work? I guess I get a choice for which one to display first. So for DDR, I can

1. display Bkgd-1, the "movie" background with "visualizations" and the 4 static arrows at the top of the screen. These would be illuminated with palette swaps. I don't think they could be scrolled unless there's a way to always write the static arrows to the same portion of the screen? Perhaps only doing a lateral scroll for the area below them on-screen (after pixel 24-down) if that's possible?

...then 2. display Bkgd-2, the stepchart, which scrolls from bottom to top.

...and 3. display sprites, such as combo counter text, "Perfect" or "Great" feedback, etc.

and that will effectively do what I want to do? This allows for big 4x4 tile arrows, an unlimited number of steps onscreen (well, as opposed to using sprites) and I can still get the arrows to flash wth the beat by palette-swapping them during vblank when I scroll.

There is only one layer of background, the 2 screens worth are arranged next to each other either vertically or horizontally. They cannot be placed on top of each other. What you can do is switch between those 2 screens part way down the screen. The SMB screen is a good example of this. The status bar is fixed at the top, not scrolling. Then when the last scanline is drawn the game switches to the game background, which does scroll. Yes this may be more confusing



For DDR you will have to limit the arrow sizes to avoid the 8 sprites per scanline limit. You need 4 static arrows, so if you used sprites they could only be 2x2 tiles maximum. You will also need the stepchart, which could have more than 2 arrows horizontally (start of two arrows overlapping end of two others). So if those used sprites it couldn't be more than 2x2 tiles. You only get 64 sprites so if the stepchart was sprites there could only be 16 steps on screen. You want the static arrows to be on top of the stepchart so they can't both use the background.

I would do the non scrolling status bar like SMB, either at the top or bottom depending on which way the stepchart scrolls. Then you have the stepchart as a scrolling background. Since it is background you can do those arrows as big as you want. The screen is only ~28 tiles tall, so you probably don't want arrows bigger than 2x2 or not enough will be on screen. When the step is hit correctly, you erase the arrow from the background. Then you have the static arrows as sprites. They can either be in front or behind the stepchart arrows. And finally more sprites for the ok/good/great messages, because those also do not scroll and will be in front of the stepchart.

If you wanted 2 player then you could do stepchart as 2x2 arrows, then use 1x1 for the static arrows so there can be 8 across. The static ones would be centered horiz on the stepchart ones.

DDR Screenshot

Take note of the green/blue arrows, the usable screen space is about 6 arrows including static ones. At 32 pixels you can fit 7 onscreen, the same dimensions as real DDR. I fear 16 pixel arrows might be too small.

How about getting tricky with alternating sprite displays? Displaying every other tile for the four arrows each refresh.



They'll flicker but it will be uniform and it might produce an interesting effect if they're put over the background, a transparent effect. How many refreshes does the NES display per second? This (really rough) demo gif looks to be about 6-8fps on my browser. Is there enough time to update all 32 of these tiles plus other sprites during vblank?

The other option if this looks like crap is to only draw parts of the arrows. This configuration only has 6 sprites per line and still gives you the visual cue you need.



Although 2player mode is possible with a four-score I don't think I'll be programming that into this first foray, I've got better ideas for the other half of the screen And really, thinking of the target market, I think two player capability is superfluous for this release. Who's going to invite their buddy over for a rousing game of 2-play 8-bit DDR? They can take turns, damnit! The most likely user is going to just be holding two control pads, sitting on their ass and playing using thumbs-on-d-pads to listen to the tunes

NES is 60 fps on NTSC, 50 fps on PAL. Any flickering will just look annoying. When games have lots of stuff on screen they will reorder sprites so the same one isn't always hidden but you should be able to avoid that.




Wait for week 4! On NTSC you have enough vblank time to update all 64 sprites, and about 3 rows or columns of background. Your game should only have to update a maximum of 1 row for stuff scrolling in, then maybe another row worth for status bar and erasing step chart arrows that were hit. Some games like Battletoads will turn the screen on late or turn it off early to get more vblank time.

If you are sticking to 1 player, you can rotate everything 90 degrees and have the step chart scrolling from right to left. That way on a scanline there are only 4 sprites for one large static arrows. It will also give you more look ahead from the longer screen and not having the status bar in the way. Only thing to make sure is that the ok/good/great either use 4 or fewer sprites, or just go on a line that doesnt have static arrows.

So wait...SMB can hold only of 512x240 pixels of background data at a time? So as I'm scrolling through the level, they continually update as I'm running along?

How does the background data update? Does each individual pixel update, or does it update in increments of X amount of pixels at a time?

Also, I assume the audio data is stored in PRG correct? Only graphics (background and sprite) are stored in CHR, right?

Exactly, the background data that is off screen gets updated so you don't see it changing on screen.

Background updates are done by tiles, so an 8x8 pixel tile is changed. When a game is scrolling horizontally there will be one vertical column of tiles to update for every 8 pixels scrolled. SMB looks like it is keeping 16 columns ahead off screen correct, or 8 columns of its brick sized blocks. Using the FCEUXD SP debugger you can see it in action. First download the SMB/DH game and load it up in FCEUXD. Before choosing SMB, open the Name Table Viewer in tools menu, and the Debug in the tools menu. In the 6502 Debugger window press the Add... button below breakpoints. Type 8082 into the first Address field and click the Execute checkbox. Hit OK. This tells the emulator to stop when the code reaches memory address $8082, which happens once per frame in SMB. You can now select SMB. The screen will stop at all black. Now continually click the Run button in the debugger to see the screen being updated. You will have to click 60 times for one second of game play. Once the demo starts running you will be able to watch new background being added as mario scrolls. I would bet the 8 block look ahead is why a turtle can go off screen and come back if there is something out of view to bounce off.

Yes audio data is in the PRG. Sounds are all generated by software, anything prerecorded is low quality (Get The Spellbook!). CHR is only used for graphics, except in some really crazy cases like Racermate when it is used for save files.

Cool dude. Do you have to program the background data to update, or will it do that automatically? I imagine that you need to program the game to scroll, and it will work automatically after that. I remember reading some nesdev forums a while back and scrolling seems to be a difficult thing to program.

I think I had another question but I can't think of it right now. So far it all makes sense to me. I'll probably get lost at about week 4 or 5

You have to program EVERYTHING Pretty much nothing happens automatically. Scrolling isn't too difficult, it just takes extra work to calculate which column to update. But for this tutorial there will be no scrolling just to take out one more point of possible confusion. I always say the first game you write should be single screen.

i'm trying to find the programs to download to get started

any links?

I think week 3 has the downloads in it

cool, thnx

can't get, how the graphics are made
in the pattern table, the 8*8 tile is stored, and it contains 64 bits (every bit contains information bout the color) ??

and then in the attribute table, are there more information about the color and this is added to the pattern table?

so e.g. in pattern table first pixel has "5" and by the attribute table "2" is added, so the final pixel is in "7" (white) and in the position that is set in the pattern table???

sry for complicated question, hope someone can help me or at least understand what i want to know ^^

^^^ There are 2 bits per pixel. Otherwise everything would be monochrome, since a single bit can only contain a 1 or a 0.

In the 8x8 tiles, the pixles are specified with colors 1-4 of the pallette you specify.

There are 4 background palletts (of 4 colors each) that can be active at one time.

So, the tile can be displayed with any of the 4 active palletts.

It is not additive or multiplicitive like you're suggesting.

Lesson 2 completed today! Cheers! 

Question about this line of text near the beginning:

"Divide Kb by 8 to get KB, because 1 byte = 8 bits."

Should that be "Divide KB by 8 to get Kb"?

no, you take 8 kilobits (8kb) divide that by 8 and you get 1kiloByte (1KB)

---Edited for a mundane comparison to help clarify ---

Imagine that kilobits are like pennies and that KiloBytes are like dollars. now you have 100 pennies, if you divided that by 100 you get $1 but in computer memory schemes (most not all as there are others) it's in 8's instead of 10's or 100's

"no, you take 8 kilobits (8kb) divide that by 8 and you get 1kiloByte (1KB)"

That's definetly not right cause if you take 8 Kb and divide that by 8, you get 1 Kb.

1 KB (byte) is equal to 8 Kb (bits).  So 1 Byte is equal to 8 bits.  So you divide 1 Byte by 8 and you get 1 bit.  So if you divide 1 KB by 8, you get 1 Kb.

 

technically yes, but you're failing to get the basic point. The basic point it to quickly calculate kb to KB. 8kb = 1KB so if you had 32kb and wanted to know how many KB you have take 32 and divide it by 8, you get 4. that means 32kb is the same as 4KB. Rather than doing it the long way and going 8, 16, 24, 32 in 8 kb increments it's faster and easier to do the divide by method.

lol, well actually I believe I do indeed get the basic point that a Byte is bigger than a bit by a factor of 8 to which your initial response stated otherwise and had me going for a second wondering if I was getting dyslexic or something.  I'm sure the tutorial just has a minor typo then.

1. "Divide Kb by 8 to get KB, because 1 byte = 8 bits."

2. Should that be "Divide KB by 8 to get Kb"?

Nothing is wrong in line 1. Your reply to line 2 is wrong though. You would multiply KB by 8 to figure out the number of Kb in the chip. No typo at all.

if you said that then I believe it's safe to assume that you haven't taken any computer courses. BB's tuts have a basic belief that you have some understanding of the computer just not the ASM code structure so he only did a quick recap to refresh our brains. Let me give you a quick lesson in Binary (this may not actually be that quick FYI)

first I need to re-teach you how to count. Humans count in a system called Base 10, it consists of the numbers 0-9. why? it is believed that counting originated from the number of fingers on our hands and that's how many fingers most humans have. So we start at 0 (nothing) and add 1
0+1=1 then we continue this process
1+1=2
... until we reach 9 then we add 1 more and OH NO we don't have any more numbers!! what do we do? Well we shift, recycle, and repeat
09+1=10. This process goes on for infinity. Now lets talk computer numbers and counting. Computers instead count in a system known as Base 2, also called Binary. This means they only have 2 numbers, 0 and 1. This is because the computer uses electric pulses to count and the only way to do this is if wither the electric current is on or off (1 and 0 respectively) So the computer starts at 0 then adds 1 0+1=1 then if it wishes to count higher it adds 1 again 1+1=? OH NO we ran out of numbers in computer counting! so we shift, recycle and repeat just like how we count 01+1=10 (to the normal person going from 1 to 10 looks bizarre, but this is how the computer works, in reality that 10 if converted to our counting scheme is 2) So we keep doing this 10+1=11 (11 in binary = 3) Each individual 0 or 1 is known as a bit.

I hope so far you are understanding this
Now, way back in the beginning of electronic computing they needed a way to fixate these individual 1's and 0's and group them together and use them. So it was decided that they would take 8 of them and use those 8 to translate it into numbers, letters and special characters (now they use 32 because of the inclusion of foreign languages but that's another lesson) these 8 bits grouped together is called a byte (it's literally a joke, the word bit could be like I bit someone, so the byte is like I bite into something. but because bite could be accidentally mistyped as bit they changed the spelling to byte)

now lets do a binary map with a binary number underneath
128 64 32 16 8 4 2 1
..1..0..0..1.1.1.1.0 or 10011110
if you notice, on the right side the chart starts with 1, each instance after that is double the previous number, why? because it's base 2, our base 10 systems works in a similar way, but because it's base 10 the number is multiplied by 10. (see the correlation? base 2 multiplied by 2, base 10 multiplied by 10 1's 10's 100's etc...)

Now with this simple chart we can translate what the binary number, or Byte, equal in our own system by adding the correlating numbers above the 1's from the binary number to the chart. 128+16+8+4+2=158
now I want you to add up all those numbers on the chart, what does it equal? the maximum number is 255. This next thing is rather important, that is the highest countable value of a byte but in computing WE ALWAYS start with 0, so there are 256 possibilities, but the highest number is 255. (being able to do this math is useful for many things in computing but for now that's all you need to know about binary)

now we get into higher numbers, what is a kilo? kilo is the metric term meaning 1,000. but the metric system is in base 10 and computers are in base 2. this means we can't have what we consider an even 1,000 when we have a kilo of a computer measurement. because of this we take the base 2 and use the kilo to multiply it to the 10th power ( 2^10, or 2*2*2*2*2*2*2*2*2*2) and that gives us a number of 1024 bits. so 1kilobit = 1024 bits. now if we want to figure out how many Bytes there are in a kilobit we know that every 8 bits = 1 Byte, so 1024/8= 128. so there are 128B in 1kb. now lets get into even higher numbers. a kiloByte is like saying 1,000 bytes, but as noted earlier we can't use that number exactly. A kiloByte is 2^10 Bytes. or 1024 Bytes each byte is 8 bits so if we wanted to break that down into individual bits we multiply it by 8 so 1024*8=8192 bits in a kiloByte. (I know, this math is really weird to get the hang of)

now just like how you can take 8 bits and make a byte, the same thing is true for the kilo version, 8kilobits = 1kiloByte.
Now we get to the point I was trying to make, it takes 8 small units to make 1 big unit. the math just so happens to come out that if you take 8 and divide by 8 you get 1 so when you have all of those small units, if you divide by 8 it will show you how many of the big units you have. let's say you have 72kilobits let's divide that by 8, 72/8=9. so 72 kilobits is = to 9kiloBytes.

does the tutorial have a typo? No, it doesn't. It's just that people aren't wired to inertly understand binary conversions.
back to my penny description it takes 100 pennies to make a dollar, 100/100 equals 1 but instead of saying it equals 1 penny i'm saying that 100 pieces out of 100 pieces equals 1 whole or a dollar

I know this was a ramble and at least I hope it taught you something or at least peeked your curiosity to learn more about computers.

Ah i see what you were getting at there in your initial response jc. The wording just threw me off cause, yes, dividing 8 bits by 8 will yield a single bit but dividing the NUMBER of bits by 8 will yield the number of bytes. All is clear now, appreciate your help you two!

Fyi i dont think jc or the tutorial had poor wording. Just my weird interpretation.

this is a wonderful wealth of information. Still trying to figure out how the palette color indexes work. Hopefully it will be a topic covered in future tutorials because the little diagram didn't do it for me.