It is currently Thu Oct 19, 2017 6:48 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 218 posts ]  Go to page Previous  1 ... 11, 12, 13, 14, 15  Next
Author Message
 Post subject:
PostPosted: Wed Sep 14, 2011 2:35 pm 
Offline
User avatar

Joined: Thu Jun 02, 2011 2:05 am
Posts: 63
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)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Sep 14, 2011 3:25 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19104
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Sep 14, 2011 11:01 pm 
Offline

Joined: Tue Sep 13, 2011 8:14 am
Posts: 6
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


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 15, 2011 3:32 am 
Offline
User avatar

Joined: Thu Jun 02, 2011 2:05 am
Posts: 63
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Sep 15, 2011 7:18 am 
Offline

Joined: Tue Sep 13, 2011 8:14 am
Posts: 6
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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Sep 16, 2011 5:03 am 
Offline

Joined: Tue Sep 13, 2011 8:14 am
Posts: 6
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. ?


Top
 Profile  
 
 Post subject:
PostPosted: Tue Sep 27, 2011 7:48 am 
Offline

Joined: Tue Sep 13, 2011 8:14 am
Posts: 6
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


Top
 Profile  
 
PostPosted: Thu Jun 27, 2013 10:39 pm 
Offline
User avatar

Joined: Fri Mar 08, 2013 9:55 pm
Posts: 349
Location: Linköping, Sweden
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.


Top
 Profile  
 
PostPosted: Tue Jul 02, 2013 8:18 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
Is the behavior the same, regardless of whether increment is set to 1 or 32?


Top
 Profile  
 
PostPosted: Wed Jul 03, 2013 12:50 am 
Offline
User avatar

Joined: Fri Mar 08, 2013 9:55 pm
Posts: 349
Location: Linköping, Sweden
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.


Top
 Profile  
 
PostPosted: Wed Jul 03, 2013 11:47 am 
Offline

Joined: Thu Mar 29, 2012 6:10 pm
Posts: 36
Unexpected, but important. Good work, Ulfalizer.


Top
 Profile  
 
PostPosted: Wed Jul 03, 2013 4:18 pm 
Offline
User avatar

Joined: Fri Mar 08, 2013 9:55 pm
Posts: 349
Location: Linköping, Sweden
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


Top
 Profile  
 
 Post subject: Re:
PostPosted: Sat Aug 22, 2015 1:27 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19104
Location: NE Indiana, USA (NTSC)
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).


Top
 Profile  
 
PostPosted: Sat Aug 22, 2015 1:36 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2962
Location: Tampere, Finland
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.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
PostPosted: Wed Apr 05, 2017 1:56 pm 
Offline

Joined: Wed Apr 05, 2017 1:54 pm
Posts: 6
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?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 218 posts ]  Go to page Previous  1 ... 11, 12, 13, 14, 15  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users 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