High quality images on the NES with MMC3 scanline interrupts and CHR-RAM

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Fiskbit
Posts: 153
Joined: Sat Nov 18, 2017 9:15 pm

Re: High quality images on the NES with MMC3 scanline interrupts and CHR-RAM

Post by Fiskbit » Wed Aug 12, 2020 4:27 pm

FYI, unlike x86, CLI enables IRQs in 6502 and SEI disables them.

eVeRinOr
Posts: 10
Joined: Wed Aug 12, 2020 9:14 am

Re: High quality images on the NES with MMC3 scanline interrupts and CHR-RAM

Post by eVeRinOr » Wed Aug 12, 2020 4:36 pm

Fiskbit wrote:
Wed Aug 12, 2020 4:27 pm
FYI, unlike x86, CLI enables IRQs in 6502 and SEI disables them.
Ah, yes I understand that. That is why I have it there because an IRQ interrupt won't happen if it is not enabled. I said that though because he asked how I am handling the I flag.

Fiskbit
Posts: 153
Joined: Sat Nov 18, 2017 9:15 pm

Re: High quality images on the NES with MMC3 scanline interrupts and CHR-RAM

Post by Fiskbit » Wed Aug 12, 2020 4:47 pm

I pointed it out because the comment was saying that the CLI was meant to disable IRQs. Normally software will disable IRQs with SEI as one of the first instructions and then reenable them with CLI later after doing an appropriate amount of setup.

If you're willing to post a ROM, I'd be happy to take a look and see if I can identify the problem.

User avatar
tokumaru
Posts: 11858
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: High quality images on the NES with MMC3 scanline interrupts and CHR-RAM

Post by tokumaru » Wed Aug 12, 2020 5:15 pm

eVeRinOr wrote:
Wed Aug 12, 2020 4:24 pm

Code: Select all

	; Ignore IRQs
	cli
Like Fiskbit pointed out, the comment above the CLI is wrong. But you don't want to enable interrupts right away like that anyway. When the NES is first turned on, the mapper and the APU, two possible sources of IRQs, are in an unknown state and could end up triggering unwanted IRQs, and an untimely call to the IRQ handler could even crash the program. After resets, you could also get IRQs that were setup before the system was reset. Do like all NES programs do and start with SEI, and only do the CLI after you initialize all possible sources of IRQs to guarantee that they won't fire before you tell them to.
Does this mean that if I had not mapped the CHR banks I could not reliably output any sort of graphics? In my code I am writing an entire 8KB of data to both Pattern Tables in order to initialize it, is that it?
Since the banks are uninitialized at start up, there are no guarantees that the whole 8KB will be mapped in, multiple slots could have the same physical RAM mapped to them, meaning you'd overwrite the repeated chunks when trying to clear the full 8KB. Just map the 6 CHR slots (as you would with CHR-ROM) contiguously to avoid overlaps.

eVeRinOr
Posts: 10
Joined: Wed Aug 12, 2020 9:14 am

Re: High quality images on the NES with MMC3 scanline interrupts and CHR-RAM

Post by eVeRinOr » Wed Aug 12, 2020 5:17 pm

Fiskbit wrote:
Wed Aug 12, 2020 4:47 pm
I pointed it out because the comment was saying that the CLI was meant to disable IRQs. Normally software will disable IRQs with SEI as one of the first instructions and then reenable them with CLI later after doing an appropriate amount of setup.

If you're willing to post a ROM, I'd be happy to take a look and see if I can identify the problem.
Ah, I see what you're saying. Yeah that was an old comment I forgot to replace. Before it had sei under it however I replaced it with cli because the NESDev Wiki said that it wasn't strictly nesessary and I need IRQs to be enabled for my project.

Here is a ROM download for you to look at:
main.nes
ROM that works flawlessly in FCEUX but fails in Mesen
(16.02 KiB) Downloaded 16 times

Fiskbit
Posts: 153
Joined: Sat Nov 18, 2017 9:15 pm

Re: High quality images on the NES with MMC3 scanline interrupts and CHR-RAM

Post by Fiskbit » Wed Aug 12, 2020 5:28 pm

Thanks for the ROM. I believe the problem is that you have the PPU configured to draw both background and sprites from the same table. The MMC3 IRQ works by looking for rising edges on PPU A12. Under a normal configuration of background on the left table ($0000-0FFF) and sprites on the right table ($1000-1FFF), a rising edge occurs when transitioning from background to sprites around the start of hblank. The mapper counts these transitions and triggers the IRQ after the specified number. Since background and sprites are both using the left table here, PPU A12 never becomes set, so there's no signal for the mapper to use to count scanlines. If you use $2000 (PPU_CONTROL) to make sprites use the right table, this should work correctly.

lidnariq
Posts: 9659
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: High quality images on the NES with MMC3 scanline interrupts and CHR-RAM

Post by lidnariq » Wed Aug 12, 2020 5:43 pm

