It is currently Sat Nov 18, 2017 7:14 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 41 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Mon Sep 25, 2017 6:16 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
Firstly, tepples is correct.
Next, it's surprising you don't know the MMC3 IRQ logic. ALL the info I got came from Disch, and some details from blargg's test ROMs. Again, it's a big surprise to me of how most of you don't even know about the MMC3 IRQ logic - a CHANCE of A12 rising at PPU dot 260, 268... at every 8 dots due to the sprite fetches, then at 4,8,12... on PPU background fetches.

Now, if you have any questions, please, contact Disch. I'm not the right person for it. Sorry for the trouble.


Top
 Profile  
 
PostPosted: Mon Sep 25, 2017 6:21 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
infiniteneslives wrote:
Quote:
the IRQ counter should decrement on PPU cycle 260,268,276... or 315


I still fail to see how you came up with those numbers from disch's docs... What's your logic behind all this?

Did you read the Disch's doc? Here's a quote.
Code:
This 8-dot sequence is repeated for each tile.. meaning there are 42 opportunities for A12 to rise.  These
opportunities occur on the following dots:

4, 12, 20, ..., 244, 252                 (32 BG tiles)
260, 268, 276, 284, 292, 300, 308, 316   (8 Spr tiles)  <<-- HERE!
324, 332                                 (2 BG tiles)

Quote:
No one here understands your wiki edits, and when asked, you're telling us to guess and dumping worthlessly dumping disch docs. Are you intentionally trying to make this some sort of puzzle?

"No one"? It's a shame to read that. :oops: :oops: Does it always happen... or just for you? ALL my edits take information from HERE. All the "incomprehensible" edits were taken from HERE. I'm really upset now... sorry. :? :oops: :cry:


Top
 Profile  
 
PostPosted: Mon Sep 25, 2017 7:32 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19222
Location: NE Indiana, USA (NTSC)
calima wrote:
The current wiki is wrong. My test ROM showed that the repro MMC3 chip fired on pixel 315, just like mednafen or the previous wiki description.

The ROM is using $0000 for bg and $1000 for sprites.

8x8 or 8x16? Because pixel 315 sounds like you're putting seven 8x16 pixel sprites from $0000-$0FFF in front of either one 8x16 pixel sprite from $1000-$1FFF or one empty secondary OAM location.

Which "repro MMC3 chip" are you talking about?


Top
 Profile  
 
PostPosted: Mon Sep 25, 2017 8:56 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1919
Location: WhereverIparkIt, USA
Sorry to have upset you, it wasn't my intention. Part of my confusion is lack of clarity of the original statement. "260,268,276... or 315"

What's the ... about, are there numbers in there you're not listing? 315 isn't on disch's list.

If there isn't much of an explanation as to why or how one gets the IRQ to fire at those times, randomly listing some of the potential times isn't helpful. In some place like the wiki it makes more sense to explain what rules must be followed to get IRQs to fire at 260. We could have practically an entire wiki page devoted to when it will fire if those rules aren't followed.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Mon Sep 25, 2017 10:22 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6440
Location: UK (temporarily)
calima wrote:
The current wiki is wrong. My test ROM showed that the repro MMC3 chip fired on pixel 315, just like mednafen or the previous wiki description.

The ROM is using $0000 for bg and $1000 for sprites.
*shrug* The MMC3 IRQ hardware is known to use this signal for its clock: a rising edge of PPU A12 after PPU A12 has been low for at least 6 pixels.

If you're seeing it assert on pixel 315, I don't know what you're doing, but there's something suspect. Maybe just how you're counting pixels. Maybe your fine X scroll value.

Per the timing convention in this timing diagram: https://wiki.nesdev.com/w/index.php/Fil ... timing.png the IRQ should be asserted on cycle 261 (the first pattern table fetch during the sprite fetch portion) or on cycle 325 (the first pattern table fetch during the background fetch portion)


Top
 Profile  
 
PostPosted: Mon Sep 25, 2017 10:40 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1919
Location: WhereverIparkIt, USA
lidnariq wrote:
The MMC3 IRQ hardware is known to use this signal for its clock: a rising edge of PPU A12 after PPU A12 has been low for at least 6 pixels.


I believe it's more accurate for the amount of time PPU A12 must be low to be referenced to CPU M2 clock cycles, but I agree that's more confusing..

This is all part of why MMC3 is considered so complex. It's not the mapper hardware is that complex, it's the signals that drive the mapper which are complex. The chip must sense scanlines via signals it has available to it (mainly PPU A12, and also CPU M2 for a sense of time). Thus one must have a strong grasp of the PPU and CPU signals and their timing to fully understand when to expect an IRQ to fire.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Mon Sep 25, 2017 11:04 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 581
tepples wrote:
8x8 or 8x16? Because pixel 315 sounds like you're putting seven 8x16 pixel sprites from $0000-$0FFF in front of either one 8x16 pixel sprite from $1000-$1FFF or one empty secondary OAM location.

Which "repro MMC3 chip" are you talking about?

