Beginner question

[emulacionsinsecretos]

How NES select a bank? I am analyzing a NES game with mapper 1.

[tepples]

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.

[dougeff]

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).

[tepples]

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.

[rainwarrior]

Why mapper 1?

I don't think mapper was a choice for OP?

I am analyzing a NES game with mapper 1.

[nes12]

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...

[koitsu]

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:

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: Select all

 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: Select all

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: Select all

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.

[tokumaru]

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.

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.

[tokumaru]

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.

[thefox]

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.

[tepples]

We have one.

[nes12]

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

[nes12]

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...

[nes12]

We have one.

Thx!

I was saw this webpage but i dont understand...

[tepples]

What was the first sentence in that article that you did not understand, so that I may fix that sentence?