This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Beginner question

Beginner question
by on (#165175)
How NES select a bank? I am analyzing a NES game with mapper 1.
Re: Beginner question
by on (#165176)
Start at the wiki page for mappers, then click 001 to learn that iNES Mapper 1 is MMC1, then visit the MMC1 page and let us know if you still have questions that that page doesn't answer.
Re: Beginner question
by on (#165189)
Why mapper 1?

I prefer mapper 4, MMC3. Easier to work with. Scanline counter. Smaller chunk of bank to be swapped.

But, generally speaking...of all mappers. The program will store a value somewhere $8000-ffff, which sends a signal to the mapper to change banks. ($8000-ffff is read-only, so no value actually changes here).
Re: Beginner question
by on (#165200)
Several reasons:
  1. During the NES's commercial era, MMC1 was available before MMC3.
  2. During the NES's commercial era, Nintendo charged less for MMC1 than for MMC3.
  3. During the homebrew era, the CPLD to fully clone MMC1 is significantly less expensive than the CPLD to fully clone MMC3.

Depending on the release date of the game that the OP is analyzing, A or B could be true.
Re: Beginner question
by on (#165204)
dougeff wrote:
Why mapper 1?

I don't think mapper was a choice for OP?
emulacionsinsecretos wrote:
I am analyzing a NES game with mapper 1.
Re: Beginner question
by on (#165487)
Hi all! I m new... I learning cpu and ppu memory map, but i dont understand few questions...
1. So $0800-$2000 this section stored the $0000-$07FF ram mirror 3x but where stored it in physicalli? Just emulation used this section? This is 6KBs!

2. The ppu memory maping... 2 KBs internal ram onboard 8 KBs stored CHR but the more? Name tables attribute tables color palette etc. Where stored it physicalli? 6KBs! (Max 16KBs).

3. I diassambled the battle city, and i see this insruction:
01: $874A LDA #$35 @ $879B (just illustration!)

@ $879B what is this ? I dont find on the WEB...
Re: Beginner question
by on (#165495)
I'll leave the memory map questions to others (not hard to explain, just don't have the energy), and I'll answer this one:

nes12 wrote:
3. I diassambled the battle city, and i see this insruction:
01: $874A LDA #$35 @ $879B (just illustration!)

@ $879B what is this ? I dont find on the WEB...

The disassembler you're using is doing something ridiculous (e.g. bug or very bad design), or you've made a typo when entering the actual instuctions/operand in your post here.

LDA #$35 loads the immediate value $35 (hexadecimal) into the accumulator. There's no addressing mode involved that would expand to an actual 16-bit PC address (e.g. $879B).

I've loaded up Battle City and I can't find this instructions at $874A. I know you said "just illustration!", so rather than illustration I'll show you some actual code in FCEUX:

Code:
 00:876B:20 DD D6  JSR $D6DD
 00:876E:AE 09 01  LDX $0109 = #$00
 00:8771:B5 00     LDA $00,X @ $0000 = #$C0

JSR $D6DD is a jump-to-subroutine call that executes code starting at $D6DD.

LDX $0109 loads an 8-bit value from memory location $0109 into the X register. At the moment this disassembly was generated, memory location $0109 contained value $00 (zero). If the game was running while generating this disassembly, then it's very likely a subsequent disassembly or trace in real-time could show another value. (It's very easy to get lost/confused when in FCEUX in this regard -- you have to know what you're doing / be paying attention).

LDA $00,X loads an 8-bit value from a zero page location $00 (e.g. $0000) plus the content of the X register. In this case, X was $00 (zero), so $00 + $00 = load from $00. FCEUX does the math for you -- that's what the @ $0000 part means. For example, take the following code:

Code:
LDX #$16
LDA $10,X

FCEUX would show the 2nd instruction as LDA $10,X @ $0026 (because $10 + $16 = $26). Another example showing the nature of this:

Code:
LDX #$03
LDA $FF,X

FCEUX would show the 2nd instruction as LDA $FF,X @ $0002 because this addressing mode is zero page only (8-bit).

FCEUX always shows the calculated effective address as a 16-bit address, even if the addressing mode of the instruction only supports zero page (8-bit) addresses. This can be confusing, I know; that's purely an "FCEUX-ism". Other emulators or realtime debuggers might show things more appropriate (i.e. LDA $FF,X @ $02 would make more sense).

There are other addressing modes that do support 16-bit addresses at runtime, e.g. zero page indirect indexed Y: LDA ($nn),Y.

I suggest reading about 6502 addressing modes and some of this will become more clear. The @ $nnnn thing, though, is a "feature" of FCEUX or whatever disassembler you're using. If it truly showed LDA #$35 @ $879B then I classify that as a major bug.

P.S. -- Why did you pick this thread to ask this question? It has nothing to do with the original question asked (how to select a PRG/CHR page with mapper 1). You're asking basic 6502 questions, which deserves its own thread.
Re: Beginner question
by on (#165497)
nes12 wrote:
1. So $0800-$2000 this section stored the $0000-$07FF ram mirror 3x but where stored it in physicalli? Just emulation used this section? This is 6KBs!

Mirroring is a side effect of mapping a small amount of memory to a larger address range. If you put a 2KB chip in an 8KB address range, it's only natural that the same memory will show up 4 times. Physically, it' the exact same memory. $0000, $0800, $1000 and $1800 all point to the exact same memory location, which is the first byte of a 2KB RAM chip.

Quote:
2. The ppu memory maping... 2 KBs internal ram onboard 8 KBs stored CHR but the more? Name tables attribute tables color palette etc. Where stored it physicalli? 6KBs! (Max 16KBs).

The first 8KB of video memory (pattern tables) are usually mapped to the cartridge, while he rest (name/attribute tables) are inside the NES. The mirroring here is also a side effect of mapping a 2Kb chip to an 8KB address range. Palette and OAM are both inside the PPU.
Re: Beginner question
by on (#165501)
Now you might be wondering: why would they map a small chip to a large address range then? Well, it's simpler, and cheaper. The 6502 has a 64KB address range, which has to be split into ROM, RAM and registers. To simplify the design and reduce costs, they broke up that space in the simplest possible way. The first thing they did was break the address space in two, and map the upper half to the cartridge's ROM. This makes it really simple for the NES to detect whether the ROM is being accessed: if the address is in the $8000-$FFFF range (binary: 100000000000000 to 1111111111111111), the ROM is being accessed, but if the address is in the $0000-$7FFF range (binary: 0000000000000000 to 0111111111111111), it's not the ROM. The difference is a single bit in the address (meaning the NES only needs to "watch" 1 address bit in order to properly route ROM accesses), the topmost one: if it's 1, select the ROM, if it's 0, more bits will have to be checked so the NES knows what to access.

So, now the NES has to break the $0000-$7FFF further, and $0000-$1FFF is dedicated to RAM, while $2000-$3FFF goes to memory mapped PPU registers. We ended up with an 8KB range dedicated to RAM, but the RAM chip is only 2KB, so it will show up 4 times in that space. The engineers could have divided the space further so that only 2KB would be dedicated to RAM, and the rest would contain "nothing" (open bus), but there'd be absolutely no reason to do that (besides OCD, which definitely doesn't go well with hardware design!). There's no benefit whatsoever, it just requires more hardware, so they didn't do it.

In addition to that, dedicating an 8KB address range to RAM also meant leaving this particular hardware spec open, so they had the possibility of increasing the size of the RAM chip before the console's release if the price dropped significantly during the development of the console. We know that didn't happen (or did the original iteration of the console have less than 2KB of RAM?), but that's still one advantage of doing things the way they did.
Re: Beginner question
by on (#165504)
tokumaru wrote:
Now you might be wondering: why would they map a small chip to a large address range then?

I wonder how many times this same question has been answered. Maybe we need an FAQ. :)
Re: Beginner question
by on (#165505)
We have one.
Re: Beginner question
by on (#165507)
koitsu

thx the help, and sorry the bad example... i just wrote my memory.
Now i understand! So this is indirect adress result adress! Yes i reading: 6502 Assembly Language Subrutines book wrote:Lance A Leventhal and Winthrop Saville
Re: Beginner question
by on (#165511)
tokumaru wrote:


The first 8KB of video memory (pattern tables) are usually mapped to the cartridge, while he rest (name/attribute tables) are inside the NES. The mirroring here is also a side effect of mapping a 2Kb chip to an 8KB address range. Palette and OAM are both inside the PPU.


Thx the help! The CPU memory mapping answer is understand!
But the PPU i dont understand...
So the CHR (8KB) stored it the cartridge (pattern table 0 and pattern table 1). The PPU RAM in the NES onboard (2 KBs). Or the inside the PPU another 2 KBs ROM where stored the name tables and attribute tables? And the 4 namne tables 2 to be 2 mirror? 4 attributes tables 2 to be 2 mirror? And the attribute tables stored the sprite data, so the CPU upload this content the attribute tables the PRG algoritmh? And the name tables also?

Sorry i bad english...
Re: Beginner question
by on (#165512)
tepples wrote:

Thx!

I was saw this webpage but i dont understand...
Re: Beginner question
by on (#165513)
What was the first sentence in that article that you did not understand, so that I may fix that sentence?
Re: Beginner question
by on (#165516)
tepples wrote:
What was the first sentence in that article that you did not understand, so that I may fix that sentence?


I dont understand what is the mirroring, why should be mirroring the RAM section. After i found this webpage and i began reading it. But i dont understand at all why should be mirroring the memory section? (i dont read end) Plus i bad english...
Re: Beginner question
by on (#165519)
nes12 wrote:
So the CHR (8KB) stored it the cartridge (pattern table 0 and pattern table 1). The PPU RAM in the NES onboard (2 KBs).

That's correct. The on-board 2KB of RAM are used for 2 name and attribute tables.

Quote:
Or the inside the PPU another 2 KBs ROM where stored the name tables and attribute tables?

No, inside the PPU chip there's only enough memory for the palette (28 entries x 6 bits = 168 bits) and the OAM (64 entries x 29 bits = 1856 bits).

Quote:
And the 4 namne tables 2 to be 2 mirror? 4 attributes tables 2 to be 2 mirror?

The name tables (and their respective attribute tables) are mirrored because although the PPU can handle 4 of them (for a total scroll area of 512x480 pixels), the built-in 2KB RAM chip can only hold 2, so they show up twice.

Quote:
And the attribute tables stored the sprite data, so the CPU upload this content the attribute tables the PRG algoritmh? And the name tables also?

I's getting harder to understand what you're writing. Everything related to sprites is stored inside the PPU. Each sprite has the following information:

- horizontal position (8 bits);
- vertical position (8 bits);
- pattern index (8 bits);
- attributes (5 bits);

Since there are 64 sprites, that adds up to 1856 bits.
Re: Beginner question
by on (#165520)
nes12 wrote:
Plus i bad english...

What language(s) do you understand well? Your profile doesn't give us any clues. Maybe someone that speaks the same language as you can help out.
Re: Beginner question
by on (#165521)
(Deleted, as probably not helpful.)
Re: Beginner question
by on (#165529)
tokumaru wrote:
nes12 wrote:
Plus i bad english...

What language(s) do you understand well? Your profile doesn't give us any clues. Maybe someone that speaks the same language as you can help out.


I from Hungary. I speak hungarian perfect and little english. I was found the battle city the player1 sprite id and horizontal positions and the direction (if i press direction button the hex editor wrote A0, A1, A2, A3) but this informations stored it the CPU internal RAM (2KB) example player 1 spriteid $A8 (zero page) then this infos copied the PPU internal RAM throught I/O registers? I belive the sprite data stored it attribute tables...

Big thanks the help!
Re: Beginner question
by on (#165530)
I think you're talking about OAM (sprites) and how there is a copy of it in RAM (OAM buffer).
Re: Beginner question
by on (#165545)
koitsu wrote:
I'll leave the memory map questions to others (not hard to explain, just don't have the energy), and I'll answer this one:

nes12 wrote:
3. I diassambled the battle city, and i see this insruction:
01: $874A LDA #$35 @ $879B (just illustration!)

Code:
 00:876B:20 DD D6  JSR $D6DD
 00:876E:AE 09 01  LDX $0109 = #$00
 00:8771:B5 00     LDA $00,X @ $0000 = #$C0


Although it looks like he posted code from bank 1, while you posted code from bank 0.
Re: Beginner question
by on (#165675)
The name table stored specially data that which is show sprite or background? The attribute table stored color set?
Re: Beginner question
by on (#165676)
tokumaru wrote:
Quote:
Or the inside the PPU another 2 KBs ROM where stored the name tables and attribute tables?

No, inside the PPU chip there's only enough memory for the palette (28 entries x 6 bits = 168 bits) and the OAM (64 entries x 29 bits = 1856 bits).


What is the entries? Registers?
Re: Beginner question
by on (#165677)
I very dont understand the name table mirroring. Could anybody said me?
Re: Beginner question
by on (#165678)
Another...
I using fceux emulator.
how can i use the code/data logger? I trying but when i load saved .cdl file i cant see the code texts...
Can u give me tutoriall video? I dont find the youtube...How can i search values? How can i detect functions and variables?
Re: Beginner question
by on (#165680)
Each nametable is 1 KiB (which means 1024 bytes) and holds one screen's worth (32x30 tiles or 256x240 pixels) of data.

There are 4 KiB of address space for nametables. In PPU address space, $2000-$23FF is the top left screen, $2400-$27FF is the top right screen, $2800-$2BFF is the bottom left screen, and $2C00-$2FFF is the bottom right screen.

But the NES Control Deck contains only 2 KiB of actual memory for nametables: $000-$3FF and $400-$7FF. So hardware on the cartridge translates the PPU address into an address in nametable memory. Some PPU addresses end up pointing to the same memory; this pointing to the same memory is called "mirroring".

"Horizontal arrangement" or "vertical mirroring" happens when the cart places the two nametables at $2000 and $2400. This arranges the screens side-by-side, with the bottom left ($2800) identical to the top left ($2000) and the bottom right ($2C00) identical to the top right ($2400). The usable area is a 64x30 tile (512x240 pixel) plane.

"Vertical arrangement" or "horizontal mirroring" happens when the cart places the two nametables at $2000 and $2800. This arranges the screens side-by-side, with the top right ($2400) identical to the top left ($2000) and the bottom right ($2C00) identical to the bottom left ($2800). The usable area is a 32x60 tile (256x480 pixel) plane.

Diagrams for all this are in the article titled "Mirroring" on NESdev Wiki.

In the above, what was the first sentence that you failed to understand? Do you know what an "address bus" is? Unfortunately, the article titled "Address bus" on Wikipedia hasn't been translated into Hungarian.
Re: Beginner question
by on (#165681)
How can i found which is sprite id which is color set use?
Re: Beginner question
by on (#165683)
tepples

very thx the help! I known what is the adress bus. But i dont understand what is the name table. U said name tables 1KiB 30x32 tiles fullscreen. Why should be 4KiB? This is 4 screens!
Re: Beginner question
by on (#165684)
The NES PPU is capable of addressing 4 screens. But the video memory soldered onto the motherboard is large enough for only 2 screens. There are two ways for a game to handle this. Most NES games use the two screens and allow the other two to be duplicates; this strategy is called mirroring. A small number (fewer than ten) contain extra memory in the cartridge to allow four distinct screens; this strategy is called 4-screen VRAM.
Re: Beginner question
by on (#165685)
tepples wrote:
The NES PPU is capable of addressing 4 screens. But the video memory soldered onto the motherboard is large enough for only 2 screens. There are two ways for a game to handle this. Most NES games use the two screens and allow the other two to be duplicates; this strategy is called mirroring. A small number (fewer than ten) contain extra memory in the cartridge to allow four distinct screens; this strategy is called 4-screen VRAM.


If 1 name table 1 screen then the nes wiki name table mirroring post why cut 1 screen to 4 ?
Re: Beginner question
by on (#165686)
nes12 wrote:
What is the entries? Registers?

One entry is one unity. If we're talking about the palette, an entry is one color. Even though there are 32 positions in the palette, the PPU doesn't have memory for color 0 in the sprite palettes (they are mirrors of the color 0 in the background palettes), so only 28 colors are actually stored.

As for the OAM (Object Attribute Memory, where the sprite information is), each entry is a set of X and Y coordinates, a pattern index and 5 bits of attributes, and there's a total of 64 entries. An entry isn't exactly 4 bytes (32 bits) because the unused bits of the attribute byte aren't stored anywhere, they simply don't exist.

nes12 wrote:
Why should be 4KiB? This is 4 screens!

The PPU was built with the capacity to "see" 4 screens, arranged as a 2x2 block, forming 512x480-pixel area. Having a tile map larger than the screen is really useful for scrolling, double-buffering, and other things. However, Nintendo needed to cut costs and installed only 2KB of VRAM in the NES, instead of the 4KB that the PPU can see, which results in mirroring. The cartridge has some autonomy over the way that memory is mapped, which allows it to configure the mirroring in different way or even provide more memory so there are in fact 4 unique screens (or more, through bankswitching).
Re: Beginner question
by on (#165687)
Ok i possible understand!

So if 2KiB change to 8 KiB then resolution is 512x480?
what is the name table data exactly which is showable: sprite or background?

What is the attribute table? What stored it?
Re: Beginner question
by on (#165688)
nes12 wrote:
So if 2KiB change to 8 KiB then resolution is 512x480?

No, no, the resolution never changes! The image the console sends to the TV is ALWAYS 256x240. But with 4KB (not 8KB!) you can represent an area of 512x480 pixels, and the screen can "hover" over that area, showing parts of it. This is essential for scrolling games.

Quote:
what is the name table data exactly which is showable: sprite or background?

The name table is just for the background. Sprites are defined by the OAM.

Quote:
What is the attribute table? What stored it?

Each name table is 960 bytes, followed by a 64-byte attribute table, bringing the total to 1024 bytes (1KB) per "screen". The name table specifies which tiles go where, and the attribute table specifies which palettes to use in each 16x16-pixel area of the name table.
Re: Beginner question
by on (#165689)
So each name table stored the background? And each attribute table stored background colors? The sprite colors where stored the OAM?

Another How can i edit the code lines with FCEUX? I can't... I found empty lines to 00 bank. (undefined)

The name table how stored the background? 1 tile 1 byte. This is background sprite id?
Re: Beginner question
by on (#165713)
Quote:
So each name table stored the background? And each attribute table stored background colors? The sprite colors where stored the OAM?


Yes.

Everything about sprites are stored in the OAM. 4 bytes per sprite...
1.Y position
2. Tile #
3. Attributes, including which color palette
4. X position

Quote:
How can i edit the code lines with FCEUX?


That would be a very unusual thing to do, but I suppose you could hex edit in code, by opening Debug/Hex Editor... set view = ROM. Any changes made will be viewable in the Debugger tool. I've only done this to fine-tune a constant value that I was testing...so I could get immediate feedback from the game. I would then type the best value into the source code.

But, usually, you would change the source code and recompile/reassemble. FCEUX was not designed to be an assembler.

Quote:
The name table how stored the background? 1 tile 1 byte. This is background sprite id?


Background is 1 byte per tile. Each byte is the tile # from 0-255. Background objects are not sprites, so I don't understand your last question.
Re: Beginner question
by on (#165715)
Well, in the disassembly window you can click on the far left of the instructions and type new instructions as text that FCEUX will assemble for you, so there's no need to do it directly in hex. It will overwrite whatever was there before, and you can save the resulting ROM to a new file. I wouldn't recommend this for extensive modifications though.
Re: Beginner question
by on (#165722)
dougeff wrote:

But, usually, you would change the source code and recompile/reassemble. FCEUX was not designed to be an assembler


I don't have the source code battle city.nes...

dougeff wrote:
Background is 1 byte per tile. Each byte is the tile # from 0-255. Background objects are not sprites, so I don't understand your last question.


So 1 byte 1 background tile, but 1 tile 8x8 pixel! Name table stored the tile index? Or full tile? (the sprite stored 2 bit/pixel => (8x8) 1 tile stored 16 byte!)
Re: Beginner question
by on (#165729)
Another...
The name table using the PPU to screen rendering. How editing the name table with CPU for PRG?

The PPU memory map:
8 KiB pattern tables in the cartridge, 2 KiB internal RAM int to NES 2 KiB name tables mirroring, 256 Byte sprite properties and maybe 64 byte color palette, OAM; and the more? ((3 KiB + 704 byte) because all 16 KiB) Where stored it?
Re: Beginner question
by on (#165731)
Usually the nametable is decompressed from PRG ROM to the nametable RAM by the game program. The compressed data format is game-specific in most cases, though a few RLE-like formats are used across multiple games from one publisher.
Re: Beginner question
by on (#165733)
Why should be using 2 name tables? One too full screen,,,
Re: Beginner question
by on (#165735)
A still screen doesn't need more than one nametable. Using more than one nametable allows scrolling without incorrect tiles at the edges of the screen.
Re: Beginner question
by on (#165742)
I think you are wanting to change a level in Battle City. Yes?

With a little investigation, you can find out...

In FCEUX, create a savestate just before the level loads. Open the Hex Editor Tool, view = ROM. Open the Code/Data Logger. Start the log. Reload the savestate, let the level load. Stop the Code/Data Logger. Look at the Hex Editor. It should have highlighted all the data used during the load (I can't remember the color meaning, look at FCEUX documents). Try changing some of the highlighted data. Reload the save state...see if it changed. If NO, undo change. Try changing another highlighted data. Reload the savestate. Repeat until you find the data relating to the level. Maybe it will take you 5 minutes of trial and error.
Re: Beginner question
by on (#165769)
No. I want reprogramming a new mode. I have few ideas. Just first i want understand how works the nes.
Example i was readed the 0-7 bits to $4016 address handle the player 1 buttons. After i was readed that $4016 address handle the 0,1,4 bits handle the joystick... which is true? Because i want the change my tank's skin if i pressed the select button during starting game few seconds...
Re: Beginner question
by on (#165796)
Well this is your lucky day because maybe I can help. But don't expect me to be that great because I'm one of the less knowledgeable people around here. I'm just doing this as a hobby, while others do programming as a job.

Battle City only has 16kB PRG ROM, and the NES can see 32kB at once on its own, so you don't need anything to expand the ROM, just edit the number of PRG ROM banks in the header of the ROM.
Re: Beginner question
by on (#165805)
True, ROM expansion doesn't get any easier than this.