It is currently Tue Oct 24, 2017 4:41 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 48 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
PostPosted: Thu Jun 03, 2010 12:17 am 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 712
Location: New Mexico, USA
Hello all. This is the initial test of my MMC3 implementation running SMB3. I was hoping some of you might have some suggestions on what the problem might be and why I am seeing garbage on the screen at various points in the game. After all, you guys fixed my Battletoads issue on AxROM in all of 10 min, so what's stopping you from fixing this too?? At least that's what I'm hoping. ;)

I have double and triple checked my PRG/CHR swapping methods. So I don't think that's the problem. I pass all of Blargg's MMC3 IRQ test ROMs. I actually pass _both_ the Rev A and Rev B style IRQ tests with the same hardware and I haven't figured out why yet - I didn't think that was supposed to be possible.

Also, my emu's sound doesn't work too well yet so I didn't record any sound for some of these vids. Here is SMB3...

Super Mario Bros. 3 (Attempt 1)
Super Mario Bros. 3 (Attempt 2)
Super Mario Bros. 3 (Attempt 3)
Super Mario Bros. 3 (Attempt 4)

Here is a short segment of Mega Man 3. I know that the pause screen in the Gemini Man stage is supposed to tell you if you're handling one of the CHR swapping modes correctly. The pause screen looks fine to me but the level selection stage is totally screwed - it looks like the screen is wrapped around over the top or something. Also, @ 0:50 is where I'm about to start reducing the number of CPU clock cycles required prior to recognizing another rising-edge of PPU address bit 12. It is set to 8 CPU clock cycles in the beginning, and then each time you see it change I decrement by 1, down to 4, and then increase back up to 8 again.

Mega Man 3 (Attempt 1)

Here is Crystalis. Things start going bad at 1:30. Something crazy also happens @ 2:32 when I try to walk too far up the map. I can fix it though by simply walking back down.

Crystalis (Attempt 1)

Here is SMB2. This one seems to play almost perfectly with only a glitch here and there.

Super Mario Bros. 2 (Attempt 1)

If there are any games you think would be good for me to test (and post the video result) for additional help diagnosing I'd be happy to oblige.

Any help/ideas would be much appreciated.

Thanks!

Jonathon

EDIT (12/12/2010): Fixed all broken links, added 3 additional SMB3 videos (i.e. attempts 2, 3, and 4), and also put all vids on youtube so you don't have to download from my very slow server.


Last edited by jwdonal on Sun Feb 06, 2011 12:00 am, edited 17 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 03, 2010 12:27 am 
Offline
User avatar

Joined: Sun Mar 19, 2006 3:06 am
Posts: 583
Location: Gothenburg/Sweden
Doublecheck the MMC3 IRQ-code.

_________________
http://nes.goondocks.se/


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 03, 2010 1:08 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3944
It helps a lot if you know what the game is doing. Run it in a debugger like FCEUX or Nintendulator, and trap writes to the relevant MMC3 registers.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 03, 2010 7:53 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
From MM3, I get the impression you're detecting A12 changes incorrectly.

For the status bar in MM3, there are zero A12 rises (A12 stays low the entire time). All BG and Sprite graphics are fetched from $0xxx. Therefore the IRQ should never trip during that time, no matter how much of a delay you have between A12 rises.

Gemini man's stage is a good test for that because the IRQ counter is used to split the level, then again to split the status bar, but is left on for the whole menu bar (even though it's not decremented because there are no A12 rises). So if you are counting lines incorrectly, you'll get what you're getting where the same 16 pixels or so of the menu bar repeat over and over due to the IRQ tripping when it shouldn't.

This may not be a problem with your IRQ counter logic as much as it might be a problem with your A12 logic. Double check when A12 is going high during rendering. It should only happen when CHR is fetched from $1xxx. All other fetches have A12 low.


EDIT:

Looking at SMB2, it's clear to me that you have lingering CPU bugs. There's no way those glitches are MMC3 related.

Forget about MMC3 for now and iron out the bugs in your CPU. No sense in looking for MMC3 bugs that might not exist!


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 03, 2010 1:55 pm 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 712
Location: New Mexico, USA
Disch wrote:
It should only happen when CHR is fetched from $1xxx. All other fetches have A12 low.

