You cannot show the content of both pattern table at the same time: one is for Background and one is for sprites.

You can only show the content of one pattern table for the BG, since 1 pattern table has 256 values and those index refer to the currently selected pattern table. This means your program is working properly, since your first write the BG data, it shows the content of the first pattern table, then you switched pattern table, now the BG is updated to show the content of the newly selected pattern table, then you writing index 0-256, which show the content of the currently selected pattern table. So both will show the content of the selected pattern table, which is the expected behavior.

You could do a sprite 0 split halfway through the screen to change the tiles below a given scanline, but the easier way might be just to hook up bit 4 of $2000 to a controller button so you can flip between the 2 pages easily.

Edit: Just to clarify, that bit does not affect what value you write to the nametable backgrounds. I notice you flip it when you write the second half. The big only affects what is displayed at time of rendering, it doesn't affect the stored nametable data at all.

You could do a sprite 0 split halfway through the screen to change the tiles below a given scanline

Well, I believe that is indeed something advanced technique. I'll continue reading the tutorials and trying my best to see if I can make it.

rainwarrior wrote:

but the easier way might be just to hook up bit 4 of $2000 to a controller button so you can flip between the 2 pages easily.

Actually displaying the 2 pages of pattern table is not my final goal.I'm recently planning to make an interesting cartridge that contains a powerful MCU on board, which generates images in realtime, and converts the image data to "pattern data format of NES PPU" and finally flush the data chunk to CHR RAM every NMI. The MCU does nearly all the work (almost instantly compared to NES itself due to its strong power and fast speed), the NES only needs to display the 2 pages of pattern table on the screen with a well organized nametable.Now you see, I encounterd the problem.That's the whole story.

With a memory controller like an mmc3, what you would do is to change the content of the chr bank at a specific location and it would allow to continue to show the content of another bank. With the scanline counter and proper timed code, it wouldn't be an issue. This is how you would display a pictures that exceed the amount of 256 tiles per pattern table.

If you're planning on running all the code in a separate CPU you could just make the NES NOP for half the frame and then write to $2000 to switch the tiles at that point, no need for even an IRQ or waiting on a sprite.

If you're planning on running all the code in a separate CPU you could just make the NES NOP for half the frame and then write to $2000 to switch the tiles at that point, no need for even an IRQ or waiting on a sprite.

But you still have to sync with the end of vblank in order to do this, unless the NMI handler executes in a constant number of cycles. The sprite 0 hit flag and the sprite overflow flag can be used to detect the end of vblank, since that's when those flags get cleared.

Here's a question: if you're generating the patterns externally, why are you restricting yourself to using only 512 tiles? If you use 16KB of CHR-RAM, instead of 8KB, you'll have enough tiles to fill the entire screen with unique graphics. The only problem is that the NES can only address 8KB by itself, you'd need a mapper (something as simple/cheap as CNROM will do) to switch the rest of the CHR-RAM.

Here's a question: if you're generating the patterns externally, why are you restricting yourself to using only 512 tiles?

Because 8KB of CHR RAM is enough for my requirement.

tokumaru wrote:

If you use 16KB of CHR-RAM, instead of 8KB, you'll have enough tiles to fill the entire screen with unique graphics. The only problem is that the NES can only address 8KB by itself, you'd need a mapper (something as simple/cheap as CNROM will do) to switch the rest of the CHR-RAM.

Yes, exactly. however my CNROM cartrigde does not work at all. Once powered on, the CHR ROM or CHR RAM immediately got hot. I believe there must be short-circuit somewhere when I replaced the mask rom chips to flash/sram from my donor cart.

With a memory controller like an mmc3, what you would do is to change the content of the chr bank at a specific location and it would allow to continue to show the content of another bank. With the scanline counter and proper timed code, it wouldn't be an issue. This is how you would display a pictures that exceed the amount of 256 tiles per pattern table.

To be honnest, if your goal is to have 512 tiles for background instead of the usual 256, and that you're going to do that with a mapper, I'd rather suggest using MMC2 or MMC4 than MMC3. Those mappers were developped exactly for this purpose.

(There is another form of noise for the dithering, but that was intentionally added. You can verify that it's a stable picture wherever the screen is not moving.)

Bregalad wrote:

To be honnest, if your goal is to have 512 tiles for background instead of the usual 256, and that you're going to do that with a mapper, I'd rather suggest using MMC2 or MMC4 than MMC3. Those mappers were developped exactly for this purpose.

I don't think there's a need to have any mapper at all for this intended purpose, plain NROM is good enough for this if 8k of CHR is sufficient.

Just wait for vblank, set page 0, use a countdown loop to wait for half the screen to pass, then set page 1. (Can probably even do this in C without much problem, i.e. inside that while(1) loop.)

To be honnest, if your goal is to have 512 tiles for background instead of the usual 256, and that you're going to do that with a mapper, I'd rather suggest using MMC2 or MMC4 than MMC3. Those mappers were developped exactly for this purpose.

MMC3 is much more common than MMC2/MMC4. Easier to find and cheaper to buy.

Who is online

Users browsing this forum: No registered users and 9 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum