It is currently Thu Sep 19, 2019 11:41 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 340 posts ]  Go to page Previous  1 ... 19, 20, 21, 22, 23  Next
Author Message
PostPosted: Sat Feb 09, 2019 8:30 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 347
Location: Minnesota, USA
One potential issue is that my simulator is reading these addresses from PPU to simulate a new scanline:

$2000 (in range)
$2000 (matching)
$2000 (matching)
$0000 (not in range) <- IRQ observed here.

Whereas the real thing does this:

$2000 (in range)
$2000 (matching)
$2000 (matching)
$2xxx (AT read, in range, not matching)
$0000 (not in range) <- I think it should have IRQ here.

I will also check if this makes a difference to the extra scanline. I also plan to use a 74LS00 to make a bulletproof /ROMSEL signal.


Top
 Profile  
 
PostPosted: Mon Feb 11, 2019 11:33 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 347
Location: Minnesota, USA
I have modified my MMC5's PPU address bus setup today:

A0-9: All connected together to 1 digital output from microcontroller
A10-12: Always 0
/A13: Another digital output from microcontroller

This allows me to use these PPU addresses:

$0000 (Pattern table 0)
$2000 (Nametable 0)
$23FF (Attribute table 0)

and technically I could use PPU address $03FF (PT0), but no immediate use for that one. Will find some time this evening to try it.

Edit:
Additional hardware modification made today:

/ROMSEL used to be /A15. Now it is [A15 NAND M2] using a 74LS00 chip. This requires the code to send out A15 instead of /A15. Also, I put a toggle switch so I can change back easily.


Top
 Profile  
 
PostPosted: Mon Feb 11, 2019 1:16 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 347
Location: Minnesota, USA
We know that 3 PPU reads in a row from the same address are required to increment the scanline counter. We also know that the IRQ does not occur on the 3rd read, it has been observed on the 4th read.

My previous testing showed this:
1st read: in range $2xxx (tested $2000)
2nd read: matching 1st read (tested $2000)
3rd read: matching 1st read (tested $2000)
4th read: out of range. (tested $0000)

And the IRQ occurred on the 4th read. My testing today was to change the address of the 4th read. I replaced the 4th read with each of these addresses:

$0000
$2000
$23FF

All 3 of these addresses still caused the IRQ. Therefore, the 4th read does not care about the address matching, not matching, or in range. The IRQ then correlates to PPU cycle 4, confirming our previous understanding. Will make the appropriate adjustment to the wiki.

Edit:
New discovery: Can't detect scanline with 3 matching AT byte reads, i.e. 3 reads of $23FF in a row won't trigger scanline detection. :wink: It has to be in normal NT range. Will update wiki accordingly.

Edit :
I jumped the gun on that one. I had a setup issue with AT vs. NT, I had changed the $2xxx instead of the $x3FF part of the address. I will repeat this experiment more carefully later. When I made my change, I was no longer detecting scanlines, which was the basis that I thought the 3FF part mattered to the 3-in-a-row thing.


Top
 Profile  
 
PostPosted: Mon Feb 11, 2019 3:15 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 347
Location: Minnesota, USA
lidnariq wrote:
Quote:
asm(" repeat #12 \n\t nop "); // Setup Delay, so address bus is stable for MMC5 to register the read on M2 rising edge
How fast is this dsPIC running? in other words, how many ns is 12 nops?

My NOP delay is approx. 350nsec. M2 has a period of approx. 5 usec (200 kHz).


Top
 Profile  
 
PostPosted: Mon Feb 11, 2019 5:21 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 347
Location: Minnesota, USA
I have taken your feedback seriously and I am doing my best to review and reduce my text before posting. Also providing more pictures for clarity and to break things up.

In my test, I do 1 CPU read (i.e. M2 toggle) for every PPU read (i.e. PPU /RD toggle). On a real NES, I should be getting fewer M2 toggles with respect to PPU /RD toggles. This may be part of the explanation why I am able to have a skipped scanline when I have 4*N M2 toggles within my v-blank. Regardless if it is realistic or not, it may still prove to be insightful to internal operations of the MMC5. It is still 100% repeatable.

I tried a few experiments:
  • Everything done with /ROMSEL = CPU_A15 NAND M2 now instead of just using /A15. No difference found.
  • Triggering scanline detection this way: PPU read $2000, 2000, 2000, 23FF, 0000. Then loop that for each scanline. Can skip either 1, but not both, 23FF and 0000 for same behavior.
  • Changing any particular one of the M2 toggles during V-blank to read from $FFFA instead of $0000 had no effect, as long as the overall number of M2 toggles remained the same.
  • Same test, changing one of them to a write of $00 to register $2001, no effect, IRQ still generated, extra scanline at 4*N intact.
  • I added a PPU read during one of the points in time that M2 was low during v-blank. This did change the offset of the 4*N. I had to add/subtract CPU reads after it to get back in sync with the 4*N again. Then if I bumped this PPU read up one spot (to occur after the next CPU read) then I had to add 1 additional CPU read after this to compensate and get the skipped scanline again.

