young indiana jones new ppu discovery, nestopia help...

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Post by jwdonal » Tue Jun 08, 2010 10:11 pm

That is *extremely* odd since the game writes to a mapper register in order to set the appropriate mirroring.....I don't understand that at all! :shock:

And you even said you checked the CRC of multiple ROM dumps. Why the heck would the game write the wrong mirroring value?? I mean, obviously it doesn't really since it works in the original NES. But....I know that my H/V mirroring bit in my mapper is correct since it works for so many other games. And obviously, the emus aren't going to have the H/V reversed since it would clearly break many other MMC3 games. What the heck is going on here!?!?

User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Post by jwdonal » Tue Jun 08, 2010 10:15 pm

James wrote:I switched to vertical mirroring mode...
Wait, how did you switch the mirroring mode? You would have to modify the ROM code of the game. How did you know what hex data to change?

User avatar
*Spitfire_NES*
Posts: 306
Joined: Fri May 21, 2010 4:10 pm

Post by *Spitfire_NES* » Tue Jun 08, 2010 10:22 pm

here is a link to JUST the ips patch. the scrolling is still GOD-AWFUL on level 2 but now tolerable. Also when the cannonball touches the ground on level 1 near the end it does not turn red.

http://www.detach.republika.pl/IndyVscrollOFF.ips

With this hex you did does that fix stuff? id love to know if you got something working correctly as this patch only turns off the vertical scrolling. enjoy! :)

User avatar
James
Posts: 429
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Post by James » Wed Jun 09, 2010 3:58 am

jwdonal wrote:
James wrote:I switched to vertical mirroring mode...
Wait, how did you switch the mirroring mode?
I was running it in FCEUXD and just changed the mirroring mode in the name table viewer.
get nemulator
http://nemulator.com

User avatar
James
Posts: 429
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Post by James » Wed Jun 09, 2010 8:42 am

I think I've found the problem! I'll post more details when I get home from work and have a chance to perform some more tests (the cannon ball section looks good, but I haven't tested level 2, nor have I verified that I haven't broken anything else in the process).
*Spitfire_NES* wrote: maybe it has nothing to do with the mmc3 at all perhaps??
nothing to do with mmc3
jwdonal wrote: fixing this bug might lead to a new discovery of the inner workings of the NES, or correct an assumption or conclusion that was incorrectly made it the past
maybe :)

User avatar
*Spitfire_NES*
Posts: 306
Joined: Fri May 21, 2010 4:10 pm

Post by *Spitfire_NES* » Wed Jun 09, 2010 12:40 pm

can't wait to hear it man do let us know when you get a chance! :)

User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Post by jwdonal » Wed Jun 09, 2010 12:44 pm

James wrote:
jwdonal wrote:
James wrote:I switched to vertical mirroring mode...
Wait, how did you switch the mirroring mode?
I was running it in FCEUXD and just changed the mirroring mode in the name table viewer.
That's awesome. I need to check out FCEUXD sometime soon. I hear lots about it.

I am eager to hear of your discovery as well. Don't let us down now that you have us all psyched up!! :-o

User avatar
James
Posts: 429
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Post by James » Wed Jun 09, 2010 11:42 pm

Check out the video -- it looks good to me!

Long story short, incrementing the PPU's vram address by 1 or 32 on $2007 access is only correct when rendering is disabled. The game, however, is reading $2007 mid-screen. It seems that accesses to $2007 during rendering affect the vram address the same way that normal rendering does. In other words, accessing $2007 mid-screen 'clocks' the counters as described in the 'VRAM access during rendering' section of Brad Taylor's 2C02 doc.

Here's my fix. This is called on reads/writes to $2007.

Code: Select all

void c_nes::c_ppu::update_vram_address()
{
	if (rendering)
	{
		if (address_increment == 32)
		{
			if ((vram_address & 0x7000) == 0x7000)
			{
				vram_address &= 0x0FFF;
				switch (vram_address & 0x03E0)
				{
				case 0x03A0:
					vram_address ^= 0x0800;
				case 0x03E0:
					vram_address &= 0xFC1F;
					break;
				default:
					vram_address += 0x0020;
				}
			}
			else
				vram_address += 0x1000;
		}
		else
			//TODO: this is, more than likely, wrong.
			vram_address++;
	}
	else
		vram_address = (vram_address + address_increment) & 0x7FFF;
}
I've put the fix in nemulator 2.1.4, which can be downloaded from http://nemulator.com, if you'd like to check it out.

edit: fixed a typo in the code
Last edited by James on Fri Jun 11, 2010 10:26 pm, edited 3 times in total.

User avatar
Disch
Posts: 1849
Joined: Wed Nov 10, 2004 6:47 pm

Post by Disch » Thu Jun 10, 2010 10:36 am

That's interesting. It kind of makes sense in a way.

I wonder if inc-by-1 mode does the same wrapping around the nametable thing.

Like...

Code: Select all

      else   // inc-by-1
      {
         if((vram_address & 0x001F) == 0x001F)
            vram_address ^= 0x041F;
         else
            ++vram_address;
      }

User avatar
James
Posts: 429
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Post by James » Thu Jun 10, 2010 11:05 am

Disch wrote: I wonder if inc-by-1 mode does the same wrapping around the nametable thing.
That's what I'm thinking as well. I didn't bother with it yet, though, since I don't know how I'd test it.
get nemulator
http://nemulator.com

User avatar
jwdonal
Posts: 719
Joined: Sat Jun 27, 2009 11:05 pm
Location: New Mexico, USA
Contact:

Post by jwdonal » Thu Jun 10, 2010 11:11 am

Is it just me or is this absolutely incredible? James has actually made a new discovery on the inner workings of the NES PPU after all these years and after so many emulators. And the chances of anyone discovering this were almost nil - I'm guessing that young indiana is one of extremely few games (the only game??) that would have this problem. Who knows what other oddities this might fix in various games. And Disch doesn't even have any beef with it - that's pretty much validation of your discovery right there.

Nice work James!! :D

EDIT: Should James make a new post for this discovery to grab peoples attention? Something other than "young indiana jones..." - more like "New PPU Rendering Discovery" or whatever. Just a thought.

tepples
Posts: 22050
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Thu Jun 10, 2010 12:17 pm

So a read during rendering skips a scanline if inc by 32 or a column if inc by 1. Do I understand right? I wonder what sort of race condition this has with normal rendering.

User avatar
*Spitfire_NES*
Posts: 306
Joined: Fri May 21, 2010 4:10 pm

Post by *Spitfire_NES* » Thu Jun 10, 2010 12:33 pm

great work james! im gonna try to get this implemented into nestopia! i cannot for one, thank you enough my man! and it looks great in action too!

i thank everyone for even responding in my thread and can't wait to see what else you guys can do. un-friggin believable! :lol: a round for everyone! lmao

User avatar
James
Posts: 429
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Post by James » Thu Jun 10, 2010 1:04 pm

jwdonal wrote: Nice work James!! :D
*Spitfire_NES* wrote: great work james!
Thanks, guys!
tepples wrote: So a read during rendering skips a scanline if inc by 32 or a column if inc by 1
Yeah, that sounds about right to me, though I haven't tested the latter behavior.

edit: just a little clarification here. Instead of saying 'skips a scanline' I might say that a read during rendering, if address_increment == 32, will point the vram address to the next scanline's data.

User avatar
tokumaru
Posts: 11858
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru » Thu Jun 10, 2010 2:29 pm

It's amazing that this community still makes discoveries like this. Nice work, James.

Post Reply