It is currently Tue Feb 19, 2019 4:42 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 334 posts ]  Go to page Previous  1 ... 17, 18, 19, 20, 21, 22, 23  Next
Author Message
PostPosted: Tue Jan 29, 2019 12:54 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 852
I have just captured the video output of Just Breed, running my cartridge of the game on the Sharp Twin Famicom AN-505BK, using my custom setup that allows me to capture the raw NTSC output before any capture card or software messes with it. This is necessary because most capturing software by default crops the very first NTSC scanline. And the result:
Attachment:
JustBreed1.png
JustBreed1.png [ 66.14 KiB | Viewed 798 times ]

Attachment:
JustBreed2.png
JustBreed2.png [ 273.95 KiB | Viewed 798 times ]

Note the two garbage lines in the top left corner. They are not seen in non-MMC5 games using this capturing setup.

Yes, the MMC5 does output garbage tiles for the first two tiles on scanline 0 in this game, because the "in-frame" flag only gets set after the two garbage nametable fetches on the pre-render scanline, which follow the fetches for tiles 0 and 1, and the "in-frame" flag affects which CHR banks are mapped. This might be considered a test for any emulator that implements the scanline/in-frame detector.

I have also attached my raw captures so nobody can say that I messed with the .png files to create a desired result or something.

Edit: Oh, and the slightly jumpy split in Metal Slader Glory seems to occur on real hardware as well (https://youtu.be/jMUobWk4Qbg?t=38).
Edit 2: I forgot that Just Breed disables rendering in the left eight pixels via $2001. This means that there are actually three garbage tiles, meaning that the CHR bank switch that is triggered by setting the in-frame flag does not occur until after the third tile at cycle 1 has been fetched.


Attachments:
JustBreed-rawcaptures.7z [222.09 KiB]
Downloaded 13 times
Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 4:37 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
NewRisingSun wrote:
I am not quite sure though why we need a simulator to write a few lines of text. That seems more like complicating things instead of simplifying them.

I think I made it sound more fancy than it really is.

Attachment:
ppu_sim.png
ppu_sim.png [ 17.23 KiB | Viewed 768 times ]


I guess I kind of need it for my own understanding. I feel like I have very little grasp on the PPU's operations and this would make it easier. It will not be a very complicated simulation. I already did most of it; it basically it shows all of the boxes from the Wiki's timing diagram and it blinks the box that you are on. It lets you step PPU cycles and also has a timer to auto-step PPU cycles so you can just watch it. I will see if I can get it finished tonight.


Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 4:43 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 852
Okay, but keep in mind that the timing diagram is wrong from cycles 258-320, as mentioned earlier.

Edit: Or maybe it's not wrong at all, just confusing as hell. Instead, the two top graphs apparently are supposed to describe background rendering only, and the bottom graph is supposed to describe the sprite rendering? My god, how confusing. That's why I never use diagrams.


Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 6:47 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
NewRisingSun wrote:
Okay, but keep in mind that the timing diagram is wrong from cycles 258-320, as mentioned earlier.

Edit: Or maybe it's not wrong at all, just confusing as hell. Instead, the two top graphs apparently are supposed to describe background rendering only, and the bottom graph is supposed to describe the sprite rendering? My god, how confusing. That's why I never use diagrams.

Well, for better or for worse, we have all sorts of different strange people that like NES and some of them are completely lost without diagrams. :mrgreen:

I got some things going with the simulator thing. It does scanlines 0-239 but still does not simulate the cyan areas. As soon as it gets to the cyan area, it sets it to "not in frame" and locked. Please have a look and see if you can find any problems. I will still need to think about the cyan area, I do not understand it yet.

The attachment is a MS Visual studio project. You can either open it in Visual Studio to run it, or you can run the pre-built EXE if you dig down to:

\PPU MMC5 Sim\PPU MMC5 Sim\bin\Debug\


Attachments:
PPU MMC5 Sim.zip [71.41 KiB]
Downloaded 15 times
Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 7:46 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
Is there any place during scanlines 0 - 239 where there could be 3 M2 cycles without any PPU read cycles? I am really stuck because it looks to me like it reads on every single even cycle until scanline 240. During the cyan sprite area, it has the gargabe NT and AT cycles but I think those are reads even though they are garbage. PPU /RD would go low, garbage or not.


Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 7:51 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8141
Location: Seattle
You're correct, every scanline is 171 pixels of /RD high and 170 pixels of /RD low. The one stutter is at the "idle" pixel on the diagram.


Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 9:41 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
lidnariq wrote:
You're correct, every scanline is 171 pixels of /RD high and 170 pixels of /RD low. The one stutter is at the "idle" pixel on the diagram.

I think that idle cycle is the key. Here is how I think these signals work:
Attachment:
timing.jpg
timing.jpg [ 298.85 KiB | Viewed 714 times ]

If I understand this right, it looks like the in-frame bit gets cleared for only a very short time after the idle cycle during each scanline 0-239. Then presumably for scanlines 240-260, in-frame remains cleared the whole time.

Based on this, I would say that the scanline counter increments and IRQ generated at the first AT byte read of each scanline. There may be corner conditions for the first scanline and pre-render scanline where my simulator can come back to help us.

It seems intuitive that the scanline counter would increment, leading to IRQ, each time that "in-frame" status bit gets set to 1. But to my knowledge, we have never confirmed that isn't actually happening when the status bit gets set to 0. If my drawing is correct, it might make more sense to increment and IRQ based on when the status bit becomes 0. I will see if I can check that soon, but I am staying home tomorrow due to extreme cold temperatures.


Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 10:48 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8141
Location: Seattle
Ben Boldt wrote:
Based on this, I would say that the scanline counter increments
No, we already know that. It's from when the PPU fetches the same exact address from the upper half of the space three times in a row. Everything else comes from that...

There's no good way to detect the idle pixel without a much faster clock than M2. (Incidentally, the idle pixel is approximately right on the left edge of the visible frame. It happens after the first two slivers of background tile data have been fetched)

... why do you think the MMC5 goes "out of frame" every scanline?


Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 11:26 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
lidnariq wrote:
from the upper half of the space three times in a row.

I am sorry, I just do not follow. What do you mean by upper half? Could you take a screenshot of the PPU diagram and circle the spot where this happens?

lidnariq wrote:
... why do you think the MMC5 goes "out of frame" every scanline?

It was my understanding that the scanline counter increments each time that the 'in frame' status bit toggles and that someone had not picked the best name for this status bit. My state diagram explains specifically the operation of the 'in frame' status bit. I created the diagram by looking at the status bit, not by setting up IRQs and waiting for them to happen due to the scanline counter incrementing. In hindsight, and to your point, I never tested or confirmed any connection between the status bit and the IRQ. Maybe there isn't any?? I was so sure of that...


Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 11:30 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 852
lidnariq wrote:
why do you think the MMC5 goes "out of frame" every scanline?
He wrote that he got that idea from that confusing PPU timing diagram on the wiki, because of those large blue-shaded areas in that diagram.
Ben Boldt wrote:
Please have a look and see if you can find any problems.
Sorry, but no. All I wanted is a short text description and pseudo-code of those two state diagrams, simplified from the abstract "state machine" terminology. Now I am looking at those same diagrams, plus a confusing PPU timing diagram, plus an MS Visio project of a PPU simulator. That is exactly what I did not want.

I have my MMC5 emulation working nice and well based on my limited understanding of those state diagrams, which have laid out in my pseudo-code, and it has turned out to be correct enough to run all games well, both in terms of IRQ, scanline split, and even scanline-0 graphical artifacts. That is all I needed.


Top
 Profile  
 
PostPosted: Tue Jan 29, 2019 11:51 pm 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
NewRisingSun wrote:
lidnariq wrote:
why do you think the MMC5 goes "out of frame" every scanline?
He wrote that he got that idea from that confusing PPU timing diagram on the wiki, because of those large blue-shaded areas in that diagram.

That actually is not where I got the idea, and I am not yet sure that it is incorrect.

NewRisingSun wrote:
Ben Boldt wrote:
Please have a look and see if you can find any problems.
Sorry, but no. All I wanted is a short text description and pseudo-code of those two state diagrams, simplified from the abstract "state machine" terminology. Now I am looking at those same diagrams, plus a confusing PPU timing diagram, plus an MS Visio project of a PPU simulator. That is exactly what I did not want.

I have my MMC5 emulation working nice and well based on my limited understanding of those state diagrams, which have laid out in my pseudo-code, and it has turned out to be correct enough to run all games well, both in terms of IRQ, scanline split, and even scanline-0 graphical artifacts. That is all I needed.

I am actually being a little bit selfish here NewRisingSun, I am doing this also very much for my own understanding, which is very lacking at the moment. I think I am looking for a complete explanation that exceeds what is necessary for what you are doing, and then working back from that proven full understanding to the simpler type of explanation you are looking for, instead of taking liberties and jumping directly to a simple "good-enough" solution. Our goals are different, and I would not ask to drag you through my lengthy process if you aren't interested.

Also, I am not sure how M2 synchronizes with PPU /RD. Does my hand-drawn picture look correct how these are synced up? I will check it eventually with my scope.

Also, lidnariq - you refer to each PPU cycle as a 'pixel', it seems that each cycle is a row of 8 1-bit pixels. Is this what you meant or is my understanding incorrect on this?


Top
 Profile  
 
PostPosted: Wed Jan 30, 2019 1:13 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 852
Ben Boldt wrote:
That actually is not where I got the idea
You wrote: "I am working through the frame timing diagram here:", followed by: "Then in the range 257-320, it quickly becomes not-in-frame because there are M2 cycles and no PPU /RD cycles." No. There are PPU /RD cycles throughout that area, as shown by the lower part of that diagram. Your conclusion that the PPU goes out-of-frame each scanline is wrong as a consequence. The PPU never stops reading until the end of scanline 239, or if the software disables rendering by writing to $2001.
Ben Boldt wrote:
instead of taking liberties and jumping directly to a simple "good-enough" solution
I am not taking any "liberties" or "jumping to solutions". I make things as simple as possible, and as complex as necessary.


Last edited by NewRisingSun on Wed Jan 30, 2019 4:31 am, edited 3 times in total.

Top
 Profile  
 
PostPosted: Wed Jan 30, 2019 1:48 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8141
Location: Seattle
Ben Boldt wrote:
I am sorry, I just do not follow. What do you mean by upper half? Could you take a screenshot of the PPU diagram and circle the spot where this happens?
We already know that the MMC5 counts its IRQ counter if

* The PPU fetches address X, where X ≥ $2000
* The PPU fetches address X again
* The PPU fetches address X a third time

Only after the third step is this sufficient to clock the IRQ counter.

We've known the horizontal timing for more than a decade: viewtopic.php?p=12379#p12379
Drag wrote a test that took advantage of predictable peculiarities of the PPU's fetch sequence to clock the MMC5 IRQ an extra scanline: viewtopic.php?f=9&t=7653


Top
 Profile  
 
PostPosted: Wed Jan 30, 2019 4:52 am 
Offline
User avatar

Joined: Tue Mar 22, 2016 8:27 pm
Posts: 230
Location: Minnesota, USA
NewRisingSun wrote:
Ben Boldt wrote:
That actually is not where I got the idea
You wrote: "I am working through the frame timing diagram here:", followed by: "Then in the range 257-320, it quickly becomes not-in-frame because there are M2 cycles and no PPU /RD cycles." No. There are PPU /RD cycles throughout that area, as shown by the lower part of that diagram. Your conclusion that the PPU goes out-of-frame each scanline is wrong as a consequence. The PPU never stops reading until the end of scanline 239, or if the software disables rendering by writing to $2001.
Ben Boldt wrote:
instead of taking liberties and jumping directly to a simple "good-enough" solution
I am not taking any "liberties" or "jumping to solutions". I make things as simple as possible, and as complex as necessary.

I am not here to fight with you or to serve you NewRisingSun, but I can honestly say that my notion that the status bit increments the scanline counter came months ago and the first time I looked at the PPU timing diagram was days ago. It could very well be that I had an incorrect idea that influenced what I saw when I looked at that diagram.

lidnariq wrote:
Ben Boldt wrote:
I am sorry, I just do not follow. What do you mean by upper half? Could you take a screenshot of the PPU diagram and circle the spot where this happens?
We already know that the MMC5 counts its IRQ counter if

* The PPU fetches address X, where X ≥ $2000
* The PPU fetches address X again
* The PPU fetches address X a third time

Only after the third step is this sufficient to clock the IRQ counter.

We've known the horizontal timing for more than a decade: viewtopic.php?p=12379#p12379
Drag wrote a test that took advantage of predictable peculiarities of the PPU's fetch sequence to clock the MMC5 IRQ an extra scanline: viewtopic.php?f=9&t=7653

Thanks for the info lidnariq, I didn't know about any of this. I will read up on it.


Top
 Profile  
 
PostPosted: Wed Jan 30, 2019 6:09 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 852
Ben Boldt wrote:
I am not here to fight with you
Neither am I; I was looking for an explanation and did not get one.

I have added my emulator-tested description to the wiki article while keeping the state diagrams as a "formal description". I only revised my pseudo-code in one way, by setting lastAddress to "undefined" when inFrame becomes false, which turned out to be necessary, otherwise inFrame would be set too early if the address at the end of the frame happened to be the same at the beginning of the next frame because the game never accessed 2006/2007 in its NMI handler. Feel free to revise my description on the wiki once you have done your simulations and discovered any edge cases that are not sufficiently covered.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot], Google Adsense [Bot] 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