+read rom
+divvy shit
+-shadow shit
-c o l o r s




+++++read opcode
----C H E C K   R EA D   M O D ES
----OVERLOAD memory operators?
----MIRROR WrItInG(Da Vinci)!!

-----PPU
----PPU increment(bit 2 of register 0 decides whether its hor or ver)
-scanlines
-palette



N O T E S:
-ROMs aren't emulated!
-mirror mirror on the wall, how the heck can you mirror them all?
//-PPU control registers
-imagine creating an OS to run a windows game.
-how can you use mirroring when you have so little memory(misleading name mayhaps)?
-the flags are a single byte register that can be pushed and popped at will.
-in bit representations a bit location is more important than the final result. meaning that comparing bit 7 is NOT the same as checking for a negative number, because some types are wider than 8 bits.
-the 6502 is one of those processors that have been widely used. apple, c64, nes...etc.
-one of the things that many documents fail to mention is that flags need to be unset if the condition is not met.
*maybe the stack elements are forever!
-do not trust a single reference(http://www.c64-wiki.com/index.php/LSR says that the flags are set unconditionally, but they aren't).
-shifting works on values not bits(-2 >> 1 = -1 NOT 65). or rather, shifting is all SIGNED number based(seeing as how java doesn't officially support unsigned numbers to begin with).
-many functions and pointers support wraparound that should also be simulated(i.e. ADDRESS_INDIRECT_X)
-there's a big difference between getting memory for reading or writing(MODE/ADDRESS).
-don't forget the bitmask widths(0xFF for byte, 0xFFFF for short...etc).
-the nes uses incomplete(partial) address decoding, which is cheaper but results in mirroring.
-nes cartridges contain ATLEAST one PRG and one CHR chips.
-alot of the ppu registers are changed by just reading them(clearing or setting a bit).
-because of the way code is compiled, alot of roms might run with without 100% emulation.
-accessing 0x2007(PPUDATA) will increment the pointer.
-DMA(0x4014) works by simply copying the page whose value we just gave to memory. 64K has 256 pages of 256bytes.
-the game "super car" uses 2003/2004 instead of 4014 dma.
*some roms dont have chr-rom or chr-ram nor any fancy mappers, in that case the ppu data is in the prg-rom.
*is background render data fetched by 0x2006?
-OAM[2]->palette table->palette->0,1,2,3=>pattern table
-frame->scanline=>name table->pattern table->attribute table->VINT(SET)
-each background tile->attribute table entry->palette
-background attribute table entries cover a 32 x 32 block that contains 16 tiles
-the background can contain empty tiles, which means we have to manually check which tiles are the first and last ones on the screen.
-the background is drawn with a pipeline shift register
-4016, two writes(1,0), then 8 reads
****3.5 (PPU)dots per CPU cycle, which means 3.5 PPU cycles are executed for every CPU cycle.
****341 dot per scanline, 262 scanlines per frame.
****341 dots(ticks), 256 for rendered pixels, 85 for HBLANK
****the 0x2000 -> 0x2007 are the only connection between the cpu and ppu(dma 4014 too).
****writes only occur during vbl, which means vbl can and is used as synching point
****mayhaps pause the cpu when it tries to read 0x2002(vbl), till the ppu reaches vbl?

-32 background tiles have to be drawn per scanline, loopyV is incremented ONLY when a tile is rendered!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-horizontal tile coordinates have to wraparound when they exceed the width, this can be done by subtracting the coarse and fine scroll
-not all scanlines have to scroll at the same time
-rendering both screens at the same time(side by side)
-debugging sprite/background problems is easier when all sprites, background and sprite0 get single different colors per entity
**sprite 0 is LITERALLY sprite number 0 of the 64 sprites in the SPR_RAM!!

L I N K S:
http://nesdev.parodius.com/bbs/viewtopic.php?t=7790&sid=1aabd028b37fbc7c8ed1511f45044337
http://www.atariarchives.org/roots/chapter_6.php
http://devster.monkeeh.com/6502/6502_intro.html
http://www.obelisk.demon.co.uk/6502/reference.html#DEX
http://www.atarimax.com/jindroush.atari.org/aopc.html#BPL
http://www.fadden.com/dl-apple2/sweet16.txt
http://www.6502.org/tutorials/vflag.html#2.4
http://www.c64-wiki.com/index.php/LDA
http://members.chello.nl/taf.offenga/illopc31.txt
http://www.ffd2.com/fridge/docs/6502-NMOS.extra.opcodes
http://www.google.com/patents/US4949298
http://nesdev.parodius.com/NES%20emulator%20development%20guide.txt
http://nocash.emubase.de/everynes.htm
http://web.textfiles.com/games/nestech.txt
https://sites.google.com/site/nesdevhandbook/theframe.html
http://nemulator.com/files/nes_emu.txt
http://nesdev.parodius.com/NES%20emulation%20discussion.txt
http://www.gamefaqs.com/nes/916386-nes/faqs/2949
http://disch.arc-nova.org/nes_input.txt
http://teaching.idallen.com/dat2343/10f/notes/040_overflow.txt
http://blog.kevtris.org/blogfiles/EWJ2PROT.TXT
http://nesdev.parodius.com/bbs/viewtopic.php?p=64224
http://forums.nesdev.com/viewtopic.php?t=664


http://wiki.intellivision.us/index.php?title=Incomplete_Address_Decoding

http://nesdev.parodius.com/NESTechFAQ.htm
http://pdroms.de/files/nes

http://tuxnes.sourceforge.net/nesmapper.txt

http://gitorious.org/nesicide/nes-test-roms/trees/master

P P U:
file:///C:/Downloads/nesdev/2C02%20technical%20reference.TXT
file:///C:/Downloads/nesdev/NinTech.txt



-researching how the gpu works. it is this weird combination of being a part of and being a separate entity from the cpu.
 even so, it is not entirely autonomous.
