diff --git a/README.md b/README.md index f08086d..25d6f19 100644 --- a/README.md +++ b/README.md @@ -1,12 +1,12 @@ -The O.G. NESasm assembler for NES 6502 assembly, version 3.1 (Latest as of March 2016). Includes `Makefile` for OS X and other Unix-like OSes. +The O.G. NESasm assembler for NES 6502 assembly, version 3.1 (Latest as of March 2016). Includes `Makefile` for OS X / Linux / other Unix-like OSes. ###### Usage ```bash -cd source && make +cd source && make && sudo make install ``` -The produces a binary, `nesasm`, that you'll want to put on your `$PATH` somewhere. +Then run the assembler with `nesasm`. See [`usage.txt`](https://raw.githubusercontent.com/camsaul/nesasm/master/usage.txt) for more details. @@ -15,4 +15,13 @@ See [`usage.txt`](https://raw.githubusercontent.com/camsaul/nesasm/master/usage. Original source, by [bunnyboy](http://nintendoage.com/index.cfm?FuseAction=Users.Home&User=bunnyboy), is [available here](http://www.nespowerpak.com/nesasm/). The only modification I made is inclusion of the `Makefile`, which was adapted from the one included with [MagicKit](http://www.magicengine.com/mkit/), and the text files, -which were found in various places in the aforementioned sites. +which were found in various places in the aforementioned sites and by lots of research/searching on my part. + + +###### Resources + +* [NerdyNights NES Programming Tutorials](http://nintendoage.com/auth/forum/messageview.cfm?catid=22&threadid=7155) +* [nesdev.com](http://nesdev.com/) +* [Beagle Bros. 6502 Cheatsheet](https://raw.githubusercontent.com/camsaul/nesasm/master/beagle_bros_6502_reference.png) +* [Programming the 65816 (PDF of book available for free)](http://archive.6502.org/datasheets/wdc_65816_programming_manual.pdf) +* [NES Technical Documentation by YOSHi](https://raw.githubusercontent.com/camsaul/nesasm/master/nes_technical_documentation.txt) diff --git a/beagle_bros_6502_reference.png b/beagle_bros_6502_reference.png new file mode 100644 index 0000000..b207608 Binary files /dev/null and b/beagle_bros_6502_reference.png differ diff --git a/ines_header_format.txt b/ines_header_format.txt new file mode 100644 index 0000000..b513177 --- /dev/null +++ b/ines_header_format.txt @@ -0,0 +1,664 @@ +[iNES Header/Format Information File] +[Version 2.0 Compiled on 1/31/98] +[VmprHntrD - kennedy5@flash.net] + + +NOTE: This document is on the iNES format is almost totally complete. I still +need to add some little tidbits as the iNES format is updated. Please do not +modify this document in any way without MY prior consent. If you wish to add +to this please talk to me through e-mail, or in the evenings on the IRC - +EFnet, in the channel #emu. [I'm an OP in there.] :P + +BE ADVISED: Any emails sent to me about ROM requests will be ignored and most +likely forwarded to the SPA at piracy@spa.org. You get one warning and this +is it, sorry to be harsh but I have to. ...Am I a nice guy or what? + +<"In"Famous Quotes:> +"Power TENDS to corrupt; Absolute power corrupts absolutely." - I forget :) +"Escape is impossible and obedience is imperative!" - Cmdr. Yurak from Voltron +"I'm surrounded by fools and imbusiles!" - King Zarkon from Voltron + + +* Zophar for help with some math and errors. +* FanWen for the greater extension of the iNES Extended Header format and all + the associated work along with it. +* Groups like Damaged Cybernetics, GitM, NPS, Vertigo 2099 and more that have + in one way or the other brought us the games this guide pertains to. +* Anyone who has ever e-mailed and/or talked to me in IRC that assisted in the + fixes and upkeep of this guide. +* And thanks to all the loyal readers that actually care about this document + and what I have to say here. + + +[Table of Contents]___________________________________________________________ + +Section 1 .... Known HEXidecimal Values of the First 8 Bytes of the NES Header +Section 2 ................... The Seventh and Eighth Bytes' HEXidecimal Values +Section 3 ........... Common iNES File Sizes & What They Are Made Of (PRG/CHR) +Section 4 .................................. HEXidecimal Values of the PRG/CHR +Section 5 ........................ Miscellaneous Information on the NES Format +Section 6 ......... Let's Get Cracking on Prepping Your RAW/FFE/PasoFami Image +Section 7 ......... Information (Recommended Tools for Converting iNES Images) +Section 8 ...... UPDATES (The History of the iNES Header/Format Documentation) + + +[Sect.1: - Known HEXidecimal Values of the First 8 Bytes of the NES Header]___ + +...Those FIRST (8) bytes of your NES, or to be a NES file... + +(Bytes 0->3 MUST BE What is stated below.) + +0 = 4E (N) +1 = 45 (E) +2 = 53 (S) +3 = 1A (Character Break, necessary!) + +(Bytes 4->8-15 Can BE MODIFIED!) + +4 = PRG (Hex number depends on size of PRG file)-/-- (See Sect. 4) +5 = CHR (Hex number depends on size of CHR file)/ +6 = Mapper 0-15/ V or H Mirroring, Battery, 4 Screen VRAM, Trainer Switches + Also is used as the "Ones" place holder digit for the extended iNES Header + format. (See Sect. 2) +7 = Mappers 16-?, the extended iNES Header format "Tens" place holder digit. + Again (See Sect. 2 for details on how this is set up.) + +8->15 = Not used at this tume but MUST BE ALL ZEROS or games will not work. + +NOTE: Now that there is a fully established Extened iNES Header Format set up + gracefully by FanWen and Marat Fayzullin ALWAYS leave in games that do + not use over mapper 15 blank in bytes 8->15 or games WILL NOT WORK! + +[Sect.2: - The Seventh and Eighth Bytes' HEXidecimal Values]__________________ + +Byte 6 in a hexeditor will look something like this: + + 59 <---This is for CastleVania III: Dracula's Curse + +(The "5" is the mapper number, the "9" stands for Vertical Mirroring AND 4 +Screen VRAM ON!) -- See below for all the possible values! + +Byte 7 in a hexeditor will look a little different, something like this: + + * 1->F/0<---Only the first part is used in coorilation with the first + part of byte 6 above. *READ BELOW FOR EXAMPLE!* + +*Extended iNES Header Format Design* + +Basically in this extended design the 7th byte is used to implement mappers of +16 and higher. It does this through a hexidecimal conversion of the actual +mapper number. In my example I'll use Mapper 69 with a vertical switch(1). + +Example: Mapper 69 = 4E in hexidecimal... + +Therefore in the new iNES Extended Header format this is how bytes 6 and 7 +would look in hex and work together. + +Example: +Bytes=> 0 1 2 3 4 5 6 7 + N E S ^Z PRG CHR MAP/SW MAP/0(always) + 4E 45 53 1A 10 20 E1 40 + +* See above that the ONES DIGIT (E) is in the 6th byte, and the TENS DIGIT (4) + is the first half of the 7th byte. But be advised that the second half of + the 7th byte in hex HAS TO ALWAYS BE 0 (zero)! + +*AND NOW FOR THE BAD NEWS FOR "YOU"* + +Considering iNES has always set the standard for "Mapper Compatibility" we are +now faced with a new problem ...CONVERSION. We must convert the current games +we have to the new format which is very TIME CONSUMING because of the iNES +Header Editors out there that insert extra garbage into the header. Therefore +let's get to FIXING YOUR GAMES for the new "Extended iNES Header Format": + +* First get out your hexeditor and move over to the eighth byte. For example + lets use the NESimage tag of: "DiskDude!" +* On the 7th byte it will be covered by the "D", to make your game a "clean" + image you must on the hexidecimal side put a double zero "00" through bytes + 7-15, then save it. +* Be very careful doing so, if you hit the first byte of the game, its DEAD if + you aren't paying attention and save it...you've been warned. +* If you can find a program on the internet called "NESFIX.EXE" this will do + all the tasks above in a fraction of the time of doing it manually. Ask + around a few people will be able to get it to you. + + +[Below is the current possibilities for the all the supported mappers] + +NOTE: The format for this graph is taken from the iNES 0.7 doc to give you a + better example of what each mapper is and runs... I would personally + like to thank Marat Fayzullin, Yang FanWen, Y0SHi, and anybody else I + left out that assisted in the adding of these new MAPPERS! + + +Mapper # Name Examples (Game Names, etc.) +______________________________________________________________________________ + +0 No Mapper All 32kb ROM + 8kb VROM games like Super + Mario Bros, Balloon Fight, Slalom, etc. +1(fixed) Nintendo MMC1 Chipset 1942, Bomberman II, Mega Man II, etc. +2 ROM (PRG) Switch Konami games like CastleVania and Stinger. +3 VROM (CHR) Switch Twin Bee, Q*Bert, and many japanese games. +4(fixed) Nintendo MMC3 Chipset Super Mario Bros 2 & 3, Silver Surfer, etc. +5(100%!) Nintendo MMC5 Chipset CastleVania III: Dracula's Curse +6 FFE F4XXX Games F4XXX Games off the FFE CD-ROM +7 32kb ROM (PRG) Switch Wizards & Warriors, Marble Madness, etc. +8 FFE F3XXX Games F3XXX Games off the FFE CD-ROM +9 Nintendo MMC2 Chipset Mike Tyson's Punch-Out!!, and Punch-Out!! +10 Nintendo MMC4 Chipset Japanese Punch-Out!!, and japanese games. +11 Color Dreams Chipset Crystal Mines, Tagin' Dragon, Babyboom, etc. +12 FFE F6XXX Games F6XXX Games off the FFE CD-ROM +15 100-in-1 Cart Switch 100-in-1 Multicart Switch + +Below are all the Extened iNES Header Format Mappers which are now, or will be +in the near future added into another emulator yet to be publicly released. +* Read above in Section 2 on how to implement Mappers 16 and up in iNES. + +16 Ban Dai Chipset Japanese: Dragon Ball Z, Gaiden etc. +17 FFE F8XXX Games F8XXX Games off the FFE CD-ROM +18 Jaleco SS8806 Chipset Japanese: Jaleco's Sport Series +19 Namcot 106 Chipset Japanese: Famista 90-92, Megami Teisen 1-2 +20 Famicom Disk System Reserved for the Disk System, DON'T USE IT! +21 Konami VRC4 2a Chipset Japanese: Wai Wai World2, Goemon Gaiden 2 +22 Konami VRC4 1b Chipset Japanese: Twinbee 3, etc. +23 Konami VRC4 1a Chipset Japanese: Wai Wai World, Kid Dracula, etc. +24 Konami VRC6 Chipset Japanese: CastleVania 3j, MADAKAJ, etc. +25 Konami VRC4 Chipset Japanese: Konami Baseball, Gradius 2, etc. +32 Irem G-101 Chipset Japanese: Image Fighter 2, etc. +33 Taito TC0190/TC0350 Japanese: PonDoKoPon, Bubble Bobble 2j, etc. +34 32kb ROM (PRG) Switch Japanese: Impossible Mission, Deadly Towers +65 Irem H3001 Chipset Japanese: Mr. Love, Mr. Big Hammer, P-Man2 +66 74161/32 Chipset Japanese: Dragonball 1, BioWarrior DAN +67 Sunsoft Mapper 3 Japanese: Unknown +69 Sunsoft Mapper 4 Japanese: Afterburner 2 +70 74161/32 Chipset Japanese: Unknown variant +80 X-005 Chipset Japanese: Demon Sword +81 C075 Chipset Japanese: Unknown +82 X1-17 Chipset Japanese: Unknown +83 Cony Mapper Japanese: Garbo Dentsu +84 PasoFami Mapper! Japanese: (.500 .MOD) Supported + + +[Below is the current possibilities for the second figure of the 7th byte.] + +This part of the byte is the place you setup the game to use, or not use +Horizontal or Vertical mirroring, Battery Backup, 4 Screen VRAM, and a built +in Trainer. Below are the different combinations of all the listed options +in HEXidecimal format. + +0 = H (Horizontal Mirroring ONLY) +1 = V (Vertical Mirroring ONLY) +2 = H + Bat. (Horizontal Mirroring + Battery ON) +3 = V + Bat. (Vertical Mirroring + Battery ON) +4 = H + Train. (Horizontal Mirroring + Trainer ON) +5 = V + Train. (Vertical Mirroring + Trainer ON) +6 = H + Bat. + Train. (Horizontal Mirroring + Battery and Trainer ON) +7 = V + Bat. + Train. (Vertical Mirroring + Battery and Trainer ON) +8 = H + 4scr. (Horizontal Mirroring + 4 Screen VRAM ON) +9 = V + 4scr. (Vertical Mirroring + 4 Screen VRAM ON) +A = H + Bat. + 4scr. (Horizontal Mirroring + Battery and 4 Screen VRAM ON) +B = V + Bat. + 4scr. (Vertical Mirroring + Battery and 4 Screen VRAM ON) +C = H + 4scr. + Train. (Horizontal Mirroring + 4 Screen VRAM and Trainer ON) +D = V + 4scr. + Train. (Vertical Mirroring + 4 Screen VRAM and Trainer ON) +E = H + Bat. + 4scr. + Train. (Horizontal Mirroring + Battery, 4 Screen VRAM, + and Trainer ON) +F = V + Bat. + 4scr. + Train. (Vertical Mirroring + Battery, 4 Screen VRAM, + and Trainer ON) + + +[Sect. 3: - Common iNES File Sizes & What They Are Made of (PRG/CHR)]_________ + +These are the "known" formats TO ME for the iNES format NES Players! Be +advised that "ROM" and "VROM" were the names of the chips that the "PRG" and +"CHR" data were stored on. [ROM = PRG VROM = CHR] + +[24K - 24576 bytes] +(EX: Donkey Kong - 131Kbit ROM + 65Kbit VROM) + +PRG => 16384 bytes (1 x 16kb pages) +CHR => 8192 bytes (1 x 8kb pages) + + +[40K - 40960 bytes] +(EX: Super Mario Bros. - 262Kbit ROM + 65Kbit VROM) + +PRG => 32768 bytes (2 x 16kb pages) +CHR => 8192 bytes (1 x 8kb pages) + + +[48K - 49152 bytes] +(EX: Twin-Bee - 262Kbit ROM + 131Kbit VROM) + +PRG => 32768 bytes (2 x 16kb pages) +CHR => 16384 bytes (2 x 8kb pages) + + +[64K - 65536 bytes] +(EX: Spy Hunter - 262Kbit ROM + 262Kbit VROM) + +PRG => 32768 bytes (2 x 16kb pages) +CHR => 32768 bytes (4 x 8kb pages) + + +[80K - 81936 bytes] +(EX: Dragon Warrior - 512 Kbit ROM + 131Kbit VROM) + +PRG => 65532 bytes (4 x 16kb pages) +CHR => 16384 bytes (2 x 8kb pages) + + +[128K - 131088 bytes] +(EX: Legend of Zelda - 1MBit ROM) + +PRG => 131088 bytes (8 x 16kb pages) +CHR => (NONE - "imbedded") + + +[132K - 139280 bytes] +(EX: Stinger (Twin Bee 2 USA - 1MBit ROM + 65Kbit "imbedded" VROM) + +PRG => 131088 bytes (8 x 18kb pages) +CHR => (8192 bytes ="imbedded") + + +[160K - 163840 bytes] +(EX: Mappy Land: 1MBit ROM + 262Kbit VROM) + +PRG => 131088 bytes (8 x 18kb pages) +CHR => 32768 bytes (4 x 8kb pages) + + +[192K - 196608 bytes] +(EX: CastleVania II: Simon's Quest - 1MBit ROM + 512Kbit VROM) + +PRG => 131072 bytes (8 x 16kb pages) +CHR => 65536 bytes (8 x 8kb pages) + + +[192K - 196608 bytes] +(EX: Wall Street Kid - 1MBit ROM + 512Kbit "imbedded" VROM) + +PRG => 131072 bytes (8 x 16kb pages) +CHR => (65536 bytes - "imbedded") + + +[224K - 229392 bytes] +(EX: Mad Max - 1MBit ROM + 785Kbit VROM] + +PRG => 131072 bytes (8 x 16kb pages) +CHR => 98304 bytes (12 x 8kb pages) + + +[232K - 237584 bytes] +(EX: Tetris 2 - 1MBit ROM + 851Kbit VROM) + +PRG => 131072 bytes (8 x 16kb pages) +CHR => 106496 bytes (13 x 8kb pages) + + +[240K = 245760 bytes] +(EX: Legend of Zelda 2 - 1MBit ROM + 917Kbit VROM) + +PRG => 131072 bytes (8 x 16kb pages) +CHR => 114688 bytes (14 x 8kb pages) + + +[248K - 253468 bytes] +(EX: Super Contra - 1Mbit ROM + 925Kbit VROM) + +PRG => 131072 bytes (8 x 16kb pages) +CHR => 122880 bytes (15 x 8kb pages) + + +[256K - 262144 bytes] +(EX: Final Fantasy - 2MBit ROM) + +PRG => 262144 bytes (16 x 16kb pages) +CHR => (NONE - "imbedded") + + +[256K - 262144 bytes] +(EX: Super Mario Bros. 2 - 1MBit ROM + 1MBbit VROM) + +PRG => 131072 bytes (8 x 16kb pages) +CHR => 131072 bytes (16 x 8kb pages) + + +[312K - 319488 bytes] +(EX: Bo Jackson Baseball - 1MBit ROM + 1458Kbit VROM) + +PRG => 131072 bytes (8 x 16kb pages) +CHR => 188416 bytes (23 x 8kb pages) + + +[336K - 344064 bytes] +(EX: Spiderman and the Sinister Six - 1MBit ROM + 2048Kbit VROM) + +PRG => 131072 bytes (8 x 16kb pages) +CHR => 212992 bytes (26 x 8kb pages) + + +[384K - 393216 bytes] +(EX: Ikari Warriors 2 - 2MBit ROM + 1MBit "imbedded" VROM) + +PRG => 262144 bytes (16 x 16kb pages) +CHR => (131072 bytes - "imbedded") + + +[384K - 393216 bytes] +(EX: Super Mario Bros. 3 - 2MBit ROM + 1MBit VROM) + +PRG => 262144 bytes (16 x 16kb pages) +CHR => 131072 bytes (16 x 8kb pages) + + +[384K - 393216 bytes] +(EX: Gremlins 2: the New Batch = 1 MBit ROM + 2MBit VROM) + +PRG => 131072 bytes (8 x 16kb pages) +CHR => 262144 bytes (32 x 8kb pages) + + +[512K - 524288 bytes] +(EX: CastleVania III: Dracula's Curse - 2MBit ROM + 2MBit VROM) + +PRG => 262144 bytes (16 x 16kb pages) +CHR => 262144 bytes (32 x 8kb pages) + + +[768K - 786432 bytes] - 1st and ONLY 6MBit NES GAME! +(EX: Kirby's Adventure - 4MBit ROM + 2MBit VROM) + +PRG => 524288 bytes (32 x 16kb pages) +CHR => 262144 bytes (32 x 8kb pages) + + +[1024K - 1048576 bytes] +(EX: Forget Name (Japanese) - 4MBit ROM + 4MBit VROM) + +PRG => 524288 bytes (32 x 16kb pages) +CHR => 524288 bytes (64 x 8kb pages) + + +[1024K - 1048576 bytes] +(EX: 100-in-1 illegal cart - 8Mbit ROM) + +PRG => 1048576 bytes (64 x 16kb pages) +CHR => (NONE - "imbedded") + + +* NOTE: 8MBit (Megabit) is equal to 1 MB (Megabyte). As far as I know from + reading NES technical data the 8MBit/1MB game is the largest game size + supported by the NES as of when it was discontinued in Summer 1994 + with its final game Wario's Woods in the United States. + + +[Sect. 4: - HEXidecimal Values of the PRG/CHR]________________________________ + +[PRG - (Range 1 x 16kb pages -> 64 x 16kb pages)] +-There is a BARE MINIMUM required for PRG which is 1 x 16kb pages! + +* NOTE: To figure out the exact size in bytes each of these pages are worth + just start at 1 x 16kb pages (aka: 16384 bytes) and just keep adding + 16384 more for each "page" higher. + +(1 x 16kb pages) = 01 (2 x 16kb pages) = 02 (3 x 16kb pages) = 03 +(4 x 16kb pages) = 04 (5 x 16kb pages) = 05 (6 x 16kb pages) = 06 +(7 x 16kb pages) = 07 (8 x 16kb pages) = 08 (9 x 16kb pages) = 09 +(10 x 16kb pages) = 0A (11 x 16kb pages) = 0B (12 x 16kb pages) = 0C +(13 x 16kb pages) = 0D (14 x 16kb pages) = 0E (15 x 16kb pages) = 0F +(16 x 16kb pages) = 10 (17 x 16kb pages) = 11 (18 x 16kb pages) = 12 +(19 x 16kb pages) = 13 (20 x 16kb pages) = 14 (21 x 16kb pages) = 15 +(22 x 16kb pages) = 16 (23 x 16kb pages) = 17 (24 x 16kb pages) = 18 +(25 x 16kb pages) = 19 (26 x 16kb pages) = 1A (27 x 16kb pages) = 1B +(28 x 16kb pages) = 1C (29 x 16kb pages) = 1D (30 x 16kb pages) = 1E +(31 x 16kb pages) = 1F (32 x 16kb pages) = 20 (33 x 16kb pages) = 21 +(34 x 16kb pages) = 22 (35 x 16kb pages) = 23 (36 x 16kb pages) = 24 +(37 x 16kb pages) = 25 (38 x 16kb pages) = 26 (39 x 16kb pages) = 27 +(40 x 16kb pages) = 28 (41 x 16kb pages) = 29 (42 x 16kb pages) = 2A +(43 x 16kb pages) = 2B (44 x 16kb pages) = 2C (45 x 16kb pages) = 2D +(46 x 16kb pages) = 2E (47 x 16kb pages) = 2F (48 x 16kb pages) = 30 +(49 x 16kb pages) = 31 (50 x 16kb pages) = 32 (51 x 16kb pages) = 33 +(52 x 16kb pages) = 34 (53 x 16kb pages) = 35 (54 x 16kb pages) = 36 +(55 x 16kb pages) = 37 (56 x 16kb pages) = 38 (57 x 16kb pages) = 39 +(58 x 16kb pages) = 3A (59 x 16kb pages) = 3B (60 x 16kb pages) = 3C +(61 x 16kb pages) = 3D (62 x 16kb pages) = 3E (63 x 16kb pages) = 3F +(64 x 16kb pages) = 40 + +** SPECIAL NOTICE ** There is now DUAL MMC1 Chipset handling avaliable which +pushes the total PRG banking up to 32kb pages via 2 16kb pages PRG chips. + +This was quite a feat performed with the work of imid, EFX, star69, and Marat +Fayzullin to get it to run, and because of this DRAGON WARRIOR III, and other +"like" games now work! This game for instance uses a 32kb banking mode +between two MMC1 chips, and to make them work together they communicate with +each other on the "4th" byte of the game image(not including the iNES header.) + + +[CHR - (Range 1 x 8kb pages -> 64 x 8kb pages)] +-There is NO MINIMUM required for CHR data because some games have the CHR + data imbedded into the PRG info. + +* NOTE: To figure out the exact size in bytes each of these pages are worth + just start at 1 x 8kb pages (aka: 8192 bytes) and just keep adding + 8192 bytes more for each "page" higher. + +(1 x 8kb pages) = 01 (2 x 8kb pages) = 02 (3 x 8kb pages) = 03 +(4 x 8kb pages) = 04 (5 x 8kb pages) = 05 (6 x 8kb pages) = 06 +(7 x 8kb pages) = 07 (8 x 8kb pages) = 08 (9 x 8kb pages) = 09 +(10 x 8kb pages) = 0A (11 x 8kb pages) = 0B (12 x 8kb pages) = 0C +(13 x 8kb pages) = 0D (14 x 8kb pages) = 0E (15 x 8kb pages) = 0F +(16 x 8kb pages) = 10 (17 x 8kb pages) = 11 (18 x 8kb pages) = 12 +(19 x 8kb pages) = 13 (20 x 8kb pages) = 14 (21 x 8kb pages) = 15 +(22 x 8kb pages) = 16 (23 x 8kb pages) = 17 (24 x 8kb pages) = 18 +(25 x 8kb pages) = 19 (26 x 8kb pages) = 1A (27 x 8kb pages) = 1B +(28 x 8kb pages) = 1C (29 x 8kb pages) = 1D (30 x 8kb pages) = 1E +(31 x 8kb pages) = 1F (32 x 8kb pages) = 20 (33 x 8kb pages) = 21 +(34 x 8kb pages) = 22 (35 x 8kb pages) = 23 (36 x 8kb pages) = 24 +(37 x 8kb pages) = 25 (38 x 8kb pages) = 26 (39 x 8kb pages) = 27 +(40 x 8kb pages) = 28 (41 x 8kb pages) = 29 (42 x 8kb pages) = 2A +(43 x 8kb pages) = 2B (44 x 8kb pages) = 2C (45 x 8kb pages) = 2D +(46 x 8kb pages) = 2E (47 x 8kb pages) = 2F (48 x 8kb pages) = 30 +(49 x 8kb pages) = 31 (50 x 8kb pages) = 32 (51 x 8kb pages) = 33 +(52 x 8kb pages) = 34 (53 x 8kb pages) = 35 (54 x 8kb pages) = 36 +(55 x 8kb pages) = 37 (56 x 8kb pages) = 38 (57 x 8kb pages) = 39 +(58 x 8kb pages) = 3A (59 x 8kb pages) = 3B (60 x 8kb pages) = 3C +(61 x 8kb pages) = 3D (62 x 8kb pages) = 3E (63 x 8kb pages) = 3F +(64 x 8kb pages) = 40 + + +[Sect. 5: - Miscellaneous Information on the NES Format]______________________ + +* The End of the CART.NES file ...the Title] + If you wish you can add a title to your NES ROM and below shows you how to + do that manually, and the size limits for that title. + + 1) First at the very end of the ROM you will eventually ADD 128 bytes to the + ROM. But first, which is part of this 128 bytes, is the addition of the + NES Title. Starting at the first added byte type in the name normally in + the character part of the hexeditor. + + 2) Next, to finish this is successfully, go over to the HEXidecimal part of + the HEXeditor and add in double zeros (00) until you have added in a + a TOTAL OF 128 BYTES (which includes the the Title you added yourself.) + (So subtract the total bytes of the title from 128 so you do it right.) + + 3) If you did it right you now have successfully added a title to your NES + ROM and it will show in the title bar in the ROM checkers like NESImage. + + +[Sect. 6: - Let's Get Cracking on Prepping Your RAW/FFE/PasoFami Image]_______ + +* "RAW" Image Conversion to iNES + + 1) For starters check and see if that RAW NES rom image you got is or is not + interleaved. (See #3 if it's interleaved.) + + 2) Great! It's not interleaved so what you need to do is to just add 16 + bytes onto the beginning of this ROM image. Then just add the standard + NES header to the ROM as stated in Section 1, and then toy around with + the mappers until you can or can't get the game to work or do something. + + 3) Crap, it's interleaved, don't worry it's fixable. What you need to do is + to write or find a program that will UN-interleave your ROM. This is the + process of seperating all the even and odd bytes. The even bytes are the + ROM (or PRG) data, and the odd bytes are the VROM (or CHR) data if that + exists. + + 4) Next, in MS-DOS, re-join the PRG and CHR data in the proper order. (Which + is PRG data before CHR data.) First take the split ROM and VROM files and + name them something like PARODIUS.PRG(ROM) and PARODIUS.CHR(VROM)... + (Parodius is a japanese side shooter game I'm using for this description.) + + 5) Now type: copy /B PARODIUS.PRG+PARODIUS.CHR PARODIUS.NES + (This is a BINARY copy mode in DOS which will glue the two files together + where the PRG ends and the CHR begins.) + + 6) Now do as it says in Step #2 and just add the 16byte header to the top of + the NES rom, and then add the NES header as stated in Section 1. + + +* "FFE" Image Conversion to iNES + + 1) To start check and see if the rom is in a standard file format as shown + in Section 3. If it isn't check to see if it is 512 bytes larger than + normal. If so, this is most likely a FFE header. + + 2) To remove this get into your HEXidecimal editor and just have it delete + the first 512 bytes from your NES rom. + + 3) Then just add a 16byte header to the top of the NES rom, and then add the + NES header as stated in Section 1. + + +NOTE: If this rom ends up being interleaved as well just follow the guidelines + set above in the RAW rom format section for UN-interleaving a ROM. + +BE ADVISED that Some NES roms maybe seem to be 512 or 1024 bytes larger than +normal. This is because it either has a trainer, or a combination of a +trainer and a FFE header. My best advice to you is that if its a trainer +leave it, if its a FFE header remove it. If the rom is 1024 bytes its a combo +of both, just remove the first 512 bytes and you'll be ok. + + +* "PasoFami (*.PRG/*.CHR -ONLY-)" Image Conversion + + 1) Start by deleting that annoying PRM file. This file is used by the + PasoFami emulator just as the 16byte header that iNES uses. + + 2) Next is the easy part, a simple binary copy (again I'll use Parodius as + the example.) Type: copy /B PARODIUS.PRG+PARODIUS.CHR PARODIUS.NES + (This is a BINARY copy mode in DOS which will glue the two files together + where the PRG ends and the CHR begins.) + + 3) Now do as it says in Step #2 in the RAW section and just add the 16byte + header to the top of the NES rom, and then add the NES header. + +NOTE: Some PasoFami images such as Super Mario Bros. 2 for example are in the + Famicom Disk System format (EX: SMB2J.DKA) and can't be converted. When + they can be, I'll add that info here. + + +[Sect. 7: - Information (Recommended Tools for Converting iNES Images)]_______ + +* RECOMMENDED TOOLS FOR USE IN THE ABOVE SECTIONS: + +HEXeditor - (ie: Norton Diskedit or Bedit) -I use bedit, it's tiny with lots +of commands, and very efficient. + +READCHAR.EXE - This tool shows you the PRG and CHR data in a RAW, FFE, +PasoFami, and NES file. With this you can determine the correct sizes of the +yet to be determined PRG and CHR pages. Also if you notice that things are +out of order (in a PRG, CHR, PRG, etc) format this will show you that the game +is most likely interleaved. + +UNLACE.EXE - This tool is something I had custom made for me. What this does +is uninterleaves NES roms from the RAW, FFE (removes the trainer by use of +command), and iNES format. What that means is that it splits up to rom and +puts all the PRG data in one file called (ROM) and all the CHR data in a file +called (VROM). And as my manual says above you just got to binary copy them +back into one file ROM+VROM = NES rom. Then add the iNES header and you just +tinker with it until it works, that's if its supported yet. + +Also to save time, I do recommend the use of DiskDude's NESimage from version +3.30+ because it can show you in its menu all the PRG and CHR sizes, as well +as all the other options avaliable to you. This is just for people that don't +want to hexedit their rom and just want to get it working right away... +impacient aren't you? :) + +NESFIX.EXE - If you do use a crummy editor like DiskDude's NES Image remember +to clean out bytes 8->15 so games will work in Exteneded iNES Header format +compatible emulators. To do this find and use NESFIX, and just run it like +so... NESFIX CART.NES and it will clean out the extra data. Not only that +this will save time in that it takes a fraction of the time to do it one by +one manually. + +And finally I recommend you have a NES emulator that is as far along in +development, or farther, than iNES, and a few smaller sized games to study +with in conjunction with my text. + + +[Sect. 8: - UPDATES (The History of the iNES Header/Format Documentation)]____ + +* UPDATE INFORMATION: + +[2.0] - Wow v2.0! "SHOW ME THE MUSHROOM!" - Toad McGuire ...More mappers! =) + +- In Sections 1-8 I reformatted some text and removed useless info. +- In Section 1 added a snipit on what byte 7 does in conjunction with byte 6 + and explained that 7 = Tens digit and 6 = ones digit for the 16+ mappers. + And fixed the chart so that 0 is the beginning digit, not 1. Stupid error. +- In Section 2 I added a notice about NESFIX so people can easily repair there + polluted headers so they will work in Extened iNES Header format players. +- Added in Section 2 the all important further extension to the Extended iNES + Header format created by FanWen. Mappers 66-70 80-84 are now added, and a + rename to the Konami VRC 2 1a and 1b to VRC 1b and 1a. +- Reformatted the CHR and PRG cart size lists to fit into 1 screen in Section + 2 as well. +- And in Section 7 I added the recommended tool of NESFIX.EXE to remove that + nasty garbage out of iNES headers. +- More BS errors in grammar and spelling fixed again. Common occurance is it + not? >:) Maybe I need to buy Hookt awn Fawniks and Lurn too Reed. =) +- In this Section 8 it got to damned big so now I'm limiting the list to the + three most current revisions for now on. (Like anyone really looks back to + read that stuff anyways, the important stuff is above.) + +[1.9] - *SMB Fanfare please..doo doo doo, dee doo, doo, doo ..iNES 0.7 is out! + +- Added to Section 1 notice of basically where the new Extended iNES format is + layed out and called from, and an "I TODL YOU SO NOTICE." >:] +- Added to Section 2 a new MAPPER chart for all the new iNES mappers that are + in iNES v0.7. +- Added to Section 2 the explanation and example of how the new iNES Extended + Header format works and is used. +- Added to Section 2 new MAPPER chart notice that the MMC5 chipset is now + emulated 100%, I checked CastleVania III and it ran perfectly! Also the + MAPPERs 1 and 4 work near 100% now, the bugs are fixed! +- Added to Section 2 new MAPPER chart notice that the MMC1 and MMC3 chipset + emulation has been bugfixed, therefore more games run that didn't before. +- Added to Section 2 Instructions on how to "clean" up games that won't work + in the new "Extended iNES v0.7 Format" because some people felt it smart to + litter the games with there name, etc. into the header, thanks jerkoffs. +- Added to Section 3 for "Stinger aka: Twin Bee 2", yet another cart size. +- Added to Section 3 a little more info to the cart sizes with imbedded CHR. +- Added to Section 4 sketchy info on why Dragon Warrior III and other 32kb + banking mode games are now playable in iNES v0.7 format. +- Changed out two quotes, added two more appropriate ones. +- Fixed a few text errors again, sorry I usually type this late at night. + +[1.8] - A new attitude... Another addition/fix again! Screw iNES NESticle me! + +- Added to Section 1 a warning about filling up the 8th through 16th byte in + an iNES compatible ROM set. +- Added to Section 2 NEW Mapper info which is that Mapper 7 and the long + awaited Mapper 9(MMC2 chip for Punch-Out!! is now functional. +- Added and rewrote Section 2's working mappers list for the latest players. +- Added to Section 3 a few new cart sizes so look up Dragon Warrior, Tetris 2, + and Mad Max. +- Fixed this list to no longer support iNES, now all compatibility for all the + latest players is dated. (IE: June 12, 1997) +- A small personal thanks section at the top of the list. +- Again I have fixed a few grammatical/spelling errors, yah I know not again. + +[End Of File] -Enjoy! + diff --git a/nes_technical_documentation.txt b/nes_technical_documentation.txt new file mode 100755 index 0000000..f47882a --- /dev/null +++ b/nes_technical_documentation.txt @@ -0,0 +1,1482 @@ ++---------------------------------------------+ +| Nintendo Entertainment System Documentation | +| | +| Version: 2.00 | ++---------------------------------------------+ + ++-------------------+ +| Table of Contents | ++-------------------+ + + 1. Introduction + A. Disclaimer + B. Why? + C. Mission + D. Dedications + E. "Thank You"s + 2. Acronymns + A. Internals + B. Hardware + 3. CPU + A. General Information + B. Memory Map + C. Interrupts + D. NES-specific Customizations + E. Notes + 4. PPU + A. General Information + B. PPU Map + C. Name Tables + D. Pattern Tables + E. Attribute Tables + F. Palettes + G. Name Table Mirroring + H. Palette Mirroring + I. Background Scrolling + J. Screen and Sprite Layering + K. Sprites and SPR-RAM + L. Sprite #0 Hit Flag + M. Horizontal and Vertical Blanking + N. $2005/2006 Magic + O. VRAM Read/Writes + P. Notes + 5. pAPU + 6. Joypads, paddles, expansion ports + 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. Expansion ports + I. Notes + 7. Memory Mapping Hardware + 8. Registers + 9. File Formats + A. iNES Format (.NES) + 10. Programming the NES + A. General Information + B. CPU Notes + C. PPU Notes + 11. Emulation + A. General Information + B. CPU Notes + C. PPU Notes + D. APU Notes + 12. Reference Material + A. CPU Information + B. PPU Information + C. APU Information + D. Memory Mapper Information + E. Mailing Lists + F. WWW Sites + G. Hardware Information + + + ++-----------------+ +| 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 up-to- + date information regarding the Nintendo Entertainment System, and it's + Famicom counterpart. + + + 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. + + Alex Krasivsky - bcat@lapkin.rosprint.ru + Andrew Davie + Avatar Z - swahlen@nfinity.com + Barubary - barubary@mailexcite.com + Bluefoot - danmcc@injersey.com + CiXeL + Chi-Wen Yang - yangfanw@ms4.hinet.net + Chris Hickman - typhoonz@parodius.com + D - slf05@cc.usu.edu + Dan Boris - dan.boris@coat.com + David de Regt - akilla@earthlink.net + Donald Moore - moore@futureone.com + Fredrik Olsson - flubba@hem2.passagen.se + Icer Addis - bldlust@maelstrom.net + Jon Merkel - jpm5974@omega.uta.edu + Kevin Horton - khorton@iquest.net + Loopy - zxcvzxcv@netzero.net + Marat Fayzullin - fms@cs.umd.edu + Mark Knibbs - mark_k@iname.com + Martin Nielsen - mnielsen@get2net.dk + Matt Conte - itsbroke@classicgaming.com + Matthew Richey - mr6v@andrew.cmu.edu + Memblers - 5010.0951@tcon.net + MiKael Iushin - acc@tulatelecom.ru + Mike Perry - mj-perry@uiuc.edu + Morgan Johansson - morgan.johansson@mbox301.swipnet.se + Neill Corlett - corlett@elwha.nrrc.ncsu.edu + Pat Mccomack - splat@primenet.com + Patrik Alexandersson - patrikus@hem2.passagen.se + Paul Robson - AutismUK@aol.com + Ryan Auge - rauge@hay.net + Stumble - stumble@alpha.pulsar.net + Tennessee Carmel-Veilleux - veilleux@ameth.org + Thomas Steen - Thomas.Steen@no.jotankers.com + Tony Young - KBAAA@aol.com + Vince Indriolo - indriolo@nm.picker.com + \FireBug\ - lavos999@aol.com + + Special thanks goes out to Stumble, for providing a myriad of infor- + mation over IRC, while avoiding sleep to do so. + + ++--------------+ +| 2. Acronymns | ++--------------+ + + A. Internals + ------------ + 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: Native to the CPU; generates + waveforms via (5) audio channels:: four (4) analogue, and + one (1) digital. There is no physical IC for audio process- + ing nor generation inside the NES. + 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. + Dandy - Synonymous (hardware-wise) with the Famicom. + Famicom - Synonymous with the NES, except for not supporting the RAW + method of DMC digital audio playback. + FDS - Famicom Disk System: Unit which sits atop the Famicom, support- + ing the use of 3" double-sided floppy disks for games. + + + ++--------+ +| 3. CPU | ++--------+ + + A. General Information + ---------------------- + The NES uses a customized NMOS 6502 CPU, engineered and produced by + Ricoh. It's primary customization adds audio. + + The NTSC NES runs at 1.7897725MHz, and 1.773447MHz for PAL. + + + 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 | $20 | | Registers | + | $4020 | $1FDF | | Expansion ROM | + | $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.) + + + 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 under two circumstances, hence it's split name: + when a software IRQ is executed (the BRK instruction), or when a + hardware IRQ is executed (via the IRQ line). + + 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" title. + These carts return from interrupts in a very odd fashion: by manipul- + ating the stack by hand, and then doing an RTS. This is technically + valid, but morally shunned. + + The aforementioned nterrupts have the following vector addresses, + mapped to areas of ROM: + + $FFFA = NMI + $FFFC = RESET + $FFFE = IRQ/BRK + + Interrupt priorities are as follows: + + Highest = RESET + NMI + Lowest = IRQ/BRK + + + D. NES-specific Customizations + ------------------------------ + The NES's 6502 does not contain support for decimal mode. Both the + CLD and SED opcodes function normally, but the 'd' bit of P is unused + in both ADC and SBC. It is common practice for games to CLD prior to + code execution, as the status of 'd' is unknown on power-on and on + reset. + + Audio registers are mapped internal to the CPU; all waveform gener- + ation is done internal to the CPU as well. + + + E. 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. + + When a BRK is encountered, the NES's 6502 pushes the CPU status flag + onto the stack with the 'b' CPU bit set. On an IRQ or NMI, the CPU + pushes the status flag onto the stack with the 'b' bit clear. This is + done because of the fact that a hardware IRQ (IRQ) and a software + IRQ (BRK) both share the same vector. For example, one could use the + following code to distinguish the difference between the two: + + C134: PLA ; Copy CPU status flag + C135: PHA ; Return status flag to stack + C136: AND #$10 ; Check D4 ('b' CPU bit) + C138: BNE is_BRK_opcode ; If set then it is a software IRQ (BRK) + + Executing BRK inside of NMI will result in the pushed 'b' bit being + set. + + 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: + + C100: 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. + + It should be noted that page wrapping does *NOT* occur in indexed- + indirect addressing modes. Due to limitations of zero-page, all + indexed-indirect read/writes should apply a logical AND #$FF to + the effective address after calculation. Example: + + C000: LDX #3 ; Reads indirect address from $0002+$0003, + C002: LDA ($FF,X) ; not $0102+$0103. + + + ++--------+ +| 4. PPU | ++--------+ + + A. General Information + ---------------------- + Mirroring (also referred to as "shadowing") is the process of mapping + particular addresses or address ranges to other addresses/ranges via + hardware. + + + B. Memory Map + ------------- + Included here are two (2) memory maps. The first is a "RAM Memory + Map," which despite being less verbose describes the actual regions + which point to physical RAM in the NES itself. The second is a + "Programmer Memory Map" which is quite verbose and describes the + entire memory region of the NES and how it's used/manipulated. + + RAM Memory Map + +---------+-------+--------------------+ + | Address | Size | Description | + +---------+-------+--------------------+ + | $0000 | $1000 | Pattern Table #0 | + | $1000 | $1000 | Pattern Table #1 | + | $2000 | $800 | Name Tables | + | $3F00 | $20 | Palettes | + +---------+-------+--------------------+ + + + Programmer 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 | N | Attribute Table #0 | + | $2400 | $3C0 | N | Name Table #1 | + | $27C0 | $40 | N | Attribute Table #1 | + | $2800 | $3C0 | N | Name Table #2 | + | $2BC0 | $40 | N | Attribute Table #2 | + | $2C00 | $3C0 | N | Name Table #3 | + | $2FC0 | $40 | N | Attribute Table #3 | + | $3000 | $F00 | R | | + | $3F00 | $10 | | Image Palette #1 | + | $3F10 | $10 | | Sprite Palette #1 | + | $3F20 | $E0 | P | | + | $4000 | $C000 | F | | + +---------+-------+-------+--------------------+ + C = Possibly CHR-ROM + N = Mirrored (see Subsection G) + P = Mirrored (see Subsection H) + R = Mirror of $2000-2EFF (VRAM) + F = Mirror of $0000-3FFF (VRAM) + + + 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. + + 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 + ------------------- + 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 is: + + * 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. + + D7-D6 of bytes written to $3F00-3FFF are ignored. + + + G. Name Table Mirroring + ----------------------- + One should keep in mind that there are many forms of mirroring when + understanding the NES. Some methods even use CHR-ROM-mapped Name + Tables (mapper-specific). + + The NES itself only contains 2048 ($800) bytes of RAM used for Name + Tables. However, as shown in Subsection B, the NES has the capability + of addressing up to four (4) Name Tables. + + By default, many carts come with "horizontal" and "vertical" mirroring, + allowing you to change where the Name Tables point into the NES's PPU + RAM. This form of mirroring affects two (2) Name Tables simultaneously; + you cannot switch Name Tables independently. + + The following chart should assist in understanding all the types of + mirroring encountered on the NES. Please note that the addresses + shown (12-bit in size) refer to the Name Table portion of the NES's + PPU RAM; one may consider these synonymous with "$2xxx" in the VRAM + region: + + Name NT#0 NT#1 NT#2 NT#3 Flags + +--------------------------+------+------+------+------+-------+ + | Horizontal | $000 | $000 | $400 | $400 | | + | Vertical | $000 | $400 | $000 | $400 | | + | Four-screen | $000 | $400 | $800 | $C00 | F | + | Single-screen | | | | | S | + | CHR-ROM mirroring | | | | | C | + +--------------------------+------+------+------+------+-------+ + F = Four-screen mirroring relies on an extra 2048 ($800) of RAM + (kept on the cart), resulting in four (4) physical independent + Name Tables. + S = Single-screen games have mappers which allow you to select + which PPU RAM area you want to use ($000, $400, $800, or + $C00); all the NTs point to the same PPU RAM address. + C = Mapper #68 (Afterburner 2) allows you to map CHR-ROM to the + Name Table region of the NES's PPU RAM area. Naturally this + makes the Name Table ROM-based, and one cannot write to it. + However, this feature can be controlled via the mapper itself, + allowing you to enable or disable this feature. + + + H. Palette Mirroring + -------------------- + Mirroring occurs between the Image Palette and the Sprite Palette. + Any data which is written to $3F00 is mirrored to $3F10. Any data + written to $3F04 is mirrored to $3F14, etc. etc... + + Colour #0 in the upper three (3) palettes of both the Image and Sprite + palette defines transparency (the actual colour stored there is not + drawn on-screen). + + The PPU uses the value in $3F00 to define background colour. + + For a more verbose explanation, assume the following: + + * $0D has been written to $3F00 (mirrored to $3F10) + * $03 has been written to $3F08 (mirrored to $3F18) + * $1A has been written to $3F18 + * $3F08 is read into the accumulator + + The PPU will use $0D as the background colour, despite $3F08 holding + a value of $03 (since colour #0 in all the palette entries defines + transparency, it is not drawn). Finally, the accumulator will hold + a value of $1A, which is mirrored from $3F18. Again, the value of $1A + is not drawn, since colour #0 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. + + D7-D6 of bytes written to $3F00-3FFF are ignored. + + + 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 D1-D0 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) | + +---------------+---------------+ + + Writes to the Horizontal Scroll value in $2005 range from 0 to 256. + Writes to the Vertical Scroll value range from 0-239; values above 239 + are considered negative (e.g. a write of 248 is really -8). + + + J. Screen and Sprite Layering + ----------------------------- + There is a particular order in which the NES draws it's contents: + + FRONT BACK + +----+-----------+----+-----------+-----+ + | CI | OBJs 0-63 | BG | OBJs 0-63 | EXT | + +----+-----------+----+-----------+-----+ + | SPR-RAM | | SPR-RAM | + | BGPRI==0 | | BGPRI==1 | + +-----------+ +-----------+ + + CI stands for 'Colour Intensity', which is synonmous with D7-D5 of + $2001. BG is the BackGround, and EXT is for the EXTension port video + signal. + + 'BGPRI' represents the 'Background Priority' bit in SPR-RAM, on a + per-sprite basis (D5, Byte 2). + + OBJ numbers represent actual Sprite numbers, not Tile Index values. + + FRONT is considered what is seen atop all other layers (drawn last), + and BACK is deemed what is below most other layers (drawn first). + + + K. 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 has an even-numbered Tile Index # use the Pattern + Table at $0000 in VRAM; odd-numbered Tile Index #s use $1000. + *NOTE*: Register $2000 has no effect on 8x16 sprites. + + All 64 sprites contain an internal priority; sprite #0 is of a higher + priority than sprites #63 (sprite #0 should be drawn last, etc.). + + 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). + + (NOTE: On a real NES unit, if sprites are disabled (D4 of $2001 is 0) + for a long period of time, SPR-RAM will gradually degrade. A proposed + concept is that SPR-RAM is actually DRAM, and D4 controls the DRAM + refresh cycle). + + + L. Sprite #0 Hit Flag + --------------------- + The PPU is capable of figuring out where Sprite #0 is, and stores + it's findings in D6 of $2002. The way this works is as follows: + + The PPU scans for the first actual non-transparent "sprite pixel" and + the first non-transparent "background pixel." A "background pixel" is + a tile which is in use by the Name Table. Remember that colour #0 + defines transparency. + + The pixel which causes D6 to be set *IS* drawn. + + The following example should help. The following are two tiles. + Transparent colours (colour #0) are defined via the underscore ('_') + character. An asterisk ('*') represents when D6 will be set. + + Sprite BG Result + ------ -- ------ + __1111__ ________ __1111__ + _111111_ _______2 _1111112 + 11222211 ______21 11222211 + 112__211 + _____211 = 112__*11 '*' will be drawn as colour #2 + 112__211 ____2111 112_2211 + 11222211 ___21111 11222211 + _111111_ __211111 _1111111 + __1111__ _2111111 _2111111 + + This also applies to sprites that are underneathe the BG (via the + 'Background Priority' SPR-RAM bit), though the above example would + be 'BG+Sprite'. + + Also, D6 is cleared (set to 0) after each VBlank. + + + M. 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 + +--------+ 243 --+ + | | | + | VBlank | +-- (243-262) VBlank + | | | + +--------+ 262 --+ + + The Vertical Blank (VBlank) flag is contained in D7 of $2002. It + indicates whether PPU is in VBlank or not. A program can reset D7 by + reading $2002. + + + N. $2005/2006 Magic + ------------------- + For detailed information pertaining to the $2005 and $2006 registers, + refer to Loopy's $2005/2006 document. His document provides entirely + accurate information regarding how these registers work. Contact + Loopy for more information. + + + O. PPU Quirks + ------------- + The first read from VRAM is invalid. Due to this aspect, the NES will + returned pseudo-buffered values from VRAM rather than linear as expec- + ted. See the below example: + + VRAM $2000 contains $AA $BB $CC $DD. + VRAM incrementation value is 1. + The result of execution is printed in the comment field. + + LDA #$20 + STA $2006 + LDA #$00 + STA $2006 ; VRAM address now set at $2000 + LDA $2007 ; A=?? VRAM Buffer=$AA + LDA $2007 ; A=$AA VRAM Buffer=$BB + LDA $2007 ; A=$BB VRAM Buffer=$CC + LDA #$20 + STA $2006 + LDA #$00 + STA $2006 ; VRAM address now set at $2000 + LDA $2007 ; A=$CC VRAM Buffer=$AA + LDA $2007 ; A=$AA VRAM Buffer=$BB + + As shown, the PPU will post-increment it's internal address data after + the first read is performed. This *ONLY APPLIES* to VRAM $0000-3EFF + (e.g. Palette data and their respective mirrors do not suffer from + this phenomenon). + + + P. Notes + -------- + The PPU will auto-increment the VRAM address by 1 or 32 (based on D2 + of $2000) after accessing $2007. + + + ++---------+ +| 5. pAPU | ++---------+ + To be written. Prior information was inaccurate or incorrect. No one + has 100% accurate sound information at this time. This section will + be completed when someone decides to reverse engineer the pAPU section + of the NES, and provide me with information (or a reference to infor- + mation). + + + ++--------------------------------------+ +| 6. Joypads, paddles, expansion ports | ++--------------------------------------+ + + A. General Information + ---------------------- + The NES supports a myriad of input devices, including joypads, Zappers + (light guns), and four-player devices. + + Joypad #1 and #2 are accessed via $4016 and $4017, respectively. + + The joypads are reset via a strobing-method: writing 1, then 0, to + $4016. See Subsection H for information regarding "half-strobing." + + On a full strobe, the joypad's button status will be returned in a + single-bit stream (D0). 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 + ------------- + The Zapper (otherwise known as the "Light Gun") simply uses bits + within $4016 and $4017, described in Section 8. See bits D4, D3, and + D0. + + It is possible to have two Zapper units connected to both joypad + ports simultaneously. + + + 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 D0 of $4016 or + $4017, as Subsection A states. + + 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 D1 of $4017; the read data is inverted + (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 D1 of $4016. A + value of 1 specifies that the button is 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. Expansion ports + ------------------ + The joypad strobing process requires dual writes: 1, then 0. If the + strobing process is not completed, or occurs in a non-standard order, + the joypads are no longer the item of communication: the expansion + port is. + + For NES users, the expansion port is located on the bottom of the unit, + covered by a small grey piece of plastic. Famicom users have a limited + expansion port on the front of their unit, which was commonly used for + joypads or turbo-joypads. + + Such an example of communicating with the expansion port would be the + following code: + + LDA #%00000001 + STA $4016 + STA $4017 ; Begin read mode of expansion port + LDA #%00000011 ; Write %110 to the expansion port + STA $4016 + + I have yet to encounter a cart which actually uses this method of + communication. + + + I. 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 16 = 16-bit register + + NOTE: 16-bit registers actually consist of two linear 8-bit registers, + which can (and will be) *INDEPENDANTLY* assigned. The reason for + specifying them as 16-bit is for ease of documentation. For + instance, "$4002+$4003" would mean that D15-D8 would be in $4003, + and D7-D0 would be in $4002. + NOTE: Bits not listed are to be considered unused. + + +---------+----------------------------------------------------------+ + | Address | Description | + +---------+----------------------------------------------------------+ + | $2000 | PPU Control Register #1 (W) | + | | | + | | D7: Execute NMI on VBlank | + | | 0 = Disabled | + | | 1 = Enabled | + | | D6: PPU Master/Slave Selection --+ | + | | 0 = Master +-- UNUSED | + | | 1 = Slave --+ | + | | D5: Sprite Size | + | | 0 = 8x8 | + | | 1 = 8x16 | + | | D4: Background Pattern Table Address | + | | 0 = $0000 (VRAM) | + | | 1 = $1000 (VRAM) | + | | D3: Sprite Pattern Table Address | + | | 0 = $0000 (VRAM) | + | | 1 = $1000 (VRAM) | + | | D2: PPU Address Increment | + | | 0 = Increment by 1 | + | | 1 = Increment by 32 | + | | D1-D0: Name Table Address | + | | 00 = $2000 (VRAM) | + | | 01 = $2400 (VRAM) | + | | 10 = $2800 (VRAM) | + | | 11 = $2C00 (VRAM) | + +---------+----------------------------------------------------------+ + | $2001 | PPU Control Register #2 (W) | + | | | + | | D7-D5: Full Background Colour (when D0 == 1) | + | | 000 = None +------------+ | + | | 001 = Green | NOTE: Do not use more | + | | 010 = Blue | than one type | + | | 100 = Red +------------+ | + | | D7-D5: Colour Intensity (when D0 == 0) | + | | 000 = None +--+ | + | | 001 = Intensify green | NOTE: Do not use more | + | | 010 = Intensify blue | than one type | + | | 100 = Intensify red +--+ | + | | D4: Sprite Visibility | + | | 0 = Sprites not displayed | + | | 1 = Sprites visible | + | | D3: Background Visibility | + | | 0 = Background not displayed | + | | 1 = Background visible | + | | D2: Sprite Clipping | + | | 0 = Sprites invisible in left 8-pixel column | + | | 1 = No clipping | + | | D1: Background Clipping | + | | 0 = BG invisible in left 8-pixel column | + | | 1 = No clipping | + | | D0: Display Type | + | | 0 = Colour display | + | | 1 = Monochrome display | + +---------+----------------------------------------------------------+ + | $2002 | PPU Status Register (R) | + | | | + | | D7: VBlank Occurance | + | | 0 = Not occuring | + | | 1 = In VBlank | + | | D6: Sprite #0 Occurance | + | | 0 = Sprite #0 not found | + | | 1 = PPU has hit Sprite #0 | + | | D5: Scanline Sprite Count | + | | 0 = Eight (8) sprites or less on current scan- | + | | line | + | | 1 = More than 8 sprites on current scanline | + | | D4: VRAM Write Flag | + | | 0 = Writes to VRAM are respected | + | | 1 = Writes to VRAM are ignored | + | | | + | | NOTE: D7 is set to 0 after read occurs. | + | | NOTE: After a read occurs, $2005 is reset, hence the | + | | next write to $2005 will be Horizontal. | + | | NOTE: After a read occurs, $2006 is reset, hence the | + | | next write to $2006 will be the high byte portion. | + | | | + | | For detailed information regarding D6, see Section 4, | + | | Subsection L. | + +---------+----------------------------------------------------------+ + | $2003 | SPR-RAM Address Register (W) | + | | | + | | D7-D0: 8-bit address in SPR-RAM to access via $2004. | + +---------+----------------------------------------------------------+ + | $2004 | SPR-RAM I/O Register (W) | + | | | + | | D7-D0: 8-bit data written to SPR-RAM. | + +---------+----------------------------------------------------------+ + | $2005 | VRAM Address Register #1 (W2) | + | | | + | | Commonly used used to "pan/scroll" the screen (sprites | + | | excluded) horizontally and vertically. However, there | + | | is no actual panning hardware inside the NES. This | + | | register controls VRAM addressing lines. | + | | | + | | Refer to Section 4, Subsection N, for more information. | + +---------+----------------------------------------------------------+ + | $2006 | VRAM Address Register #2 (W2) | + | | | + | | Commonly used to specify the 16-bit address in VRAM to | + | | access via $2007. However, this register controls VRAM | + | | addressing bits, and therefore should be used with | + | | knowledge of how it works, and when it works. | + | | | + | | Refer to Section 4, Subsection N, for more information. | + +---------+----------------------------------------------------------+ + | $2007 | VRAM I/O Register (RW) | + | | | + | | D7-D0: 8-bit data read/written from/to VRAM. | + +---------+----------------------------------------------------------+ + | $4000 | pAPU Pulse #1 Control Register (W) | + | $4001 | pAPU Pulse #1 Ramp Control Register (W) | + | $4002 | pAPU Pulse #1 Fine Tune (FT) Register (W) | + | $4003 | pAPU Pulse #1 Coarse Tune (CT) Register (W) | + | $4004 | pAPU Pulse #2 Control Register (W) | + | $4005 | pAPU Pulse #2 Ramp Control Register (W) | + | $4006 | pAPU Pulse #2 Fine Tune Register (W) | + | $4007 | pAPU Pulse #2 Coarse Tune Register (W) | + | $4008 | pAPU Triangle Control Register #1 (W) | + | $4009 | pAPU Triangle Control Register #2 (?) | + | $400A | pAPU Triangle Frequency Register #1 (W) | + | $400B | pAPU Triangle Frequency Register #2 (W) | + | $400C | pAPU Noise Control Register #1 (W) | + | $400D | Unused (???) | + | $400E | pAPU Noise Frequency Register #1 (W) | + | $400F | pAPU Noise Frequency Register #2 (W) | + | $4010 | pAPU Delta Modulation Control Register (W) | + | $4011 | pAPU Delta Modulation D/A Register (W) | + | $4012 | pAPU Delta Modulation Address Register (W) | + | $4013 | pAPU Delta Modulation Data Length Register (W) | + +---------+----------------------------------------------------------+ + | $4014 | Sprite 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 Sound/Vertical Clock Signal Register (R) | + | | | + | | D6: Vertical Clock Signal IRQ Availability | + | | 0 = One (1) frame occuring, hence IRQ cannot | + | | occur | + | | 1 = One (1) frame is being interrupted via IRQ | + | | D4: Delta Modulation | + | | D3: Noise | + | | D2: Triangle | + | | D1: Pulse #2 | + | | D0: Pulse #1 | + | | 0 = Not in use | + | | 1 = In use | + | +----------------------------------------------------------+ + | | pAPU Channel Control (W) | + | | | + | | D4: Delta Modulation | + | | D3: Noise | + | | D2: Triangle | + | | D1: Pulse #2 | + | | D0: Pulse #1 | + | | 0 = Channel disabled | + | | 1 = Channel enabled | + +---------+----------------------------------------------------------+ + | $4016 | Joypad #1 (RW) | + | | | + | | READING: | + | | D4: Zapper Trigger | + | | 0 = Pulled | + | | 1 = Released (not held) | + | | D3: Zapper Sprite Detection | + | | 0 = Sprite not in position | + | | 1 = Sprite in front of cross-hair | + | | D0: Joypad Data | + | +----------------------------------------------------------+ + | | WRITING: | + | | Joypad Strobe (W) | + | | | + | | D0: Joypad Strobe | + | | 0 = Clear joypad strobe | + | | 1 = Reset joypad strobe | + | +----------------------------------------------------------+ + | | WRITING: | + | | Expansion Port Latch (W) | + | | | + | | D0: Expansion Port Method | + | | 0 = Write | + | | 1 = Read | + +---------+----------------------------------------------------------+ + | $4017 | Joypad #2/SOFTCLK (RW) | + | | | + | | READING: | + | | D7: Vertical Clock Signal (External) | + | | 0 = Not occuring | + | | 1 = Occuring | + | | D6: Vertical Clock Signal (Internal) | + | | 0 = Occuring (D6 of $4016 affected) | + | | 1 = Not occuring (D6 of $4016 untouchable) | + | | D4: Zapper Trigger | + | | 0 = Pulled | + | | 1 = Released (not held) | + | | D3: Zapper Sprite Detection | + | | 0 = Sprite not in position | + | | 1 = Sprite in front of cross-hair | + | | D0: Joypad Data | + | +----------------------------------------------------------+ + | | WRITING: | + | | Expansion Port Latch (W) | + | | | + | | D0: Expansion Port Method | + | | 0 = ??? | + | | 1 = Read | + +---------+----------------------------------------------------------+ + + + ++-----------------+ +| 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 mirroring | + | | | | | | + | | | +--+----- 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 page. | + | ..-EOF | | CHR-ROM pages (in ascending order). | + +--------+------+------------------------------------------+ + + + ++-------------------------+ +| 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 consists of a multi-step process: + + 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 $2007 (invalid data once) + 5) Read data from $2007 + + NOTE: Step #4 when reading VRAM is only necessary when reading + VRAM data not in the $3F00-3FFF range. + + NOTE: Accessing VRAM should only be performed during VBlank. Attempts + to access VRAM outside of VBlank will usually result in garbage + showing up on the screen. See Section 4, Subsection N for more + information regarding why this occurs. + + Waiting for VBlank is quite simple: + + 8000: LDA $2002 + BPL $8000 + + Reading $2002 will result in all bits being returned; however, D7 + will be reset to 0 after the read is performed. + + 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. + + Be sure to clear the internal VRAM address via $2006 semi-often. You + will often encounter a situation where a palette fade or a VRAM update + will cause the screen "to be trashed" (squares on the screen, or what + seem to be graphical "glitches"). The reason for this is that your code + took longer than a VBlank. When the VBlank goes to refresh the screen + with the data in the PPU, it takes whatever value is in the internal + VRAM address and uses that as the starting base for Name Table #0. + The solution is to fix your code by re-assigning the VRAM address to + $0000 (or $2000), so that the refresh may occur successfully. Such + code would be: + + LDA #$00 + STA $2006 + STA $2006 + + You will find code like this in commercial games quite often. + + + ++---------------+ +| 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. + + When SRAM ($6000-7FFF) is disabled, writes to the memory area should + be ignored. Reads will possibly return data previously left on the + bus, and therefore when emulated should return 0 (or should be trap- + ped). + + RAM-based memory areas ($0000-07FF) should *NOT* be zeroed on RESET; + they should be zeroed on power on/off. (Technically, the RAM is not + zeroed on power on/off either: the RAM will slowly dissapate over + time when the unit it off. However, for emulation purposes, please + make sure that a cold boot and a warm boot do different things). + + See Section 12, Subsection E for Mailing List information. + + + B. CPU Notes + ------------ + The NES does not use a 65c02 (CMOS) CPU as rumored. + + Ignore opcodes which are bad (or support the option of trapping them). + Some ROM images out there, such as "Adventures of Lolo" contain bad + opcodes, due to dirty connectors on the cartridge during the extract- + ion process (or other reasons). + + There are 154 valid opcodes (out of 256 total) on the NES. + + + 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. + + + D. APU Notes + ------------ + To be written. + + + ++------------------------+ +| 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. + + + F. WWW Sites + ------------ + The following are a list of WWW sites which contain NES-oriented + material. If you encounter errors, bad links, or other anomolies + while visiting these sites, contact the site authors/owners, NOT + me. Thanks. + + http://nesdev.parodius.com/ + + Contains a verbose amount of documentation regarding anything + NES-oriented, including hard-to-find mapper documentation. Seems + to be a decent NES information depository. + + http://www.ameth.org/~veilleux/NES_info.html + + Currently only contains hardware-oriented material, such as + overviews of cart and unit ASICs, mappers, and MMCs. Many + pinout diagrams for mappers and NES units are available here. + Also provides documentation on NES repair, modifying your NES + to give stereo output, applying stereo mixing to your NES, and + much much more. + + + G. Hardware Information + ----------------------- + The following security bits may be purchased from MCM Electronics + (http://www.mcmelectronics.com/): + + For NES carts: 22-1145 (3.8mm security bit) + For NES units: 22-1150 (4.5mm security bit) + + The 4.5mm security screw is also used for the Super Nintendo Enter- + tainment System (SNES), and Nintendo 64. + + diff --git a/source/Makefile b/source/Makefile index 3f1d645..d5a878d 100644 --- a/source/Makefile +++ b/source/Makefile @@ -40,3 +40,7 @@ nes.o : nes.h $(TARGNES) : $(OBJS) $(CC) -o $(TARGNES) $(OBJS) + + +install: all + cp -f $(TARGNES) /usr/local/bin