+---------------------------------------------+ | Nintendo Entertainment System Documentation | | | | Author: JDC (yoshi@parodius.com) | | Revision: 1.00 | +---------------------------------------------+ +------------------+ | Revision History | +------------------+ v1.00: [---] Changes from 0.53 to 1.00 should be blatantly obvious. Besides being practically re-written, all information has changed, and the MMC section is no longer supported. +-------------------+ | Table of Contents | +-------------------+ 1. Introduction A. Disclaimer B. Why? C. Mission D. Dedications E. "Thank You"s F. About the Author G. Contacting the Author 2. Terminology and Hardware A. Terminology B. Hardware C. Notes 3. CPU A. General Information B. Memory Map C. Interrupts D. Notes 4. PPU A. General Information B. PPU Map C. Name Tables D. Pattern Tables E. Attribute Tables F. Palettes G. Mirroring H. Palette Mirroring I. Background Scrolling J. Sprites and SPR-RAM K. Horizontal and Vertical Blanking L. Mid-HBlank VRAM Writes M. Notes 5. pAPU A. General Information B. Pulse Channels C. Triangle Channel D. Noise Channel E. DMC (PCM) Channel F. Notes 6. Joypads and other devices A. General Information B. The Zapper C. Four-player devices D. Paddles E. Power Pad F. R.O.B. (Robot Operated Buddy) G. Signatures H. Notes 7. Memory Mapping Hardware 8. Registers 9. File Formats A. iNES Format (.NES) B. Famicom Disk System (.DKA/.DKB/.500) C. dNESe Format D. fwNES Format E. Notes 10. Programming the NES A. General Information B. CPU Notes C. PPU Notes D. Notes 11. Emulation A. General Information B. CPU Notes C. PPU Notes D. APU Notes E. FAQ (Frequently Asked Questions) 12. Reference Material A. CPU Information B. PPU Information C. APU Information D. Memory Mapper Information E. Mailing Lists +-----------------+ | 1. Introduction | +-----------------+ A. Disclaimer ------------- I am in no way held responsible for the results of this information. This is public-domain information, and should not be used for commercial purposes. If you wish to use this document for commercial purposes, please contact me prior to development, so that I may discuss the outline of your project with you. I am not trying to hinder anyone financially: if you wish to do real Nintendo Entertainment System development, con- tacting either Nintendo of America or Nintendo Company, Ltd. would be wise. Their addresses are listed here: Nintendo of America Nintendo Company, Ltd. P.O. Box 957 60 Fukuine Redmond, WA 98073 Kamitakamatsu-cho, USA Higashiyama-ku, Koyoto 602, Japan All titles of cartridges and console systems are registered trademarks of their respective owners. (I just don't deem it necessary to list every single one by hand :-) ). B. Why? ------- At the time this document was created, there was only one piece of lit- erature covering the internals to the NES: Marat Fayzullin's documen- tation, otherwise known as "NES.DOC". While Fayzullin's documentation was lacking in many areas, it provided a strong base for the basics, and in itself truly stated how complex the little grey box was. I took the opportunity to expand on "NES.DOC," basing other people's findings, as well as my own, on experience; experience which has helped make this document what it has become today. The beginning stages of this document looked almost like a replica of Fayzullin's documentation, with both minor and severe changes. Marat Fayzullin himself later picked up a copy of my documentation, and later began referring people to it. Keep in mind, without Marat's "NES.DOC" document, I would have never had any incentive to write this one. C. Mission ---------- The goal of this document is simplistic: to provide accurate and (as oxymoronic as it sounds) up-to-date information regarding the Nintendo Entertainment System (and Famicom). D. Dedications -------------- I'd like to dedicate this document to Alex Krasivsky. Alex has been a great friend, and in my eyes, truly started the ball of emulation rolling. During the good times, and the bad times, Alex was there. Spasibo, Alex; umnyj Russki... E. "Thank You"s --------------- I'd like to take the time and thank all the people who helped make this document what it is today. I couldn't have done it without all of you. Acey - d0p@sofi.ah.dk Alex Krasivsky - bcat@lapkin.rosprint.ru Avatar Z - wwahlen@nfinity.com Bluefoot - danmcc@injersey.com CiXeL - Chris Hickman - typhoonz@parodius.com D - slf05@cc.usu.edu Dan Boris - dan.boris@coat.com Donald Moore - moore@futureone.com FanWen Yang - yangfanw@ms4.hinet.net Fredrik Olsson - flubba@hem2.passagen.se Icer Addis - bldlust@maelstrom.net Jon Merkel - jpm5974@omega.uta.edu Kevin Horton - khorton@iquest.net Loopy - loopy@inquo.net Marat Fayzullin - fms@cs.umd.edu Mark Knibbs - mark_k@iname.com Matt Conte - itsbroke@classicgaming.com Matthew Richey - mr6v@andrew.cmu.edu MiKael Iushin - acc@tulatelecom.ru Mike Perry - mj-perry@uiuc.edu Morgan Johansson - MOJ@nerikes.se Neill Corlett - corlett@elwha.nrrc.ncsu.edu Pat Mccomack - splat@primenet.com Patrik Alexandersson - sp5alpa2@skolan.lysekil.se Paul Robson - AutismUK@aol.com Ryan Auge - rauge@hay.net Stumble - stumble@alpha.pulsar.net Tony Young - KBAAA@aol.com Vince Indriolo - indriolo@nm.picker.com \FireBug\ - lavos999@aol.com F. About the Author ------------------- My name is Jeremy Chadwick, more commonly known as Y0SHi or JDC. My profession is in UNIX system/network/security administration. I have worked for a plethora of companies within the Bay Area of California USA, and am currently located in Corvallis Oregon USA, and am quite content with relocating to some other area within the west-coast of the United States ( :-) ). On top of the aforementioned, I'm also the founder of Parodius Net- working, more commonly referred to as "parodius.com". Our network has made a name for itself when it comes to providing console and emul- ation-oriented materials. We never intended for it to become so popular, but we are happy to be part of such a glorious and wonderful evolution. I personally have been "online" since mid-1990. Originally I began BBS- ing during my younger years, and got directed to the 'NET via a local friend of mine. I've stuck with it ever since. I've been programming computers since 1987, and consoles since July of 1994. I released my famous SNES Documentation (SNDOC230.ZIP) a few days after Christmas of 1994. You can see more of my workings on my home page. G. Contacting the Author ------------------------ Email: yoshi@parodius.com Parodius Networking yoshi@skipnet.com 33811 Twin Maple Lane ICQ: #6279222 Corvallis, OR 97333 IRC: Y0SHi or Y0SH (EFNet) USA Phone: +1 541-754-1094 +-----------------------------+ | 2. Terminology and Hardware | +-----------------------------+ A. Terminology -------------- CPU - Central Processing Unit: Self-explanitory. The NES uses a standard 6502 (NMOS). PPU - Picture Processing Unit: Used to control graphics, sprites, and other video-oriented features. pAPU - Pseuedo-Audio Processing Unit: Used for sound. The NES contains five (5) audio channels: four (4) analogue, and one (1) digital. There is no physical APU IC in the NES, as the system is analogue, not digital. All analogue circuitry is kept within the CPU. MMC - Multi-Memory Controller: Micro-controllers used in NES games to access memory beyond the 6502 64Kbyte boundary. They can also be used to access extra CHR-ROM, and may be used for "special effects" such as forcing and IRQ, and other things. VRAM - Video RAM: The RAM which is internal to the PPU. There is 16kbits of VRAM installed in the NES. SPR-RAM - Sprite RAM: 256 bytes of RAM which is used for sprites. It is not part of VRAM nor ROM, though it's local to the PPU. PRG-ROM - Program ROM: The actual program-code area of memory. Also can be used to describe areas of code which are external to the actual code area and are swapped in via an MMC. PRG-RAM - Program RAM: Synonymous with PRG-ROM, except that it's RAM. CHR-ROM - Character ROM: The VRAM data which is kept external to the PPU, swapped in and out via an MMC, or "loaded" into VRAM during the power-on sequence. VROM - Synonymous with CHR-ROM. SRAM - Save RAM: RAM which is commonly used in RPGs such as "Cry- stalis," the Final Fantasy series, and "The Legend of Zelda." WRAM - Synonymous with SRAM. DMC - Delta Modulation Channel: The channel of the APU which handles digital data. Commonly referred to as the PCM (Pulse Code Modulation) channel. EX-RAM - Expansion RAM: This is the memory used within Nintendo's MMC5, allowing games to extend the capabilities of VRAM. B. Hardware ----------- NES - Nintendo Entertainment System: Self-explanitory. Dendy - Synonymous with the Famicom. Famicom - Synonymous with the NES, except it does not contain the fifth audio channel (DMC) nor any of it's registers. FDS - Famicom Disk System: Unit which sits atop the Famicom, support- ing the use of 3" double-sided floppy disks for games. C. Notes -------- None. +--------+ | 3. CPU | +--------+ A. General Information ---------------------- The NES uses a standard NMOS 6502 CPU, with modifications applied for audio. The NTSC NES runs at 1.7897725MHz, while the PAL version is at 1.773447MHz. B. Memory Map ------------- +---------+-------+-------+-----------------------+ | Address | Size | Flags | Description | +---------+-------+-------+-----------------------+ | $0000 | $800 | | RAM | | $0800 | $800 | M | RAM | | $1000 | $800 | M | RAM | | $1800 | $800 | M | RAM | | $2000 | 8 | | Registers | | $2008 | $1FF8 | R | Registers | | $4000 | $17 | | Registers | | $4017 | $FE9 | U | | | $5000 | $1000 | | Expansion Modules | | $6000 | $2000 | | SRAM | | $8000 | $4000 | | PRG-ROM | | $C000 | $4000 | | PRG-ROM | +---------+-------+-------+-----------------------+ Flag Legend: M = Mirror of $0000 R = Mirror of $2000-$2008 every 8 bytes (e.g. $2008=$2000, $2018=$2000, etc.) U = Unknown C. Interrupts ------------- The 6502 has three (3) interrupts: IRQ/BRK, NMI, and RESET. Each interrupt has a vector. A vector is a 16-bit address which spec- ifies a location to "jump to" when the interrupt is triggered. IRQ/BRK is triggered when the 6502 executes the BRK instruction, or when an IRQ is forced via other means. The BRK opcode is rarely used for triggering this IRQ; most carts use it for their own use. RESET is triggered on power-up. The ROM is loaded into memory, and the 6502 jumps to the address specified in the RESET vector. No registers are modified, and no memory is cleared; these only occur during power-up. NMI stands for Non-Maskable Interrupt, and is generated by each refresh (VBlank), which occurs at different intervals depending upon the system used (PAL/NTSC). NMI is updated 60 times/sec. on NTSC consoles, and 50 times/sec on PAL. Interrupt latency on the 6502 is seven (7) cycles; this means it takes seven (7) cycles to move in and out of an interrupt. Most interrupts should return using the RTI instruction. Some NES carts do not use this method, such as Squaresoft's "Final Fantasy 1." These carts return from interrupts in a very odd fashion: by manipulating the stack by hand, and then doing an RTS. This is technically valid, but morally shunned. The following interrupts have the following vector-points in ROM: $FFFA = NMI $FFFC = RESET $FFFE = IRQ/BRK Interrupt priorities are as follows: Highest = RESET NMI Lowest = IRQ/BRK D. Notes -------- Please note the two separate 16K PRG-ROM segments; they may be linear, but they play separate roles depending upon the size of the cartridge. Some games only hold one (1) 16K bank of PRG-ROM, which should be loaded into both $C000 and $8000. Most games load themselves into $8000, using 32K of PRG-ROM space. The first game to use this method is Super Mario Brothers. However, all games wit more than one (1) 16K bank of PRG-ROM load themselves into $8000 as well. These games use Memory Mappers to swap in and out PRG-ROM data, as well as CHR-ROM. +--------+ | 4. PPU | +--------+ A. General Information ---------------------- None. B. Memory Map ------------- +---------+-------+-------+--------------------+ | Address | Size | Flags | Description | +---------+-------+-------+--------------------+ | $0000 | $1000 | C | Pattern Table #0 | | $1000 | $1000 | C | Pattern Table #1 | | $2000 | $3C0 | | Name Table #0 | | $23C0 | $40 | | Attribute Table #0 | | $2400 | $3C0 | M | Name Table #1 | | $27C0 | $40 | | Attribute Table #1 | | $2800 | $3C0 | M | Name Table #2 | | $2BC0 | $40 | | Attribute Table #2 | | $2C00 | $3C0 | M | Name Table #3 | | $2FC0 | $40 | | Attribute Table #3 | | $3000 | $F00 | U | | | $3F00 | $10 | | Image Palette #1 | | $3F10 | $10 | | Sprite Palette #1 | | $3F20 | $E0 | P | Palette Mirror | +---------+-------+-------+--------------------+ Flag Legend: C = Possibly CHR-ROM M = Mirrored (see Subsection G) P = Mirrored (see Subsection H) U = Unused C. Name Tables -------------- The NES displays graphics using a matrix of "tiles"; this grid is called a Name Table. Tiles themselves are 8x8 pixels. The entire Name Table itself is 32x30 tiles (256x240 pixels). Keep in mind that the displayed resolution differs between NTSC and PAL units. NTSC units have an on- screen resolution of 256x224, while PAL units use 256x240. The Name Tables holds the tile number of the data kept in the Pattern Table (continue on). D. Pattern Tables ----------------- The Pattern Table contains the actual 8x8 tiles which the Name Table refers to. It also holds the lower two (2) bits of the 4-bit colour matrix needed to access all 16 colours of the NES palette. Example: VRAM Contents of Colour Addr Pattern Table Result ------ --------------- -------- $0000: %00010000 = $10 --+ ...1.... Periods are used to .. %00000000 = $00 | ..2.2... represent colour 0. .. %01000100 = $44 | .3...3.. Numbers represent .. %00000000 = $00 +-- Bit 0 2.....2. the actual palette .. %11111110 = $FE | 1111111. colour #. .. %00000000 = $00 | 2.....2. .. %10000010 = $82 | 3.....3. $0007: %00000000 = $00 --+ ........ $0008: %00000000 = $00 --+ .. %00101000 = $28 | .. %01000100 = $44 | .. %10000010 = $82 +-- Bit 1 .. %00000000 = $00 | .. %10000010 = $82 | .. %10000010 = $82 | $000F: %00000000 = $00 --+ The result of the above Pattern Table is the character 'A', as shown in the "Colour Result" section in the upper right. E. Attribute Tables ------------------- The Pattern Table contains the actual 8x8 tiles which the Name Table refers to. It also holds the lower two (2) of the 4-bit colour matrix Each byte in an Attribute Table represents a 4x4 group of tiles on the screen. There's multiple ways to describe what the function of one (1) byte in the Attribute Table does: * Holds the upper two (2) bits of a 32x32 pixel grid, per 16x16 pixels. * Holds the upper two (2) bits of sixteen (16) 8x8 tiles. * Holds the upper two (2) bits of four (4) 4x4 tile grids. It's quite confusing; two graphical diagrams may help: +------------+------------+ | Square 0 | Square 1 | #0-F represents an 8x8 tile | #0 #1 | #4 #5 | | #2 #3 | #6 #7 | Square [x] represents four (4) 8x8 tiles +------------+------------+ (i.e. a 16x16 pixel grid) | Square 2 | Square 3 | | #8 #9 | #C #D | | #A #B | #E #F | +------------+------------+ The actual format of the attribute byte is the following (and corris- ponds to the above example): Attribute Byte (Square #) ---------------- 33221100 ||||||+--- Upper two (2) colour bits for Square 0 (Tiles #0,1,2,3) ||||+----- Upper two (2) colour bits for Square 1 (Tiles #4,5,6,7) ||+------- Upper two (2) colour bits for Square 2 (Tiles #8,9,A,B) +--------- Upper two (2) colour bits for Square 3 (Tiles #C,D,E,F) F. Palettes ----------- The NES has two 16-colour "palettes": the Image Palette and the Sprite Palette. These palettes are more of a "lookup table" than an actual palette, since they do not hold physical RGB values. Only the lower six (6) bits of each palette entry are used. The lower four (4) bits define the hue (chrominance), and the upper two (2) bits define the luminance (brightness). Saturation is based off of both the hue and luminance values. There are only twelve (12) possible hue values (1-12); any hue value greater then twelve (12) will result in the entry being black. A hue value of zero (0) results in no hue, meaning only the luminance value is used (resulting in a shade of grey). There are 52 possible colours, which includes two (2) possible shades of grey, black, and white. Specific mirroring (continue on) occurs between the two palettes. Due to the mirroring, each palette can only support 13 unique colour entries, making 26 the maximum number of colours on-screen. G. Mirroring ------------ Mirroring (otherwise known as shadowing) is the process of keeping two "copies" of a Name Table in memory. Imagine yourself in front of a mirror: anything you do, the mirror does. One cannot change the mirror without changing the original. The NES only contains enough VRAM to handle two (2) physical Name Tables, though this can be exterminated using the Four-Screen VRAM method (continue reading). Mirroring affects two (2) Name Tables simultaneously; you cannot switch Name Tables independently. Mirroring can also be disabled. The three (3) methods of mirroring: single-screen, "horizontal," and "vertical." Each term is used to describe which Name Tables get mirrored to what. Single-screen provides no mirroring, and only uses one (1) Name Table. Horizontal mirroring points Name Table #1 to #0, and #3 to #2. Vertical mirroring points Name Table #2 to #0, and #3 to #1. See below: Original Mirrored N. Table N. Table +------------+----------+----------+ | Horizontal | #0 | #1 | | | #2 | #3 | +------------+----------+----------+ | Vertical | #0 | #2 | | | #1 | #3 | +------------+----------+----------+ Four-Screen VRAM is where the NES's VRAM is somehow extended, resulting in four (4) physical Name Tables. H. Palette Mirroring -------------------- Mirroring also occurs within the Image Palette and the Sprite Palette, as well as between the two. Any data which is written to $3F00 is mirrored to $3F04, $3F08, $3F0C, $3F10, $3F14, $3F18, and $3F1C. Any data written to $3F04 is mirrored to $3F00, $3F08, $3F0C, etc.. Colour #0 in both the Image and Sprite Palettes defines transparency. The entire Image and Sprite Palettes are both mirrored to other areas of VRAM as well; $3F20-3FFF are mirrors of both palettes, respectively. I. Background Scrolling ----------------------- The NES can scroll the background (pre-rendered Name Table + Pattern Table + Attribute Table) independently of the sprites which are over- layed on top of it. The background can be scrolled horizontally and vertically. Scrolling works as follows: Horizontal Scrolling Vertical Scrolling 0 512 +-----+-----+ +-----+ 0 | | | | | | A | B | | A | | | | | | +-----+-----+ +-----+ | | | B | | | +-----+ 480 Name Table "A" is specified via Bits #0-1 in register $2000, and "B" is the Name Table after (due to mirroring, this is dynamic). This doesn't work for game which use Horizontal & Vertical scrolling simultaneously. The background will span across multiple Name Tables, as shown here: +---------------+---------------+ | Name Table #2 | Name Table #3 | | ($2800) | ($2C00) | +---------------+---------------+ | Name Table #0 | Name Table #1 | | ($2000) | ($2400) | +---------------+---------------+ Due to the resolution of the screen (256x240), the only valid vertical scroll values which can be written to the Background Scroll Register ($2005) are ones between 0 and 239. If a value is >239, it's ignored. However, immediately after a VBlank occurs, the next write to $2005 will control the horizontal scrolling values. See details on register $2005 for more information. To quote Pat Mccomack: "This stuff is used in smb1 (horizontal scrolling) but it's probably the same way with other games. Scrolling seems to be scanline based, ie during refresh the game can write different values to the scroll register (usually they do this when they detect the sprite 0 hit via reg $2002). The scrolling screen layout also can change. With horiz- ontal scrolling, the name table at the first screen (0-255) is the one specified in reg $2000, and the name table for the second screen (256-512) is the opposite of the first one, based on mirroring I guess." J. Sprites and SPR-RAM ---------------------- The NES supports 64 sprites, which can be either 8x8 or 8x16 pixels in size. The sprite data is kept within the Pattern Table region of VRAM. Sprite attributes such as flipping and priority, are stored in SPR-RAM, which is a separate 256 byte area of memory, independent of ROM and VRAM. The format of SPR-RAM is as follows: +-----------+-----------+-----+------------+ | Sprite #0 | Sprite #1 | ... | Sprite #63 | +-+-------+-+-----------+-----+------------+ | | +------++---------+--------------------------------------+ + Byte | Bits | Description | +------+----------+--------------------------------------+ | 0 | YYYYYYYY | Y Coordinate - 1. Consider the coor- | | | | dinate the upper-left corner of the | | | | sprite itself. | | 1 | IIIIIIII | Tile Index # | | 2 | vhp000cc | Attributes | | | | v = Vertical Flip (1=Flip) | | | | h = Horizontal Flip (1=Flip) | | | | p = Background Priority | | | | 0 = In front | | | | 1 = Behind | | | | c = Upper two (2) bits of colour | | 3 | XXXXXXXX | X Coordinate (upper-left corner) | +------+----------+--------------------------------------+ The Tile Index # is obtained the same way as Name Table data. Sprites which are 8x16 in size function a little bit differently. A 8x16 sprite which is even-numbered uses the Pattern Table at $0000 in VRAM. If the Sprite Tile # is odd, the sprite uses $1000 in VRAM. *PLEASE NOTE*: Register $2000 has no effect on 8x16 sprites. If a sprite has the the Sprite Priority bit set and has a higher priority than a sprite at the same location, then the background will be in front of both sprites. Konami's "Castlevania" cart uses this feature. Only eight (8) sprites can be displayed per scan-line. Each entry in SPR-RAM is checked to see if it's in a horizontal range with the other sprites. Remember, this is done on a per scan-line basis, not on a per sprite basis (e.g. done 256 times, not 256/8 or 256/16 times). K. Horizontal and Vertical Blanking ----------------------------------- The NES, like every console, has a refresh: where the display device relocates the electron gun to display visible data. The most common display device is a television set. The refresh occurs 60 times a second on an NTSC device, and 50 on a PAL device. The gun itself draws pixels left to right: this process results in one (1) horizontal scanline being drawn. After the gun is done drawing the entire scanline, the gun must return to the left side of the display device, becoming ready to draw the next scanline. The process of the gun returning to the left side of the display is the Horizontal Blank period (HBlank). When the gun has completed drawing all of the scanlines, it must return to the top of the display device; the time it takes for the gun to re-position itself atop the device is called the Vertical Blank period (VBlank). As you can see from the below diagram, the gun more or less works in a zig-zag pattern until VBlank is reached, then the process repeats: +-----------+ +--->|***********| <-- Scanline 0 | | ___---~~~ | <-- HBlank V |***********| <-- Scanline 1 B | ___---~~~ | <-- HBlank l | ... | ... a | ... | ... n |***********| <-- Scanline 239 k +-----+-----+ | | +--VBlank--+ An NTSC NES has the following refresh and screen layout: +--------+ 0 ----+ | | | | | | | Screen | +-- (0-239) 256x240 on-screen results | | | | | | +--------+ 240 --+ | ?? | +-- (240-242) Unknown usage +--------+ 243 --+ | | | | VBlank | +-- (243-262) VBlank | | | +--------+ 262 --+ The Vertical Blank (VBlank) flag is contained in Bit #7 of $2002. It indicates whether PPU is in VBlank or not. A program can reset Bit #7 by reading $2002. The Hit Flag is contained in Bit #6 of $2002. This bit is set to 1 when the PPU starts refreshing the first scanline where sprite #0 is located. For example, if sprite #0's Y coordinate is 34, the Hit flag will be set in scanline 34. The Hit Flag is set to 0 when a VBlank occurs. L. Mid-HBlank VRAM Writes ------------------------- VRAM writes can be executed during mid-HBlank. The PPU will continue to update the screen at the current scanline; the data written will be applied to a different scanline, and also affects the horizontal scroll value. The format of the data written during mid-HBlank is: BYTE 1: 00AA??vv BYTE 2: vvvHHHHH Horizontal Position = H*8 Vertical Position = 0 Scanline = (v*8)+AA M. Notes -------- VRAM is addressed via a 14-bit address, and will wrap on it's 16K boundary (e.g. accesses to $4001 will read from $0001). The PPU will auto-increment the VRAM address by 1 or 32 (based on Bit #2 of $2000) after accessing $2007. Information provided in the latter section of Subsection K may be incorrect. +---------+ | 5. pAPU | +---------+ A. General Information ---------------------- The NES uses a four (4) channel analogue synthesis chip to do it's audio, and also has a fifth (5) channel for digital sound. Unlike the SNES and it's SPC700, there is no IC APU on the NES: hence the name 'pAPU' (pseudo-APU). Analogue synthesis is achieved via oscillators, resistors, transistors, and capacitors. Voltage is sent through these, and certain aspects of each sound channel are controlled using registers. The first two (2) channels are pulse (square), and the third (3) being a triangle. The fourth (4) channel is a noise channel. The fifth (5) channel is the DMC (PCM) channel. B. Pulse Channels ----------------- No information is currently available. C. Triangle Channel ------------------- The triangle channel's duty cycle is always 50/50. D. Noise Channel ---------------- No information is currently available. E. DMC (PCM) Channel -------------------- The DMC channel, commonly referred to as the 'PCM' channel, uses two methods of digital audio playback: DMA and RAW. The DMA method is most commonly used. The steps for playback are as follows: 1) Set $4012 (DMC Address Register) to the 64-byte aligned offset within PRG-ROM $C000-FFFF. For instance, if $8E is written here, the sample data will be loaded from ($8E*64)+C000, or $E380. 2) Set $4013 (DMC Length Register) to the length of the sample data. The sample length is defined as (16*x)+1, where x is the value written. 3) Set $4010 (DMC Frequency Register) to whatever 4-bit frequency you desire. 4) Set Bit #4 of $4015 (Channel Control) to 1, enabling the DMC channel. The sample data used for the DMA method is 1-bit unsigned data. The actual format of the data is currently unknown, as is the latency of playback. The RAW method is used in carts such as Tengen's "Gauntlet 2," for 8-bit "high-quality" speech. The steps for playback are as follows: 1) Write the 8-bit value to $4011 (DMC Volume Register). F. Notes -------- The sound constant on the NES is 3579545/32, or 111860.78. +------------------------------+ | 6. Joypads and other devices | +------------------------------+ A. General Information ---------------------- The NES directly supports up to two (2) joypads, or one (1) joypad and one (1) Zapper (light gun). It can also support four-player devices which allow for the use of up to four (4) joypads simultaneously. Both joypads are accessed via registers $4016 and $4017. Each joypad is reset via a strobing-method: writing 1, then 0 to either register. From there on, the joypad's button status will be returned in a single-bit stream. Multiple reads need to be made to read all the information about the controller. 1 = A 9 = Ignored 17 = +--+ 2 = B 10 = Ignored 18 = +-- Signature 3 = SELECT 11 = Ignored 19 = | 4 = START 12 = Ignored 20 = +--+ 5 = UP 13 = Ignored 21 = 0 6 = DOWN 14 = Ignored 22 = 0 7 = LEFT 15 = Ignored 23 = 0 8 = RIGHT 16 = Ignored 24 = 0 See Subsection G for information about Signatures. B. The Zapper ------------- No information is currently available. C. Four-player devices ---------------------- Some NES games allow the use of a four-player adapter, extending the number of usable joypads from two (2) to four (4). Carts which use the quad-player device are Tengen's "Gauntlet II," and Nintendo's "RC Pro Am 2." All four (4) controllers read their status-bits from Bit #0 (as Subsection A states) of $4016 or $4017. For register $4016, reads #1-8 control joypad #1, and reads #9-16 control joypad #3. For $4017, it is respective for joypad #2 and #4. The following is a list of read #s and their results. 1 = A 9 = A 17 = +--+ 2 = B 10 = B 18 = +-- Signature 3 = SELECT 11 = SELECT 19 = | 4 = START 12 = START 20 = +--+ 5 = UP 13 = UP 21 = 0 6 = DOWN 14 = DOWN 22 = 0 7 = LEFT 15 = LEFT 23 = 0 8 = RIGHT 16 = RIGHT 24 = 0 See Subsection G for information about Signatures. D. Paddles ---------- Taito's "Arkanoid" uses a paddle as it's primary controller. The paddle position is read via Bit #1 of $4017; the read data is inver- ted (0=1, 1=0). The first value read is the MSB, and the 8th value read is (obviously) the LSB. Valid value ranges are 98 to 242, where 98 rep- resents the paddle being turned completely counter-clockwise. For example, if %01101011 is read, the value would be NOT'd, making %10010100 which is 146. The paddle also contains one button, which is read via Bit #1 of $4016. A value of 1 defines the button being pressed. E. Power Pad ------------ No information is currently available. F. R.O.B. (Robot Operated Buddy) -------------------------------- No information is currently available. G. Signatures ------------- A signature allows the programmer to detect if a device is connected to one of the four (4) ports or not, and if so, what type of device it is. Valid/known signatures are: %0000 = Disconnected %0001 = Joypad ($4016 only) %0010 = Joypad ($4017 only) H. Notes -------- None. +----------------------------+ | 7. Memory Mapping Hardware | +----------------------------+ Due to the large number of mappers used (over 64), the "MMC" section which was once fluid in v0.53 of this document, has now been removed. All is not lost, as another document by \FireBug\ of Vertigo 2099 con- tains accurate information about nearly every mapper in existence. You can retrieve a copy via one of the following URLs: http://free.prohosting.com/~nintendo/mappers.nfo Please note I take no responsibility for the information contained in the aforementioned document. Contact lavos999@aol.com for more information. +--------------+ | 8. Registers | +--------------+ Programmers communicate with the PPU and pAPU via registers, which are nothing more than pre-set memory locations which allow the coder to make changes to the NES. Without registers, programs wouldn't work: period. Each register is a 16-bit address. Each register has a statistics field in parentheses located immediately after its description. The legend: R = Readable W = Writable 2 = Double-write register ? = Unknown or possibly incorrect Underneath the description is a binary representation of each bit which is part of the register itself. The legend: 0 = Always zero 1 = Always 1 - = Not used ? = Unknown +---------+----------------------------------------------------------+ | Address | Description | +---------+----------------------------------------------------------+ | $2000 | PPU Control Register #1 (W) | | | %vMsbpiNN | | | v = Execute NMI on VBlank | | | 1 = Enabled | | | M = PPU Selection (unused) | | | 0 = Master | | | 1 = Slave | | | s = Sprite Size | | | 0 = 8x8 | | | 1 = 8x16 | | | b = Background Pattern Table Address | | | 0 = $0000 (VRAM) | | | 1 = $1000 (VRAM) | | | p = Sprite Pattern Table Address | | | 0 = $0000 (VRAM) | | | 1 = $1000 (VRAM) | | | i = PPU Address Increment | | | 0 = Increment by 1 | | | 1 = Increment by 32 | | | NN = Name Table Address | | | 00 = $2000 (VRAM) | | | 01 = $2400 (VRAM) | | | 10 = $2800 (VRAM) | | | 11 = $2C00 (VRAM) | | | | | | NOTE: Bit #6 (M) has no use, as there is only one (1) | | | PPU installed in all forms of the NES and Famicom. | +---------+----------------------------------------------------------+ | $2001 | PPU Control Register #2 (W) | | | %fffpcsit | | | fff = Full Background Colour | | | 000 = Black | | | 001 = Red | | | 010 = Blue | | | 100 = Green | | | p = Sprite Visibility | | | 1 = Display | | | c = Background Visibility | | | 1 = Display | | | s = Sprite Clipping | | | 0 = Sprites not displayed in left | | | 8-pixel column | | | 1 = No clipping | | | i = Background Clipping | | | 0 = Background not displayed in | | | left 8-pixel column | | | 1 = No clipping | | | t = Display Type | | | 0 = Colour display | | | 1 = Mono-type (B&W) display | +---------+----------------------------------------------------------+ | $2002 | PPU Status Register (R) | | | %vhsw---- | | | v = VBlank Occurance | | | 1 = In VBlank | | | h = Sprite #0 Occurance | | | 1 = VBlank has hit Sprite #0 | | | s = Scanline Sprite Count | | | 0 = Less than 8 sprites on the | | | current scanline | | | 1 = More than 8 sprites on the | | | current scanline | | | w = VRAM Write Flag | | | 1 = Writes to VRAM are ignored | | | | | | NOTE: If read during HBlank and Bit #7 of $2000 is set | | | to 0, then switch to Name Table #0. | | | NOTE: After a read occurs, $2005 is reset, hence the | | | next write to $2005 will be Horizontal. | | | NOTE: Bit #6 (h) is set to 0 after each VBlank. | | | NOTE: Bit #6 (h) is not set until the first actual non- | | | transparent pixel is drawn. Hence, if you have a | | | 8x8 sprite which has all pixels transparent except | | | for pixel #4 (horizontally), Bit #6 will be set | | | after the 4th pixel is found & drawn. | | | NOTE: Bit #7 (v) is set to 0 after read occurs. | | +----------------------------------------------------------+ | | PPU Status Register (W) | | | %???????? | +---------+----------------------------------------------------------+ | $2003 | SPR-RAM Address Register (W) | | | | | | Specifies the 8-bit address in SPR-RAM to access via | | | $2004. | +---------+----------------------------------------------------------+ | $2004 | SPR-RAM I/O Register (RW) | | | | | | Used to R/W 8-bit data to/from SPR-RAM. | +---------+----------------------------------------------------------+ | $2005 | Background Scroll Register (W2) | | | | | | Used to pan/scroll the pre-rendered screen (excluding | | | sprites) horizontally and vertically. The data is | | | written in the following mannar: | | | | | | BYTE 1: Horizontal | | | BYTE 2: Vertical | +---------+----------------------------------------------------------+ | $2006 | VRAM Address Register (W2) | | | | | | Specifies the 16-bit address in VRAM to access via | | | $2007. The data is written in the following mannar: | | | | | | BYTE 1: Upper 8-bit portion of effective address | | | BYTE 2: Lower 8-bit portion of effective address | +---------+----------------------------------------------------------+ | $2007 | VRAM I/O Register (RW) | | | | | | Used to R/W 8-bit data to/from VRAM. | +---------+----------------------------------------------------------+ | $4000 | pAPU Pulse #1 Control Register #1 (W) | | | %CCwessss | | | CC = Duty Cycle (Positive vs. Negative) | | | 00 = 87.5% | | | 01 = 75.0% | | | 10 = 50.0% | | | 11 = 25.0% | | | w = Waveform Hold (e.g. Looping) | | | 1 = On | | | e = Envelope Select | | | 0 = Varied | | | 1 = Fixed | | | s = Playback Rate | +---------+----------------------------------------------------------+ | $4001 | pAPU Pulse #1 Control Register #2 (W) | | | %fsssMrrr | | | f = Frequency Sweep | | | 0 = Off (Bits #0-6 ignored) | | | 1 = On (Bits #0-6 respected) | | | sss = Frequency Change Speed | | | M = Frequency Method | | | 0 = High --> Low | | | 1 = Low --> High | | | rrr = Frequency Range (0=Min, 7=Max) | +---------+----------------------------------------------------------+ | $4002 | pAPU Pulse #1 Frequency Register #1 (W) | | | %ffffffff | | | f = Frequency (lower 8-bits) | | | | | | NOTE: The entire frequency is 11-bits in size; be aware | | | that the upper 3-bits are in $4003. | +---------+----------------------------------------------------------+ | $4003 | pAPU Pulse #1 Frequency Register #2 (W) | | | %tttttfff | | | t = Active Time Length | | | fff = Frequency (upper 3-bits) | +---------+----------------------------------------------------------+ | $4004 | pAPU Pulse #2 Control Register #1 (W) | | | %CCwessss | | | CC = Duty Cycle (Positive vs. Negative) | | | 00 = 87.5% | | | 01 = 75.0% | | | 10 = 50.0% | | | 11 = 25.0% | | | w = Waveform Hold (e.g. Looping) | | | 1 = On | | | e = Envelope Select | | | 0 = Varied | | | 1 = Fixed | | | s = Playback Rate | +---------+----------------------------------------------------------+ | $4005 | pAPU Pulse #2 Control Register #2 (W) | | | %fsssMrrr | | | f = Frequency Sweep | | | 0 = Off (Bits #0-6 ignored) | | | 1 = On (Bits #0-6 respected) | | | sss = Frequency Change Speed | | | M = Frequency Method | | | 0 = High --> Low | | | 1 = Low --> High | | | rrr = Frequency Range (0=Min, 7=Max) | +---------+----------------------------------------------------------+ | $4006 | pAPU Pulse #2 Frequency Register #1 (W) | | | %ffffffff | | | f = Frequency (lower 8-bits) | | | | | | NOTE: The entire frequency is 11-bits in size; be aware | | | that the upper 3-bits are in $4007. | +---------+----------------------------------------------------------+ | $4007 | pAPU Pulse #2 Frequency Register #2 (W) | | | %tttttfff | | | t = Active Time Length | | | fff = Frequency (upper 3-bits) | +---------+----------------------------------------------------------+ | $4008 | pAPU Triangle Control Register #1 (?) | | | %???????? | +---------+----------------------------------------------------------+ | $4009 | pAPU Triangle Control Register #2 (?) | | | %???????? | +---------+----------------------------------------------------------+ | $400A | pAPU Triangle Frequency Register #1 (W) | | | %ffffffff | | | f = Frequency (lower 8-bits) | | | | | | NOTE: The entire frequency is 11-bits in size; be aware | | | that the upper 3-bits are in $400B. | +---------+----------------------------------------------------------+ | $400B | pAPU Triangle Frequency Register #2 (W) | | | %tttttfff | | | t = Active Time Length | | | fff = Frequency (upper 3-bits) | +---------+----------------------------------------------------------+ | $400C | pAPU Noise Control Register #1 (W) | | | %???????? | +---------+----------------------------------------------------------+ | $400D | pAPU Noise Control Register #2 (W) | | | %???????? | +---------+----------------------------------------------------------+ | $400E | pAPU Noise Frequency Register #1 (W) | | | %ffffffff | | | f = Frequency (lower 8-bits) | | | | | | NOTE: The entire frequency is 11-bits in size; be aware | | | that the upper 3-bits are in $400F. | +---------+----------------------------------------------------------+ | $400F | pAPU Noise Frequency Register #2 (W) | | | %tttttfff | | | t = Active Time Length | | | fff = Frequency (upper 3-bits) | +---------+----------------------------------------------------------+ | $4010 | pAPU DMC Control Register (W) | | | %i???ssss | | | i = Generate IRQ when finished | | | 1 = Enabled | | | s = Frequency | +---------+----------------------------------------------------------+ | $4011 | pAPU DMC Volume Register (W) | | | | | | Defines the 8-bit volume of the DMC channel. Can also | | | be used for RAW data playback. | +---------+----------------------------------------------------------+ | $4012 | pAPU DMC Address Register (W) | | | | | | Defines the 64-byte aligned offset within PRG-ROM | | | $C000-FFFF for the sample data. ($4012*64)+$C000 is the | | | effective address. | +---------+----------------------------------------------------------+ | $4013 | pAPU DMC Data Length Register (W) | | | | | | Defines the length of the sample data. ($4013*16)+1 is | | | the actual calculated length. | +---------+----------------------------------------------------------+ | $4014 | SPR-RAM DMA Register (W) | | | | | | Transfers 256 bytes of memory into SPR-RAM. The address | | | read from is $100*N, where N is the value written. | +---------+----------------------------------------------------------+ | $4015 | pAPU Status Register (R) | | | %0000000p | | | p = Status | | | 1 = pAPU in use | | +----------------------------------------------------------+ | | pAPU Channel Control (W) | | | %---edcba | | | a = Pulse #1 (1=Enabled) | | | b = Pulse #2 (1=Enabled) | | | c = Triangle (1=Enabled) | | | d = Noise (1=Enabled) | | | e = DMC (1=Enabled) | +---------+----------------------------------------------------------+ | $4016 | Joypad #1 (R) | | | %???STeed | | | S = Zapper Sprite Detection | | | 1 = Sprite in front of cross-hair | | | T = Zapper Trigger | | | 0 = Pressed | | | ee = Expansion Port Data | | | d = Joypad Data | | +----------------------------------------------------------+ | | Joypad #1 (W) | | | %?????ees | | | ee = Expansion Port Data | | | s = Joypad Strobe | | | 0 = Clear joypad strobe | | | 1 = Reset joypad strobe | +---------+----------------------------------------------------------+ | $4017 | Joypad #2 (R) | | | %???STeed | | | S = Zapper Sprite Detection | | | 1 = Sprite in front of cross-hair | | | T = Zapper Trigger | | | 0 = Pressed | | | ee = Expansion Port Data | | | d = Joypad Data | | +----------------------------------------------------------+ | | Joypad #2 (W) | | | %???????? | +---------+----------------------------------------------------------+ +-----------------+ | 9. File Formats | +-----------------+ A. iNES Format (.NES) --------------------- +--------+------+------------------------------------------+ | Offset | Size | Content(s) | +--------+------+------------------------------------------+ | 0 | 3 | 'NES' | | 3 | 1 | $1A | | 4 | 1 | 16K PRG-ROM page count | | 5 | 1 | 8K CHR-ROM page count | | 6 | 1 | ROM Control Byte #1 | | | | %####vTsM | | | | | ||||+- 0=Horizontal Mirroring | | | | | |||| 1=Vertical Mirroring | | | | | |||+-- 1=SRAM enabled | | | | | ||+--- 1=512-byte trainer present | | | | | |+---- 1=Four-screen VRAM layout | | | | | | | | | | +--+----- Mapper # (lower 4-bits) | | 7 | 1 | ROM Control Byte #2 | | | | %####0000 | | | | | | | | | | +--+----- Mapper # (upper 4-bits) | | 8-15 | 8 | $00 | | 16-.. | | Actual 16K PRG-ROM pages (in linear | | ... | | order). If a trainer exists, it precedes | | ... | | the first PRG-ROM bank. | | ..-EOF | | CHR-ROM pages (in ascending order). | +--------+------+------------------------------------------+ B. Famicom Disk System (.DKA/.DKB/.500) --------------------------------------- +--------+------+---------------------------------------+ | Offset | Size | Content(s) | +--------+------+---------------------------------------+ | [IMAGE HEADER] | | 0 | 1 | | | 1 | 3 | Disk ID | | 6 | 1 | Disk # | | 38 | 1 | Disk # (???) | | 63 | 1 | Amount of data blocks | | | | [DATA BLOCK HEADER] | | 64 | 1 | $03 | | 65 | 1 | Block # | | 66 | 1 | | | 67 | 8 | Name | | 75 | 2 | Destination | | 77 | 2 | Size of data | | 79 | 1 | Data Type | | | | $00 = PRG-RAM | | | | $01 = CHR-ROM | | | | $02 = 6-bit audio data | | 79-.. | | Data | | ... | | | | ... | | Repeat loading DATA BLOCKS HEADERS as | | ... | | shown above; continue loading until | | ..-EOF | | EOF is reached. | +--------+------+---------------------------------------+ C. dNESe Format --------------- Information unavailable. Contact Ryan Auge for details. D. fwNES Format --------------- Information unavailable. E. Notes -------- The Famicom Disk System format bases disk sides on the file extension; .DKA being Side-A, and .DKB being Side-B. Each side of a disk is 64K in size, hence both files should be exactly 65536 bytes in size. +-------------------------+ | 10. Programming the NES | +-------------------------+ A. General Information ---------------------- None. B. CPU Notes ------------ None. See Section 11, Subsection B for more possible information. C. PPU Notes ------------ Reading and writing to VRAM consist of a tri or quad-step process (Step #1 being optional, based on if you wish to do mid-HBlank updates or not): Writing to VRAM Reading from VRAM --------------- ----------------- 1) Wait for VBlank 1) Wait for VBlank 2) Write upper VRAM address 2) Write upper VRAM address byte into $2006 byte into $2006 3) Write lower VRAM address 3) Write lower VRAM address byte into $2006 byte into $2006 4) Write data to $2007 4) Read data from $2007 *** NOTE: Accessing VRAM should only be performed during VBlank. Attempts to access VRAM outside of VBlank will usually result in a mid-HBlank access (See Section 4, Subsection L). This is probably not what you want. Waiting for VBlank is quite simple. In most cases, you will simply want to wait for it to start. In other cases (such as for a delay), waiting for VBlank to start _AND_ end is useful. VBlank Start VBlank Start & End ------------ ------------------ L1 LDA $2002 L1 LDA $2002 BPL L1 BPL L1 L2 LDA $2002 BMI L2 Reading $2002 will result in all bits being returned; however, Bit #7 (VBlank) will be reset to 0 after the read is performed. Many Squaresoft games use this method to reset the status of VBlank, so that they may do mid-HBlank updates. The actual on-screen palette used by the NES, as stated prior, is not RGB. However, a near-exact replica can be found in common NES emulators today. Contact the appropriate authors of these emulators to obtain a valid RGB palette. D. Notes -------- None. +---------------+ | 11. Emulation | +---------------+ A. General Information ---------------------- If you're going to be programming an emulator in C or C++, please be familiar with pointers. Being familiar with pointers will help you out severely when it comes to handling mirroring and VRAM addressing. For you assembly buffs out there, obviously pointers are nothing more than indirect addressing -- it's easier to change a 32-bit value than to swap in and out an entire 64K of data. See Section 12, Subsection E for Mailing List information. B. CPU Notes ------------ The NES does not use a 65C02 (CMOS) CPU as rumored. The 6502 has a bug in opcode $6C (jump absolute indirect). The CPU does not correctly calculate the effective address if the low-byte is $FF. Example: $C000: 4F $C1FF: 00 $C200: 23 .. $D000: 6C FF C1 - JMP ($C1FF) Logically, this will jump to address $2300. However, due to the fact that the high-byte of the calculate address is *NOT* increased on a page-wrap, this will actually jump to $4F00. Ignore opcodes which are bad (or support the option of trapping bad opcodes or not). Some ROM images out there, such as "Adventures of Lolo" have bad opcodes in them, due to dirty connectors on the cart- ridge during the extraction process, or other reasons. C. PPU Notes ------------ The formulae to calculate the base address of a Name Table tile number is: (TILENUM * 16) + PATTERNTABLE Where TILENUM is the tile number in the Name Table, and PATTERNTABLE is the Pattern Table Address defined via register $2000. It's recommended that DOS programmers use what is known as "MODE-Q," a 256x256x256 "tweaked" video mode, for writing their emulator. Try to avoid Mode-X modes, as they are non-chained, and result in painfully slow graphics. Chained modes (like MODE-13h) are linear, and work best for speedy graphics. Since the NES's resolution is 256x240, the aforementioned "MODE-Q" should meet all necessary requirements. Most emulators do not limit the number of sprites which can be displayed per scanline, while the actual NES will show flicker as a result of more than eight (8). {Put some more garbage here; it's early...} Emulators should _NOT_ mask out unused bits within registers; doing so may result in a cart not working. Some emulators choose to store 0 as the vertical scroll value of the background if a value >239 is written to $2005. I don't know if this method of implementation is "correct." D. APU Notes ------------ The following formulae can be used to obtain accurate playback of the pulse, triangle, and noise channel(s): Pulse1 = 111860.78 / ($4002 + ($4003 & 7)) Pulse2 = 111860.78 / ($4006 + ($4007 & 7)) Tri = 111860.78 / ($400A + ($400B & 7) / 2) Noise = 111860.78 / ($400E + ($400F & 7)) Where the $400x values are actually taken from their respective registers. E. FAQ (Frequently Asked Questions) ----------------------------------- Not available. +------------------------+ | 12. Reference Material | +------------------------+ A. CPU Information ------------------ None. B. PPU Information ------------------ None. C. APU Information ------------------ None. D. MMC Information ------------------ None. E. Mailing Lists ---------------- There is a NES Development Mailing List in existence. Contact Mark Knibbs for more information. This list is for anyone who wishes to discuss tech- nical issues about the NES; it is not a list for picking up the latest and greatest information about NES emulators or what not.