Note that if you want to use the same 4KB of CHR RAM for both backgrounds and sprites, you can use the MMC3 banking registers to let you do this, while leaving the the PPU's control configured so that the MMC3 still works correctly.

eVeRinOr
Posts: 10
Joined: Wed Aug 12, 2020 9:14 am

Re: High quality images on the NES with MMC3 scanline interrupts and CHR-RAM

Post by eVeRinOr » Wed Aug 12, 2020 5:45 pm

Fiskbit wrote:
Wed Aug 12, 2020 5:28 pm
Thanks for the ROM. I believe the problem is that you have the PPU configured to draw both background and sprites from the same table. The MMC3 IRQ works by looking for rising edges on PPU A12. Under a normal configuration of background on the left table ($0000-0FFF) and sprites on the right table ($1000-1FFF), a rising edge occurs when transitioning from background to sprites around the start of hblank. The mapper counts these transitions and triggers the IRQ after the specified number. Since background and sprites are both using the left table here, PPU A12 never becomes set, so there's no signal for the mapper to use to count scanlines. If you use $2000 (PPU_CONTROL) to make sprites use the right table, this should work correctly.
Oh! Thanks a ton man, that actually makes a lot of sense. I am aware of this limitation (after initialization I have the pattern tables setup this way) however later in my program I change which side the background uses temporarily (to access all 512 tiles just for the background as my game probably won't have any sprites unless I am doing sprite multiplexing) but in this process I forgot to switch it back to allow sprites to use the right side. I fixed this error and it is now working in Mesen! I swear, sometimes the simplest of things are the problem. (In this case two bits lmao)

The only thing I need now is an alternative way of converting images over to use two pattern tables instead of one so that I can get a quality more on par with NES Image Converter 2 without manually recreating the image within NES limitations. Right now I use NES Screen Tool (The main problem is it tends to have a lack of color when I import it while NES Image Converter 2 it tends to retain almsot all the color. I know some of this is thanks to sprite multiplexing although even without it the images still look good and as far as I know the program doesn't do any pallete swapping tricks)
Last edited by eVeRinOr on Wed Aug 12, 2020 5:58 pm, edited 2 times in total.

eVeRinOr
Posts: 10
Joined: Wed Aug 12, 2020 9:14 am

Re: High quality images on the NES with MMC3 scanline interrupts and CHR-RAM

Post by eVeRinOr » Wed Aug 12, 2020 5:47 pm

lidnariq wrote:
Wed Aug 12, 2020 5:43 pm
Note that if you want to use the same 4KB of CHR RAM for both backgrounds and sprites, you can use the MMC3 banking registers to let you do this, while leaving the the PPU's control configured so that the MMC3 still works correctly.
Yes, as I need multiple IRQs to happen on a single frame (There is a HUD on both the top and the bottom of the screen) Minimally two for the HUD and one for the middle of the image. I want to look into setting up the MMC3 banking registers to do this but I'm taking this one step at a time.

tepples
Posts: 22049
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: High quality images on the NES with MMC3 scanline interrupts and CHR-RAM

Post by tepples » Wed Aug 12, 2020 5:59 pm

tokumaru wrote:
Wed Aug 12, 2020 12:50 pm
Then maybe you should be looking into making it for a more capable console... :roll:
If NES is too weak and Super NES is too strong, what console are Goldilocks and Cubby using? Sega Master System and TurboGrafx-16 never sold well in anglophone markets. Japan and Brazil are sort of outliers: Japan because of its ideograms and Brazil because of its import substitution industrialization trade policy.
tokumaru wrote:
Wed Aug 12, 2020 12:50 pm
you can easily swap the 8KB CHR-RAM chip for a larger one (32KB chips should be easy to find) and bankswitch it like it was CHR-ROM. Support for this in emulators can vary (needs NES 2.0 header).
I recommend TGROM with the 8 KiB CHR RAM replaced with 32 KiB. Mesen and (nightly) FCEUX emulate this configuration fine, as does the version of the PowerPak MMC3 mapper that I use. To test other emulators, use MMC3 big CHR RAM test ROM. I was lead programmer for a game released on cartridge using this configuration.

User avatar
Controllerhead
Posts: 148
Joined: Tue Nov 13, 2018 4:58 am
Location: $4016
Contact:

Re: High quality images on the NES with MMC3 scanline interrupts and CHR-RAM

Post by Controllerhead » Wed Aug 12, 2020 7:50 pm

tepples wrote:
Wed Aug 12, 2020 5:59 pm
tokumaru wrote:
Wed Aug 12, 2020 12:50 pm
Then maybe you should be looking into making it for a more capable console... :roll:
If NES is too weak and Super NES is too strong, what console are Goldilocks and Cubby using?
78 'hundred =p
Image

calima
Posts: 1186
Joined: Tue Oct 06, 2015 10:16 am

Re: High quality images on the NES with MMC3 scanline interrupts and CHR-RAM

Post by calima » Thu Aug 13, 2020 12:13 am

To make an image for two sets of patterns, just split it in half and convert the halves separately using whatever techniques you're already using.

Post Reply