question about pattern tables and the PPU

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
ReverendSA
Posts: 36
Joined: Wed Mar 23, 2016 12:27 pm

question about pattern tables and the PPU

Post by ReverendSA »

Hello,

When I incbin a chr file, I see this in fceux:

Image

I guess this is because when you incbin the chr, it will take the first 2000 bytes and display them under pattern table 0/1, right?

this chr file when viewed in yychr though has far more than 2000 bytes of data. I was wondering how I could load these for example into the PPU instead:

address $2000
Image
address $3000
Image

This is the default CHR file seen when opening yychr.

My code to load the chr is just this:

Code: Select all

	.BANK 2
	.ORG $0000
	.INCBIN "GRAPHICS/YYCHR.CHR"
I am still reading over the documentation though I have not found out what to do yet.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: question about pattern tables and the PPU

Post by Dwedit »

If you want to switch which graphics bank appears in FCEUX, you need to read about Mappers. The simplest mapper for switching graphics data is CNROM (mapper 3). Write a byte to 8000-FFFF (And that value in ROM must also have the same value), then the bank changes.

If you need to exceed 32KB of Program data, you may consider GNROM (mapper 66) instead, or MMC1 (mapper 1), or MMC3 (mapper 4). Despite Mapper 66 being a higher number, it is not a more complicated mapper.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: question about pattern tables and the PPU

Post by tokumaru »

By itself, the NES can only see 8KB of CHR, and a simple NROM cartridge will automatically map its 8KB CHR-ROM chip to that space. If you need more than that, you're gonna have to use a mapper, like Dwedit said. The way in which parts of a larger CHR chip are mapped to the 8KB window the NES can see varies according to the mapper... it can go from 1 8KB window all the way to 8 1KB windows, as mappers get more advanced.

Another option is to use CHR-RAM instead of CHR-ROM. This is when a cartridge uses a RAM chip for the CHR memory instead of a ROM chip. This means that when the console powers on, the CHR memory is not automatically populated with graphics, the program itself has to copy data from PRG-ROM to CHR-RAM to fill it with tiles. You can do this as many times as you need, and update as many tiles as you need each time. The main constraint here is time: while switching CHR-ROM is almost instantaneous, populating CHR-RAM is a manual one-byte-at-a-time data transfer, which takes significant CPU time to execute. Not a problem between levels, for example, since a normal human being can't tell that there are 1 or 2 extra blank frames in there, but during gameplay (i.e. to animate background tiles) it's significantly harder to pull off efficiently.
ReverendSA
Posts: 36
Joined: Wed Mar 23, 2016 12:27 pm

Re: question about pattern tables and the PPU

Post by ReverendSA »

hey guys I gave bank switching a shot and it worked.
However, this works if I incbin 2 different chr files, both of which are 8kb.
I am testing with a 28kb chr file which has 8000 bytes of graphics.
Is there a way in mapper 0 to incbin this 28kb file with 8000 bytes of graphics, but offset it so that the 2 pattern tables used aren't from the beginning of the chr file? Or does that also require bank switching? I have not been able to bank switch yet using a single chr file.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: question about pattern tables and the PPU

Post by Dwedit »

CHR ROM size is specified in the NES header as a multiple of 8K, and while you can use any number you want, it really should be a power of 2. (8K, 16K, 32K, 64K, 128K, etc)

28K is not a multiple of 8, and not a power of 2, it should be expanded to 32K. Get yourself familiar with hex editors if you don't know how to add bytes to a file.

If your CHR size in the NES header doesn't match the actual CHR data, it's truncated to what the size in the header says. If your CHR data is smaller than what the header says, emulators will refuse to load the file.

For PRG Rom size, it must be a power of 2 for most mappers. (16K, 32K, 64K, 128K, 256K, 512K, 1024K, etc)
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
ReverendSA
Posts: 36
Joined: Wed Mar 23, 2016 12:27 pm

Re: question about pattern tables and the PPU

Post by ReverendSA »

Dwedit wrote: Mon Dec 13, 2021 12:11 pm CHR ROM size is specified in the NES header as a multiple of 8K, and while you can use any number you want, it really should be a power of 2. (8K, 16K, 32K, 64K, 128K, etc)

28K is not a multiple of 8, and not a power of 2, it should be expanded to 32K. Get yourself familiar with hex editors if you don't know how to add bytes to a file.

If your CHR size in the NES header doesn't match the actual CHR data, it's truncated to what the size in the header says. If your CHR data is smaller than what the header says, emulators will refuse to load the file.

For PRG Rom size, it must be a power of 2 for most mappers. (16K, 32K, 64K, 128K, 256K, 512K, 1024K, etc)
That was my bad. I was able to pad it to 32kb and now when I incbin the modded 32kb chr file, I see in the ROM that just after the prg, CHR uses up 7FFF bytes. The PPU still only shows the first 2 pattern tables, there should be a way to cycle through the others right? Without using a mapper different from 0 I mean.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: question about pattern tables and the PPU

Post by Dwedit »

FCEUX's pattern table viewer shows what is mapped into the NES's PPU memory at 0000-2000. Only the game can change this by bankswitching it.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: question about pattern tables and the PPU

Post by tokumaru »

ReverendSA wrote: Mon Dec 13, 2021 11:39 amIs there a way in mapper 0 to incbin this 28kb file with 8000 bytes of graphics, but offset it so that the 2 pattern tables used aren't from the beginning of the chr file? Or does that also require bank switching?
Depending on the assembler you're using, you can include just part of a file... In ca65, .incbin can take 3 arguments: the path to the file, the start offset (defaults to 0) and the number of bytes to include (defaults to the whole file). So if you wanted to include the second 8KB block in a large CHR file you could do this:

Code: Select all

.incbin "tiles.chr", 8192, 8192 ;starting from 8192, include 8192 bytes
This will work for mapper 0 as long as you only read 8192 bytes (8KB) from the file, and since mapper 0 doesn't allow any tile switching at all, you're stuck with those 8KB for the whole program.
ReverendSA wrote: Mon Dec 13, 2021 1:00 pm The PPU still only shows the first 2 pattern tables, there should be a way to cycle through the others right? Without using a mapper different from 0 I mean.
Cycling through the patterns during runtime will require a mapper.
ReverendSA
Posts: 36
Joined: Wed Mar 23, 2016 12:27 pm

Re: question about pattern tables and the PPU

Post by ReverendSA »

thank you guys for your quick posts and information. I tried out mapper 66 and chr-ram and had fun writing the routine for that. I will have some fun doing pattern table changes with button presses and optimizing it.

Image


Code: Select all

	RESET_PPUMASK
	LDX #$00 		; same cycles as TAX
	LDA #LOW(GFX)
	STA GRAPHICS_LOADING_ADDRESS
	LDA #HIGH(GFX)
	STA GRAPHICS_LOADING_ADDRESS+1
MLOOP:	
	LDY #$00		
    TXA
    STA $2006
	LDA #$00
    STA $2006	
SUBLOOP:
    LDA [GRAPHICS_LOADING_ADDRESS], Y	
    STA $2007
    INY
    CPY #$00
    BNE SUBLOOP
	LDA GRAPHICS_LOADING_ADDRESS+1
	CLC
	ADC #$F0
	ADC #$10
	STA GRAPHICS_LOADING_ADDRESS+1
	INX
	CPX #$10
	BNE MLOOP
Post Reply