Demonstration of translucency

Well, I was going to make a post asking for help, but I solved the problem right before I would have made it.

So, I created translucency in BG mode 1, with 16x16 tiles. BG1 is the main window and BG2 is the subwindow. BG1 tile map is at VRAM $0000, while its tile CHR is at $1000. BG2 tile map is at $0800, and BG2 tile CHR is at $2000. Frame 2 for BG2 tile CHR, so far unused, will be at $3000. I will set up the animation.

One thing I learned on this project is that when you load the tile map, always assume the map is 64x64 even if it's not. (EDIT: Another thing I learned is you must always set up the scroll values, even if your game doesn't scroll, that way they are all set to 0.)

The files, including screenshot and project files, are attached.

Here is the video setup code:

OK, now I've added animation. This is the NMI:



I did "stz $10" in the main vector just before it goes into its infinite loop.

I'm going to assume you're using NMI with VBlank properly (vs. waiting around in a loop polling $4210 bit 7 to detect VBlank), given your other post.

Your NMI vector routine needs an 8-bit read of $4210 at the very start (ex. lda $4210 assuming accum is 8-bit). I'm not sure if this will solve your problem, but it's quite possible (and should be done anyway!).

I would also suggest, given your quote "(EDIT: Another thing I learned is you must always set up the scroll values, even if your game doesn't scroll, that way they are all set to 0.)", is that you actually follow the official register initialisation procedure per the official manual (chapter 26, Register Clear). It's very possible you aren't pre-initialising SNES registers properly (note this, obviously, doesn't pre-zero or pre-initialise RAM contents or anything else -- that's for you to do. I'm talking just about MMIO registers). This should be done in your RESET vector routine.

Also, if you're using bsnes as your test emulator, know that the emulator intentionally pre-initialises register values and RAM with bogus values, which can often lead to problems if your code does not properly initialise or zero things (registers, RAM, etc.) in advance. This has been discussed many times over. It isn't an emulator bug -- if anything, byuu's choice to do this often results in people finding these types of bugs in their program. :-)

(2018/08/29 Edit: attachments removed.)

koitsu,

I appreciate your post, but I had already gotten it working on NO$SNS and Geiger's SNES debugger thingie. The only thing I had neglected, was the $4210 read at the beginning of the NMI (though why this is required is beyond me). It works in bsnes.

So the version with both the .sfc extension (as that is the only extension bsnes will accept) and the .smc extension, are attached.

And yes, it works.

Preface: HARDWARE FOLKS, PLEASE CORRECT ME IF I'M WRONG OR DESCRIBE THIS INACCURATELY. lidnariq, I'm lookin' at you ;-)


The explanation is semi-complicated and involves understanding a little bit about how the actual hardware works. I understand "part" of how it works, but myself have questions. The NES suffers from the same phenomenon (sort of), however see the very last paragraph of this post for a "hmm, maybe the SNES does something different/unique". I'll provide references for my statements as well.

NMI on the 6502/65c02/65816 is a "edge-sensitive" or "edge-triggered" signal connected via a physical trace between the NMI pin on the CPU and the PPU (I don't remember on the SNES if it's PPU1 or PPU2, but it's irrelevant in understanding the behaviour). The signal is digital, so it only has two states: high (1) and low (0).

NMI is what's known as a "falling edge", which means the signal must transition from high to low (1 --> 0) for the CPU to run code at your NMI vector. Low to low (0 --> 0), high to high (1 --> 1), and low to high (0 --> 1) all do nothing. (Educational: in contrast, "rising edge" would mean the signal must transition from low to high (0 --> 1) for something to happen).

As such, it's presumed the PPU keeps the signal high (1) as a default -- keep reading.

When $4200 bit 7 is set to 1 (the trigger-NMI-on-VBlank bit), when VBlank happens, the PPU sets the signal to low (0). Thus, the high --> low transition causes NMI to happen within the CPU, and it runs code starting at the NMI vector.

Following so far? Maybe a bit complex and into the hardware level of things, but it should make sense.

For the PPU to essentially "reset" back to its default state -- make the PPU keep the signal high (1) again -- one must read register $4210 to essentially "reset the latch".

Failing to read $4210 in your NMI routine would therefore mean the signal would remain in low (0) state perpetually -- which, to me, means no more NMIs would fire (i.e. it happens once and that's it). However, what I've seen stated repeatedly is that failure to do this can cause "NMI to fire multiple times" (I don't understand how that would happen because I'm not a hardware guy).

There are at least two documents that outline NMI behaviour with VBlank on the SNES (I haven't looked at nocash's, but there's probably useful stuff in there too). Here are those:

Charles MacDonald's documentation says the following, emphasis mine:


Anomie's SNES timing doc says this, emphasis mine:


So if the PPU itself is resetting NMI to high (1) when it begins to draw the pixel at 0,0 then why do Nintendo's docs say one must read $4210 else risk duplicate NMIs -- and how would you risk getting more than one?

Both can potentially be explained by details about the NES.

The nesdev Wiki, and this is for the NES specifically, has a write-up about this behaviour, specifically how NMI can end up occurring multiple times. PPUCTRL ($2000) in that Wiki page would be essentially $4200 on the SNES, and PPUSTATUS ($2002) would essentially be $4210 on the SNES. On the NES, you need to read $2002 and write to $2000 to "truly" get the PPU to re-set the NMI signal back to high (1). On the NES, I don't think when H=0 and V=0 does the NES PPU set NMI to high (1) automatically.

So I'm left to believe that the comments in the official SNES documentation are a kind of "learned behaviour" from the NES days, where you had to "do extra stuff" to essentially get the PPU to reset the NMI signal to high (1). Nintendo may have alleviated all that nonsense by simply having the PPU set NMI to high (1) itself when drawing pixel 0,0.

Long-winded answer, but it's the best I got. If someone else has more concrete details or explanations, I'd love to hear 'em.

Edit: it looks like nocash's documentation sort of confirms my suspicions, but actually explains how "multiple NMIs" could happen if you don't read $4210. From http://problemkaputt.de/fullsnes.htm#snesppuinterrupts talking about $4210, emphasis mine:

So yeah, it looks like Nintendo alleviated the annoyance that stemmed from the NES days by doing things differently, but also added that you should read from $4210 for a particular unique case (if you were to set bit 7 of $4200 to 0, then later set bit 7 of $4200 to 1, without reading $4210 in your NMI routine, you could risk re-executing your NMI routine).

Hardware is a weird beast.

It's actually the same in both the SNES and NES.

In the NES, during vblank, if you haven't read $2002 and you write 0 then $80 to $2000, you'll get another NMI.
In the SNES, during vblank, if you haven't read $4210 and you write 0 then $80 to $4200, you'll get another NMI.

The more likely version of both of these flaws is "NMI is disabled, you enable NMI during vblank, you immediately get an NMI that may not have enough time to do a full upload"

In the NES, the NMI flag is cleared at the same time as everything else (the sprite overflow, sprite 0 hit, and the "you can't usefully talk to the PPU right after reset" behavior), which I think is coordinate (0,-1)