Realistically, though, wouldn't the PPU's V-Blank have an identical number of M2 toggles each time? The extra/missing PPU idle cycle happens between the prerender scanline and scanline 0, so that might theoretically be ignored by this 4*N logic. To me, this kind of points back to NTSC vs. PAL detection, and skipping an extra scanline with PAL for example. Or maybe something having to do with the 4 different power-on states of M2 clock vs PPU clock? I am not really sure how this could be a setup problem anymore.

Scope shots:

Normal:
Attachment:
no_extra_scanline.png
no_extra_scanline.png [ 45.32 KiB | Viewed 6212 times ]


Extra Scanline:
Attachment:
extra_scanline.png
extra_scanline.png [ 45.86 KiB | Viewed 6212 times ]



Next, I simulated full scanlines, instead of tricking the MMC5 with the least possible number of steps. A full scanline was simulated like this:

A. V-blank CPU $0000 reads, number of reads 4*N adjusted to find extra scanline.
B. PPU read $2000, 2000
C. PPU read $2000, 23FF, 0000, 0000.
D. Loop to C 42 times. (# of fetch sequences per scanline)
E. Loop to B 241 times. (# of scanlines)
F. Loop to A infinite times

Same behavior:

Was able to immediately detect scanline (3/4 M2s):
Attachment:
tek00080.png
tek00080.png [ 48.8 KiB | Viewed 6212 times ]


Could not immediately detect scanline (1/4 M2s):
Attachment:
tek00081.png
tek00081.png [ 48.06 KiB | Viewed 6212 times ]



If I skip step B for the pre-render scanline (like a real NES, i.e. scanline 260 does not end in the extra NT fetches), it never misses a scanline.

Note: Edited text above.


Top
 Profile  
 
PostPosted: Mon Feb 11, 2019 7:06 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8559
Location: Seattle
Ben Boldt wrote:
Realistically, though, wouldn't the PPU's V-Blank have an identical number of M2 toggles each time?
Yes, but I don't think the math follows? They also won't all be reads. We know that MMC5 works correctly on 2C02, 2C07 and I'm about 90% certain I've heard someone mention it work on the UA6538 also.

Vblank on 2C02 is (262-241)*341/3 = 2387cy ; ÷4 = 596 ; %241 = 114
Vblank on 2C07 is (312-241)*341/3.2 = 7565cy ; ÷4 = 1891 ; %241 = 204
Vblank on UA6538 is (312-241)*341/3 = 8070cy ; ÷4 = 2017 ; %241 = 89

so while it's conceivable that there's a special compensatory mechanism, it's far more likely that you're tickling undefined behavior.

Also, PPU/RD isn't doing anything during vblank, so it's not like there's any clock source for the MMC5 other than its internal 10µs timer and the CPU's 1.7-1.8MHz M2.

Quote:
no_extra_scanline.png
Oh, hm. Your test always asserts M2 only during a read. In practice, M2 is high for almost two pixels, so sometimes the two buses shouldn't align.

It does seem unlikely that that could be what's wrong, however.

Quote:
If I skip step B for the pre-render scanline (like a real NES, i.e. scanline 260 does not end in the extra NT fetches), it never misses a scanline.
So it looks like there's something being caught there that explicitly copies the scanline # over when the MMC5 detects the pre-render scanline, and you're getting some kind of uninitialized state here otherwise?


Top
 Profile  
 
PostPosted: Mon Feb 11, 2019 8:15 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 347
Location: Minnesota, USA
lidnariq wrote:
so while it's conceivable that there's a special compensatory mechanism, it's far more likely that you're tickling undefined behavior.

I agree with that completely.

The issue that we are seeing here is caused by a completely unnatural condition -- basically I have generated the 2 dummy nametable reads right before the prerender scanline, that are not normally there. Depending on the number of M2 toggles before these extra nametable reads, it may or may not trigger the scanline counter. Every 4th M2 toggle added does not trigger the scanline counter, the others do.

Our diagram explains the way that the in-frame status bit works. I believe strongly that there should be a way to converge the scanline counter's behavior with the status bit's behavior into 1 simple diagram, and ultimately into 1 accurate concise explanation.


Top
 Profile  
 
PostPosted: Thu Feb 14, 2019 2:32 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 347
Location: Minnesota, USA
Still not able to fit everything we know together in a simple/realistic way. I have a couple more tidbits from today.

I am able to take an additional shortcut getting the MMC5 to detect scanlines. If I do PPU reads always from address $2000, repeating, I get:

Read 1 (Matching 1)
Read 2 (Matching 2)
Read 3 (Matching 3)
Read 4 -> Scanline detected
Read 5 -> Another scanline detected
Read 6 -> Another scanline detected, etc.

Even with this shortcut, the first scanline is detected on Read 5 each 4*N number of M2s before Read 1.

Another note: I noticed on the "241st Scanline reset" thing, IRQ goes high on the RISING edge of PPU /RD. This my first observed action triggered from rising edge PPU /RD.
Attachment:
tek00082.png
tek00082.png [ 39.68 KiB | Viewed 6006 times ]


Something to consider: 'in frame' status bit might get set on scanline 0, however it is not ever possible to generate IRQ on scanline 0. There could be something lurking between scanline 0 detection and scanline 1


Top
 Profile  
 
PostPosted: Thu Feb 14, 2019 4:07 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 347
Location: Minnesota, USA
New discovery today.

Right when I enter the simulated V-Blank, I tried 1 additional PPU read, so I could easily control the address of the last PPU read before the series of M2 toggles. If the last PPU read was $2000, and then 3 M2 rising edges occur, it clears the IRQ, as we knew. But if I change the last PPU read to $23FF, $0000, or $03FF, it NEVER clears IRQ from M2. I tried 1000 toggles, /IRQ stayed low. I also made sure to try v-blanks with fewer than 241 scanlines between to make sure I wasn't conditionally triggering that function somehow. It made no difference.

This makes sense though -- the last thing the PPU does before V-blank is a dummy NT read from scanline 239, cycle 340. So the MMC5 sees this, then if there are 3 M2 rising edges in a row without any PPU reads, that is how it knows it is 'not in frame'. It doesn't explain the 1 in 4 thing we are seeing. One more piece of the puzzle though.


Top
 Profile  
 
PostPosted: Thu Feb 14, 2019 4:57 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8559
Location: Seattle
So ... that means we should be able to get wacky results on hardware if we turn of rendering using a mirror of the PPU's registers at exactly the right time?


Top
 Profile  
 
PostPosted: Thu Feb 14, 2019 5:19 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 347
Location: Minnesota, USA
lidnariq wrote:
So ... that means we should be able to get wacky results on hardware if we turn of rendering using a mirror of the PPU's registers at exactly the right time?

Concerning the MMC5 itself sniffing register $2001, I haven't actually seen any effect to the scanline counter when I do a write $00 to CPU address $2001. Is that what you are referring to? I have tried it and I do not believe it clears the scanline IRQ or resets the counter or anything like that.


Top
 Profile  
 
PostPosted: Thu Feb 14, 2019 5:32 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 347
Location: Minnesota, USA
I just did another experiment. With this 'last' PPU read before the M2 toggles. Before, I just left the PPU address bus intact with the address I was testing, so we didn't really know if it was latching the last PPU address on PPU/RD falling edge, or if it was still reading and using the address that's out there on the bus.

I tested by setting PPU address = $2000, PPU /RD low, then high, then changing PPU address to $0000 before proceeding to the M2 toggles. It still cleared the IRQ after the 3rd rising edge of M2 after this. SO, it does latch the fact that the last address was an NT byte, and not an AT byte or PT byte. It seems reasonable that it always keeps track of the entire previous PPU address for the purpose of finding matches anyway.


Top
 Profile  
 
PostPosted: Thu Feb 14, 2019 5:37 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8559
Location: Seattle
The in-frame flag doesn't directly affect IRQs?


Top
 Profile  
 
PostPosted: Thu Feb 14, 2019 6:33 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 347
Location: Minnesota, USA
lidnariq wrote:
The in-frame flag doesn't directly affect IRQs?

Are you saying that the in-frame flag clears when you write $00 to $2001? I think I missed that earlier - was that something krzysiobal found? I have not found $2001 to have any effect on scanline IRQ counting / setting / clearing so far but I should take another look.

It could be a 1-way street for scanline detection to trigger setting the in-frame flag but not the other way around.


Top
 Profile  
 
PostPosted: Thu Feb 14, 2019 6:39 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8559
Location: Seattle
I think krzysiobal found it also, but blargg mentioned something that looks awfully similar a little while ago


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 340 posts ]  Go to page Previous  1 ... 19, 20, 21, 22, 23  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: chimaera and 3 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