What about for background/sprite palette (BSP) fetching (i.e. $3FXX)? Bit 12 goes high there as well. I know that the BSP palette is internal to the PPU, but are you saying that accesses to the BSP should not show up on the external PPU address bus? As of right now I think those addresses do show up on my external PPU address (I'll need to check), but the external read/write signals do not assert during the internal BSP accesses - so no harm is done at least with respect to data corruption. Although I think I might be confusing manual $2006/$2007 accesses to rendering accesses. I need to check all this out.

Disch wrote:
Forget about MMC3 for now and iron out the bugs in your CPU. No sense in looking for MMC3 bugs that might not exist!

Yes, I absolutely agree. I don't want to waste my time or anyone elses. But I really should be able to fix this silly address bit 12 mis-counting thing even if there are some bugs in my CPU. This should be a pretty simple PPU fix if I can get an answer to the above question.

Thanks!

Jonathon


Last edited by jwdonal on Thu Jun 03, 2010 2:26 pm, edited 2 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 03, 2010 2:14 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
jwdonal wrote:
are you saying that accesses to the BSP should not show up on the external PPU address bus?

I'm pretty sure that the PPU's internal CGRAM accesses during rendering do not show up on the PPU bus. Ordinarily, the PPU accesses external memory only on every other dot, and the rated memory access speed of (say) CHR RAM bears this out. But it accesses CGRAM on every dot. (BSP is something else entirely.)


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 03, 2010 4:39 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
+1 to what tepples said.

Pallet accesses are not seen by the cartrides, do not change A12, and do not impact MMC3's IRQ counter.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 03, 2010 5:37 pm 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 712
Location: New Mexico, USA
ok, so I looked over my code and internal palette access during rendering are not showing up on the external PPU address bus. But $2006/$2007 accesses to $3FXX by the software _would_ show up. And from what I have read, that is correct operation. Unless someone here tells me otherwise.

So I don't see how I can be mis-counting A12 rises. I will need to look into it more. The way I count rises is if (A12=0) on the previous CPU clock cycle and (A12=1) in the current CPU clock cycle that is a rise. And any time that I do not see that specific scenario I don't decrement the IRQ counter. So I don't think that part of my code is screwed up....


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 03, 2010 5:57 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 8:33 am
Posts: 3715
Location: Central Texas, USA
I believe A12 can rise and fall within a CPU single clock cycle when the PPU is rendering. The CPU shouldn't be related at all to this check, as it's entirely a function of the PPU address bus and the MMC3 watching it. There's no clock involved.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 03, 2010 5:57 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
During sprite fetch (x=256 to 319), A12 is low for 4 dots (while performing a dummy nametable fetch) and high for 4 dots (while fetching the pattern). It is believed that the MMC3 puts some sort of low-pass filter between A12 and the scanline counter to ignore rising edges that occur less than 8 dots or so after a falling edge.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 03, 2010 6:05 pm 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 712
Location: New Mexico, USA
blargg wrote:
I believe A12 can rise and fall within a CPU single clock cycle when the PPU is rendering.

Definitely agreed.

blargg wrote:
The CPU shouldn't be related at all to this check, as it's entirely a function of the PPU address bus and the MMC3 watching it. There's no clock involved.

I don't think it's possible for me _not_ to use a clock and be able to detect a rising edge in my hardware. Just to verify - the original clock input to the MMC3 was the (21.47727M / 12) clock correct? Or was it the raw 21.47727 clock? If it was the faster clock then I could see how it could detect rising edges of A12 _within_ a CPU cycle. But if the MMC3 clock was the CPU div-12 clock then they must have been doing some fancy analog circuitry stuff in order to detect edges that is not possible for me to do in my FPGA. *However*, I do have a way around this - I will work on it and get back to you.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 03, 2010 7:01 pm 
Offline
User avatar

Joined: Mon Sep 27, 2004 2:13 pm
Posts: 1667
Location: .ma.us
The MMC3 doesn't use any clock but the 1.79 MHz Phi2 and it doesn't need any analog circuitry either, it's 100% logic for sure.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 03, 2010 7:03 pm 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 712
Location: New Mexico, USA
Ok. So can you tell me how to detect a within-cpu-cycle rising-edge of PPU address bit 12 with only the cpu clock and discrete logic?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 03, 2010 7:04 pm 
Offline

Joined: Sun Sep 19, 2004 11:07 pm
Posts: 154
pinout suggests it was getting the 1.789MHz clock, however, the counter could have just been clocked directly by A12.

Do your checks at 21MHz, with some sort of lowpass on the thing as mentioned.

Going by the wiki claim of it ignoring edges less than 14-16 dots apart, something like this might do it.

Code:
module a12_edge_filter(clk21, a12, out);
  input wire clk21, a12;
  output wire out;
  reg [3:0] wd;
  reg pa12;

  assign out = |wd[3:0];

  always @(posedge clk21) begin
    pa12 <= a12;
    if (~pa12 & a12)
      wd <= 4'hF;
    else if (|wd)
      wd <= wd - 1'b1;
endmodule


Probably needs a reset to start the wd counter at 0, but I think that will do the right thing. The response time can be fiddled with by changing the 4'hF appropriately. out will rise one cycle after seeing the first rising edge, and will not drop until a12 stays low for more than 15 cycles.

Alternatively, you could probably get the intended behavior at the CPU rate with a similar check, with it requiring A12 to drop for 2+ cycles before recognizing another edge.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jun 03, 2010 7:11 pm 
Offline
User avatar

Joined: Sat Jun 27, 2009 11:05 pm
Posts: 712
Location: New Mexico, USA
ReaperSMS wrote:
the counter could have just been clocked directly by A12.

Wow, I hadn't considered that. I bet that is _exactly_ how they did it back then too. You'd never want to do that in an FPGA though - major clock domain and timing constraint calculation issues. However, as you say...

ReaperSMS wrote:
Do your checks at 21MHz, with some sort of lowpass on the thing as mentioned.

Yeah, that was the "work-around" that I was just working on that I mentioned earlier. I was trying to make the hardware match as much as possible but I don't see any other solution except to overclock the mapper.

I agree with everything you've said. Nice! :)


Last edited by jwdonal on Thu Jun 03, 2010 7:44 pm, edited 2 times in total.

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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [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