nesdev.com
http://forums.nesdev.com/

young indiana jones new ppu discovery, nestopia help...
http://forums.nesdev.com/viewtopic.php?f=3&t=6401
Page 14 of 15

Author:  plasturion [ Wed Sep 14, 2011 2:35 pm ]
Post subject: 

Hi,
oxyandy wrote:
Just get ips win and make an ips file to put in the patch folder,
from original and hacked rom.
Then if you wish, you enable auto-patching,
or load original then ips from launcher.

It will apply to current rom, this is another way of doing it :)


I think it won't help with several cases. Try to load Dragon Scroll (J) with lasted Nestopia 1.40 or 1.41 (not mine), and then apply ips patch. You'll see an error - unsupported or malfromed mapper. That's because game has new CRC value, and without database entry this game won't run. (the same result will be when you disable internal database and try only open Dragon Scroll).

There are two things to make this better without adding new entries for hacked roms:
- enhance somehow auto-recognizing mapper type (you are able to load Dragon Scroll without database in my last release, but it's almost impossible to make it perfect)
- or force to keep old CRC and SHA-1 (original) value before loading ips patch (that sounds good for me). btw. there's checkbox "bypass CRC validation" - what is doing, is this work?

anyway good to hear all your improvements! I hope your release will be free of mentioned above fatal error - bugs (like in 1.41 that makes system unresponsive on fullscreen, forcing to reboot)

Author:  tepples [ Wed Sep 14, 2011 3:25 pm ]
Post subject: 

The second best option as I see it is to separate the database of verified good dumps into a separate executable that takes a hash of the PRG and CHR and returns a correct 16-byte iNES or NES 2.0 header. This would allow permanently fixing the header in the ROM file before applying IPS, and it'd allow behavior similar to your "force to keep old": load ROM, get fixed header, load IPS.

The best option would involve a BitTorrent-style hash list that recognizes inexact matches in order to recognize that a ROM has been partly patched. Again, this would be best as a separate executable so that other tools can make use of it.

Author:  oxyandy [ Wed Sep 14, 2011 11:01 pm ]
Post subject: 

Quote:
bugs (like in 1.41 that makes system unresponsive on fullscreen, forcing to reboot)


If somehow through combining source I have introduced this bug, removal is very easy.
How to repeat this bug ?
What makes it happen ?

I just load Dragon Scroll - Yomigaerishi Maryuu (Japan) (No-Intro name)
then the English ips patch and had no problem.

Code:
Dragon Scroll - Yomigaerishi Maryuu (Japan)
Soft-patched: No
CRC:          AC9895CC

Soft-patched: Yes
CRC:          24C66CC4


Ok yes I see Official release after loading original then patch doesn't load.
Hmm so an entry is needed in external.xml or if patched rom is really special, the internal one :P

Is this the same rom ?
I will email you a link :)

EDIT:

Ok so this is the key to the bug
"full screen (set sync with vblank),"
This will produce an unresponsive system ?

I will confirm shortly, I have needed things open...
I will look over those specific changes later once I finish my work,
thanks

Author:  plasturion [ Thu Sep 15, 2011 3:32 am ]
Post subject: 

oxyandy wrote:
Ok so this is the key to the bug
"full screen (set sync with vblank),"
This will produce and unresponsive system ?


for 1.41 it was a clue, thanks to you - I could see your pre-release I noticed few more bugs.

I can't see anything on full screen - it's just black screen, after some few alt+enter something wrong with sound sync.

in your release system sometimes goes unresponsive like in 1.41, even sync with vblank is not enable.

Author:  oxyandy [ Thu Sep 15, 2011 7:18 am ]
Post subject: 

I have tried and tried, I can not repeat the bug.

I use 1280 x 1024
View screen size MAX

I normally do not have vsync checked.
but for the testing I have.

I am using standard filter.
Monitor is set primary 1 in video options

Monitor frequency auto.

Colour 16 bit or 32

As input I use Wireless Controllers or the keyboard.

That archive I shared with you had a nestopia.xml included with it.

have you tried deleting that ?

I can easy make a fresh build,
built on top of virgin 140 source
with just the mapper / game fixes,

and this I will do shortly

Author:  oxyandy [ Fri Sep 16, 2011 5:03 am ]
Post subject: 

Quote:
Well I tracked another bug to the flip filter
It causes games to run really fast when displayed on the second monitor.
The smaller the window, the fast it runs.
Also eats up CPU at over 60%

This was confirmed with your own built Nestopia-1.40.1-IF6-unofficial binary.

Flip filter enabled or not.

Will look deeper into the true cause later.


So is not the flip filter, sorry.

I have been busy working,
I did not have a chance to try this with versions prior to 1.40.1-IF6, till now.