8x8. I believe it was Retrostage's board.

Quote:
If you're seeing it assert on pixel 315, I don't know what you're doing, but there's something suspect. Maybe just how you're counting pixels. Maybe your fine X scroll value.
It's completely reproducible, and the ROM does nothing weird. There is no scrolling. And emulators also act that way.

I counted pixels by counting cycles and then multiplying by 3.


Top
 Profile  
 
PostPosted: Mon Sep 25, 2017 11:26 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3075
Location: Brazil
Just to clarify the things, please, read here and here.


Top
 Profile  
 
PostPosted: Mon Sep 25, 2017 12:02 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6440
Location: UK (temporarily)
Having looked closely in the test ROM:

The IRQ is PHA, 20 NOPs, then 24 cycles of LDA #imm STA 2006/5/5/6. This should take 201 pixels. (How did Calima get 195?). edit: Plus it takes 7 cycles to enter an IRQ (Total: 222 pixels). Additionally, because this changes the scroll location instead of something with less latency (like emphasis), there's another 16-ish pixels of latency afterwards.

Additionally, the IRQ interrupts a "CMP zp; BEQ rel" loop so there's up to 3 CPU cycles = 9 pixels of jitter in the resultant IRQ timing.

If I change the 2006/5/5/6 write sequence to one that instead sets the greyscale bit at the same time as the original final 2006 write, the edge moves ≈20-12 pixels to the left, as expected.

All emulators finally display the updated scroll somewhere around on-screen coordinate (160), meaning that the IRQ was asserted somewhere around on-screen pixel (260). So, there you go: your test shows that IRQ is asserted on pixel 260, as previously stated.

calima wrote:
The current wiki is wrong. My test ROM showed that the repro MMC3 chip fired on pixel 315, just like mednafen or the previous wiki description.
An awful lot of people who are at least as smart as you and many of whom have tremendously greater domain knowledge have put an awful lot of effort into documenting things. Some of them are still present. A little humility would serve you well.


Top
 Profile  
 
PostPosted: Mon Sep 25, 2017 11:48 pm 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 581
Zepper is one of them, having made a successful Windows emulator, and the original documentation was his.

You are correct that I made a mistake in that I didn't count the 7 cycles to enter an IRQ. However you also made a mistake, there are 19 nops, not 20.

PHA = 3
19 NOPS = 19 * 2
4 LDA #imm = 2 * 4
4 STA ABS = 4 * 4

3 + 19*2 + 2*4 + 4*4 = 65
65 * 3 = 195


Top
 Profile  
 
PostPosted: Mon Sep 25, 2017 11:57 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6440
Location: UK (temporarily)
And you misinterpreted it, and you doubled down when you were told you had misinterpreted it.

Nothing in Zepper's original documentation obviously meant "there are 8 physical variations of the MMC3". That's all on you.

When the options are "Maybe Calima can't count" or "Maybe everyone else is wrong", you should seriously consider the former.

And when you retaliate with nitpicking? That just makes you look like a petty fool.


Top
 Profile  
 
PostPosted: Tue Sep 26, 2017 12:15 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 581
You respond to a post proving you can't count with "calima can't count" :D

edit: I'm sorry, this was unnecessary. However, you made the same kind of mistake you accused me of, without admitting yours. What is that if not petty?


Top
 Profile  
 
PostPosted: Tue Sep 26, 2017 1:36 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 581
On the topic of unclear docs, the Scrolling page says:
Quote:
Because this method sets v immediately, it can be used to set the scroll in the middle of the line. This is not normally recommended, as the difficulty of exact timing and interaction of tile fetches makes it difficult to do cleanly.
And
Quote:
By writing twice to $2006, the second write causes an immediate full reload of v from t, allowing you to update the vertical scroll in the middle of the screen.

According to lidnariq, the change only becomes visible 1-2 tiles later. Can somebody with wiki rights correct that page?


Top
 Profile  
 
PostPosted: Tue Sep 26, 2017 6:22 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19222
Location: NE Indiana, USA (NTSC)
The effect on fetches is immediate. The effect on actual output pixels is delayed until the already-fetched pattern data passes through the shift registers that decode planar tile format and perform fine scrolling.

Requests for edits like this to address cross-cutting concerns everywhere, such as how the timing of mid-scanline v changes interacts with the pixel decoding and fine scroll processes, are part of how the wiki becomes more verbose and harder for a novice to read.


Top
 Profile  
 
PostPosted: Tue Sep 26, 2017 10:27 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6440
Location: UK (temporarily)
calima wrote:
However, you made the same kind of mistake you accused me of, without admitting yours. What is that if not petty?
My problem is not that you made a mistake.

It's that, when told you had made a mistake, you insisted you hadn't, requiring that I look inside the details of what you had done to prove the specifics of the mistake.

When you retaliate with "I made a mistake, but you ALSO made a mistake"— That's what's petty. That's a false equivalence, because I wasn't using the exact calculation to conclude something that was untrue.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 41 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group