MM3 scanline counter, check multiple point possible and how?

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

User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: MM3 scanline counter, check multiple point possible and

Post by Bregalad »

Banshaku wrote:I guess latch is not easy to understand without an electronic background. Which kind of latch is the one on MMC3 then?
I didn't check but I'm fairly sure it's used as an equivalent to "register" or "D-flip-flops".
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MM3 scanline counter, check multiple point possible and

Post by lidnariq »

"latch" is a generic term.

"transparent latch" is the variant that holds values while disabled, and is transparent while enabled.
a "register" is the variant that gets a new value on one direction of clock edge
a "D latch" is underspecified, and could mean either
an "S-R latch" is one that has just "set" and "reset" inputs
a "J-K latch" is like an S-R latch but has a clock input, which is to say it's a kind of register.

As to how it's implemented inside the MMC3? Could be either, really. Inside a computer, a latch often will look like a register.
Banshaku wrote:I remember seeing that in the DOS days for VGA X-Mode where you have to unchain the latch or something like that (maybe I'm mixing wordds now ^^;;
To the best of my memory, there wasn't a latch specifically related of unchaining the planed memory. And what latches I remember there being were definitely the generic "it holds a thing" kind of latch rather than any narrower definition.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: MM3 scanline counter, check multiple point possible and

Post by Bregalad »

lidnariq wrote: a "D latch" is underspecified, and could mean either
What you said is probably correct except for this. A D latch is NOT a SR nor a JK, it is a very specific type probably equivalent to what you name "register". For some reason "registers" seems more often used when there's either more than 1 bit or when it's in a programmable logic development context. When it's outside of programmable logic and is a single bit, it's called a D flip-flop, even though it's the same thing as a register. Don't ask me why.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MM3 scanline counter, check multiple point possible and

Post by lidnariq »

a "D latch" could mean either a transparent latch or a register.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: MM3 scanline counter, check multiple point possible and

Post by tepples »

Is $2002 a "register" in this sense? Why or why not? Is the same true of $2000 or $2007?

In this post, koitsu was wondering why I often refer to memory-mapped I/O (MMIO) addresses as "ports". Your answer informs how I proceed with the explanation.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MM3 scanline counter, check multiple point possible and

Post by lidnariq »

$2002 is neither?

When the CPU reads from $2002, it's just using a tristatable buffer:
if both /r2002 and _io_ce are low, read_2002_output_spr_overflow is high.
if read_2002_output_spr_overflow is high, 3753 is low.
if 3753 is low, either node 522 pulls _io_db5 high, or node 3743 pulls _io_db5 low, depending on the current contents of spr_overflow .

Similar logic is present for spr0_hit.

Specifically the behavior of clearing the NMI flag:
if both /r2002 and _io_ce are low, read_2002_output_vblank_flag is high. This node in turn is part of an S-R latch, which is neither a transparent latch nor a register. The S-R latch is why reading from it at the exact same time as it would be turned on causes it to stay off.

Writing to $2000 and $2001 uses transparent latches, more or less. (It's implemented with transmission gates, so it's not the "normal" transparent latch. None the less, it's level-based instead of edge-based). While write_2000_reg is high, the data bus replaces the current value of the bits; while it's low, the feedback loop is closed and it retains the current value.

In general, I don't think I've seen many edge-triggered behaviors inside the NES; almost everything appears to be transparent latches using multiple nonoverlapping clock phases.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: MM3 scanline counter, check multiple point possible and

Post by Banshaku »

After reading all those comments I feel dizzy ^^;; I'm not ready yet to go that deep :lol: It's great to see those details though. I enjoy reading them even though I don't understand them properly ;)

As for the split, like talked in the IRQ thread, I'm not able to make a clean one yet. there is 2 possibility I see:

- I'm not doing it properly (duh)
- the surrounding code impede the mid-screen split because of some side effects I'm not aware yet

For now, I'm not sure which one is the cause. If there would be stub example for the MMC3, I could take that and try with some test data and see it is flicker the same way. I will try to build a basic stub but I'm not sure where I'm doing something wrong. Maybe I need to wait for the next scanline since my scroll spill in the next one, causing the jitters, not sure yet.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MM3 scanline counter, check multiple point possible and

Post by lidnariq »

What does Mesen's event viewer show?
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: MM3 scanline counter, check multiple point possible and

Post by Banshaku »

From memory, I see the "window" that shows where the nametable pointed jumping from 2000->2400, back and forth but somehow it seems un-natural (gut feeling only). After line 75, where the split occurs, some of the lines become dark like it is jumping again back and forth when it shouldn't so I'm starting to have a feeling that some of my C code may have some side effects that I'm not aware of.

Since this is realtime, it's not like I can put a break point and check the state of the code when it's runs at 60 frames per seconds. I guess I need some visual feedback which may be possible with mesen scripting but I didn't try that option yet but it may become necessary.

I still feel that first I need to test only that case without the surrounding code to see if I can make it work properly. Once I'm sure the code is right, it would become easier to debug the cause. Maybe I should test it first in asm only.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MM3 scanline counter, check multiple point possible and

Post by lidnariq »

No, that's specifically why I asked about mesen's event viewer. It visually shows exactly when the code is doing raster effects.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: MM3 scanline counter, check multiple point possible and

Post by Banshaku »

oh, sorry about that. I completely misunderstood your question ^^;;

I didn't know about that screen so first I need to learn how it works. Once I have a better understanding I will be able to answer your question. Thank you for showing me that screen! I guess I should test a simple split first to have a better idea about what is supposed to be shown there.

edit:

woah, that screen is very interesting! So much information about registers, colored pixel where event occurs, cycle it occurred, it's great! I just need to understand the details and that will help. My current broken (remaining random testing from yesterday) code for scrolling show that it writes after IRQ on cycle before 261 so NT change would be a no go. First I need to put back the code for my first visually bugged test to make it easier to understand.

edit2:

Found a few bugs that caused the first issue and now with fine x scroll I was able to do something close that I want for the second scroll (ye!). What is left is the final one, which is not working yet since more code is required. If you change fine scroll or ctr flags while palette is animated, sometime it seems to fail (or it is just a coincidence from a another bug).

Getting really happy with the results!
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: MM3 scanline counter, check multiple point possible and

Post by Banshaku »

Sorry for the double post.

@lidnariq

I'm starting to find the cause of my bugs. A lot of them are threads related since I'm not used to IRQ, C, ASM code all at the same time. It is pretty useful for light animation but I'm not used to the threading yet.

Another reason of the bug is I was requesting the IRQ after the music was played ^^;;; I didn't realize the impact since the first part had no music and everything was doing well.

What is left to figure out is if a split screen is running (scroll is still done mid-way to hide a part of the screen), it seems to affect the main thread when doing palette update in the NMI and I do not know why yet. I need to investigate that issue.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: MM3 scanline counter, check multiple point possible and

Post by lidnariq »

MMC3 counts A12 rises: palette updates involve writing to addresses where A12 is high. You need to initialize the MMC3 IRQ after all updates are done and you've set your top-of-frame scroll values.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: MM3 scanline counter, check multiple point possible and

Post by Banshaku »

When I saw your post it was in the middle of the night and didn't make much sense (too tired) so I waited before answering with would have been incomprehensible gibberish ^^;;;

Now if I understand well, since the count is done when A12 rise and palette affect A12 (which affect the address too), any address changing "outside" of the IRQ would affect the IRQ count in some way. And I could see that trying to change the palette mid-way would affect the counter then. There is one place that I would like to change only 1 color to fix an issue during a top screen part fade but it may be better to find another trick instead (this part is not done yet).

Right now my current issue is, my IRQ are sets so the VBLANK put top to specific position, the first IRQ change the X location mid-frame (around scanline 75) to hide a part that will be shown later. When PPU flags are set to ON, this IRQ is running, the palette is black and a fade in is requested. Unless I did not understood well, if the palette fade is done in VBLANK, the mid-screen scroll should not affect the palette or anything. Right now if I fade in in that situation, nothing is shown on the screen (fade didn't work or something else went wrong). Same thing for fade out, it doesn't occur.

I would be surprised that I cannot do palette change during vblank when IRQ is running so my first guess is to check the fade method that may be doing some direct hardware access, causing corruption along the way. Those methods have been done recently so they could be the culprit.
User avatar
Banshaku
Posts: 2417
Joined: Tue Jun 24, 2008 8:38 pm
Location: Japan
Contact:

Re: MM3 scanline counter, check multiple point possible and

Post by Banshaku »

I checked my code and the palette fade put the data in a buffer that will be executed on the next refresh so I don't know why yet palette action in NMI seems to create issue when the mid-screen scroll inside IRQ is fired. Hmmm...

edit:

I found the cause and it was related to the fade. When disabling the IRQ everything was fine. So I checked the code and then one point got my interest: I'm using the NMI counter incremented inside the NMI to calculate frames. What if for some reason the NMI reacted differently and causing issues? I switched to wait for VBlank instead of nmi counter and it started to work properly.

Now I will test the second IRQ (second split with bankswitching) and if it works then this thread will be finished then. Sometime some "error" or way of coding manifest their side effects in unusual ways ^^;;;

edit:

All splits working! I just have to be careful about events of scrolling/fading that may overlaps. Thanks everyone!
Post Reply