I now see this happens with vsync ticked, in 1.40 + 1.36. (I didn't try others)


All I need to do is enable vsync and then drag a windowed Nestopia to the edge of my primary display
so it overlaps slightly onto the secondary display window, then it runs as above, fast.

If the window is small, it runs really fast.
If the window is maximised then it doesn't seem like it is running fast
but, the sound is a bit choppy and breaks up a little.

I wonder if this is similar to the sound problem which so many seem to be plagued with. ?

Author:  oxyandy [ Tue Sep 27, 2011 7:48 am ]
Post subject: 

Quote:
Try to load Dragon Scroll (J) with lasted Nestopia 1.40 or 1.41 (not mine), and then apply ips patch. You'll see an error - unsupported or malfromed mapper. That's because game has new CRC value, and without database entry this game won't run. (the same result will be when you disable internal database and try only open Dragon Scroll).


Ok, I have learnt a lot,
1. To load a patched rom of dragon scroll you need a database entry.
2. To load the ips patch that makes that patched rom you do not need an entry at all.
But, the ips patch needs the same header / mapper info as the original.

So I made this. try this in Official 1.40 and it will load no problem.
http://www.upload.ee/download/1691263/e ... Patched.7z

Author:  ulfalizer [ Thu Jun 27, 2013 10:39 pm ]
Post subject:  Re: young indiana jones new ppu discovery, nestopia help...

I traced through the v-related circuitry in Visual 2C02 to figure out what goes on in this glitch. The short version is that reading or writing $2007 during rendering triggers a Y increment and a coarse X increment. Here's the explanation:

v is split up into multiple sections (X scroll, Y scroll, horizontal nametable bit, vertical nametable bit, and fine Y scroll), each with a configurable carry in that determines the "next" value for the section. When not rendering, the carries are set up to perform linear increments of v by either 1 or 32. When rendering, they are set up to perform the operations described in The skinny on NES scrolling.

The crux is that reading or writing $2007 triggers the "load next value" signal for all the bits of v (it triggers both of the "load next hscroll value" and "load next vscroll value" signals), and it expects the carries to be set up for a linear increment. During rendering, this instead has the effect of loading both the next Y value and the next coarse X value.

I also updated the "$2007 reads and writes" bullet in The skinny on NES scrolling.

Author:  Drag [ Tue Jul 02, 2013 8:18 pm ]
Post subject:  Re: young indiana jones new ppu discovery, nestopia help...

Is the behavior the same, regardless of whether increment is set to 1 or 32?

Author:  ulfalizer [ Wed Jul 03, 2013 12:50 am ]
Post subject:  Re: young indiana jones new ppu discovery, nestopia help...

Drag wrote:
Is the behavior the same, regardless of whether increment is set to 1 or 32?


Yup, the increment setting is ignored while rendering, and that extends to this glitch too.

Author:  Alegend45 [ Wed Jul 03, 2013 11:47 am ]
Post subject:  Re: young indiana jones new ppu discovery, nestopia help...

Unexpected, but important. Good work, Ulfalizer.

Author:  ulfalizer [ Wed Jul 03, 2013 4:18 pm ]
Post subject:  Re: young indiana jones new ppu discovery, nestopia help...

Alegend45 wrote:
Unexpected, but important. Good work, Ulfalizer.


Thanks. This does kinda fall in the OCD category though (I only know of one game that cares, and the previously guessed behavior was likely sufficient there), but it's not very hard to get right at least. :P

Author:  tepples [ Sat Aug 22, 2015 1:27 pm ]
Post subject:  Re:

BootGod wrote:
Can the IRQ behavior be determined solely by the MMC3 revision?

As far as I can tell, MMC3C and MMC3B S (with S in the same font as the logo of Sharp Electronics) have the new behavior (0 = IRQ every line), and MMC3A and MMC3B (no S) have the old behavior (0 = disable).

Author:  thefox [ Sat Aug 22, 2015 1:36 pm ]
Post subject:  Re: young indiana jones new ppu discovery, nestopia help...

Can't remember whether this was mentioned before, but Legend of Zelda does two "inexplicable" $2007 reads in it's vertical scrolling routine (used when screen is scrolling upwards/downwards) at $8566, with rendering enabled. Notably they also didn't know about the $2005/$2006 trick so they only used $2006 when scrolling vertically, making the vertical screen transition slightly choppier than the horizontal one.

Author:  Duxa [ Wed Apr 05, 2017 1:56 pm ]
Post subject:  Re: young indiana jones new ppu discovery, nestopia help...

Sorry for resurrecting an old thread. But the shaking issue is there on Nintendo's emulator that is used in their games in eShop on 3DS. If you do an inject of this game into that emulator the screen shakes. Unfortunately I cant use another emulator so I need to fix the game itself. I saw that there is an ips patch posted on page 2. is that still the best solution for this?

Page 14 of 15 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/