Hello NES dev
I have partially implemented the PPU and tested it on a very simple tiles
now I want a real games tiles
what I want exactly :
name table memory ,the tiles pointed to by name table , the corresponding attribute tables and for sure the palette memory
I have found some tools but unfortunately , the either do not give me what I want ( I don't want a bitmap , I want memory) or I couldn't use it.
any help ?
Tools required
Moderator: Moderators
Re: Tools required
What's the difference between a simple tile and a complex one? The PPU handle them identically.tested it on a very simple tiles
How about this approach...what I want exactly :
name table memory ,the tiles pointed to by name table , the corresponding attribute tables and for sure the palette memory
Play a game in FCEUX, pause execution. Copy the contents of the PPU in the hex editor tool.
nesdoug.com -- blog/tutorial on programming for the NES
Re: Tools required
These can be pulled from any of several sources:Muhammad_R4 wrote:what I want exactly :
name table memory ,the tiles pointed to by name table , the corresponding attribute tables and for sure the palette memory
- FCEUX (Windows) can dump all PPU memory: Debug > Hex Editor then File > Dump > PPU Memory. Tiles are at $0000 (usually) or $1000 (sometimes), nametables are at $2000 or $2C00, and palette is at $3F00.
- Create something with my graphics editor, either directly or by using savtool to convert a bitmap image. Then open the .sav file. Tiles are at $0000, nametable at $1800, and palette at $1F00.
- A save state of a game with CHR RAM will have the entire PPU memory. Save state formats are emulator-specific, but an open-source emulator should document its format.
- A save state of a game with CHR ROM will have the nametables and palette, and the tile data will be in CHR ROM.
I assume "complex one" is a full-size scene that can be shown to those evaluating progress in your project, as opposed to just a couple hand-pixeled tiles with no artistic merit.
-
- Posts: 66
- Joined: Sat Jun 25, 2016 5:33 am
Re: Tools required
exactly what I meant by complex , I want to see a complex sceneI assume "complex one" is a full-size scene that can be shown to those evaluating progress in your project, as opposed to just a couple hand-pixeled tiles with no artistic merit.
-
- Posts: 66
- Joined: Sat Jun 25, 2016 5:33 am
Re: Tools required
These can be pulled from any of several sources:
FCEUX (Windows) can dump all PPU memory: Debug > Hex Editor then File > Dump > PPU Memory. Tiles are at $0000 (usually) or $1000 (sometimes), nametables are at $2000 or $2C00, and palette is at $3F00.
I have done this , when i dumbed the memory and opened it to read , there where somethings ( strange chars , etc ) ,then what?
Re: Tools required
What did you use to open the file? Open it in a hex editor, not a text editor.
-
- Posts: 66
- Joined: Sat Jun 25, 2016 5:33 am
Re: Tools required
I have another question
what about the OAM memory ? how can I see it ?
what about the OAM memory ? how can I see it ?
Re: Tools required
Some builds of FCEUX (Windows) supported exporting the 256-byte display list from emulated OAM. I requested it when I was originally developing that graphics editor four years ago. Somehow it got lost in the shuffle, possibly around the big reorganization of FCEUX 2.2.1. (I remember the reorganization because the Action 53 mapper, #28, also got lost but was reinstated in FCEUX 2.2.2.) You can file a request in FCEUX's issue tracker at SourceForge to have it reinstated. Until then, you can open the debugger and set a breakpoint on writes to CPU $4014 to catch the display list just before the CPU sends it to PPU OAM. For example, if the value written to $4014 is $02, then OAM will be a copy of the data that was in CPU $0200-$02FF at the time of the write to $4014. Or if the value written to $4014 is $07, then OAM will be a copy of the data that was in CPU $0700-$07FF at the time of the write to $4014. Then you can export CPU memory and extract the appropriate 256-byte page.
Re: Tools required
I believe Nintendulator can see the Sprite RAM in its debugger.
nesdoug.com -- blog/tutorial on programming for the NES