Nestopia 1.40
Moderator: General Mods
-
- Veteran
- Posts: 844
- Joined: Thu Jul 29, 2004 3:56 am
Nestopia 1.40
1.40 is out!?
http://nestopia.sourceforge.net/
Shell Additions:
* New cheat dialog features and improvements.
* Automatic cheat load/save support in Paths dialog.
* Option to mute sound when running in alt. speed mode.
Shell Changes:
* Icon improvements by Pongbashi.
* Default fullscreen resolution depending on monitor's aspect ratio.
* Refactoring.
Shell Fixes:
* Various minor things.
Core Additions:
* Preliminary Dendy console support. Fixes Magistr (Subor) and some other 'clone exclusives'. Info from Flamer and HardWareMan.
* DMC DMA read conflicts. Info from blargg and bunnyboy.
* Mapper 177, 179, 219 and 221. Info from CaH4e3.
* Database entries.
Core Changes:
* Better and more flexible PPU address line implementation at the expense of some speed.
* Database entries.
* Refactoring.
Core Fixes:
* Wrong palette sometimes when switching to/from VS images.
* Wrong image information sometimes, e.g. battery when there isn't any.
* Save state NTSC/PAL mode saving.
* Minor save state inaccuacy fix with tape recording
http://nestopia.sourceforge.net/
Shell Additions:
* New cheat dialog features and improvements.
* Automatic cheat load/save support in Paths dialog.
* Option to mute sound when running in alt. speed mode.
Shell Changes:
* Icon improvements by Pongbashi.
* Default fullscreen resolution depending on monitor's aspect ratio.
* Refactoring.
Shell Fixes:
* Various minor things.
Core Additions:
* Preliminary Dendy console support. Fixes Magistr (Subor) and some other 'clone exclusives'. Info from Flamer and HardWareMan.
* DMC DMA read conflicts. Info from blargg and bunnyboy.
* Mapper 177, 179, 219 and 221. Info from CaH4e3.
* Database entries.
Core Changes:
* Better and more flexible PPU address line implementation at the expense of some speed.
* Database entries.
* Refactoring.
Core Fixes:
* Wrong palette sometimes when switching to/from VS images.
* Wrong image information sometimes, e.g. battery when there isn't any.
* Save state NTSC/PAL mode saving.
* Minor save state inaccuacy fix with tape recording
Yes I know that my grammar sucks!
-
- ZSNES Shake Shake Prinny
- Posts: 5632
- Joined: Wed Jul 28, 2004 4:15 pm
- Location: PAL50, dood !
We don't need another db-taxing behemoth. Make new threads when they get too big so the old ones can die.
皆黙って俺について来い!!
Pantheon: Gideon Zhi | CaitSith2 | Nach | kode54
Code: Select all
<jmr> bsnes has the most accurate wiki page but it takes forever to load (or something)
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
-
- ZSNES Developer
- Posts: 6747
- Joined: Tue Dec 28, 2004 6:47 am
If that's supposed to be there, I plead ignorance.blargg wrote:You're praising it for its accuracy in this area, correct?Deathlike2 wrote:Edit: Although, it seems to have issues in the menu screen for Mega Man 3.
Continuing [url=http://slickproductions.org/forum/index.php?board=13.0]FF4[/url] Research...
It's there on hardware - both on the stage select screen (top line of lower third) and on the weapon select menu (top line).Deathlike2 wrote:If that's supposed to be there, I plead ignorance.blargg wrote:You're praising it for its accuracy in this area, correct?Deathlike2 wrote:Edit: Although, it seems to have issues in the menu screen for Mega Man 3.
Why yes, my shift key *IS* broken.
-
- ZSNES Developer
- Posts: 3904
- Joined: Tue Jul 27, 2004 10:54 pm
- Location: Solar powered park bench
- Contact:
I agree.grinvader wrote:We don't need another db-taxing behemoth.
*Nach wipes Nestopia off his hard drive.Neo Kaiser wrote: Core Additions:
* Database entries.
May 9 2007 - NSRT 3.4, now with lots of hashing and even more accurate information! Go download it.
_____________
Insane Coding
_____________
Insane Coding
You can always just disable the database. The main reason the database exists is because the iNES format is insufficient by itself. Plus, there are a lot of dumps floating around with incorrect info in their headers. The database fixes those (and prevents wasteful bug reports by doing so).Nach wrote:*Nach wipes Nestopia off his hard drive.
You may find the new NES XML format promising, though...
-
- -Burninated-
- Posts: 871
- Joined: Mon Sep 10, 2007 11:33 pm
- Location: Unspecified
-
- Veteran
- Posts: 844
- Joined: Thu Jul 29, 2004 3:56 am
If the iNES format is insufficient then another format must be made. "Wasteful reports" means that people are still ignorant thus it is the duty of the NES community to educate them and teach them how to fix the headers. Hell I fixed all my ROMs headers! why can't they? It is just a feature that can be disabled but what good it will do if people will still use bad dumps? Aren't we supposed to dump our own ROMs?Not that I actually dump my ROMs of course! :-pxamenus wrote:You can always just disable the database. The main reason the database exists is because the iNES format is insufficient by itself. Plus, there are a lot of dumps floating around with incorrect info in their headers. The database fixes those (and prevents wasteful bug reports by doing so).Nach wrote:*Nach wipes Nestopia off his hard drive.
You may find the new NES XML format promising, though...
Yes I know that my grammar sucks!
is the result from:Neo Kaiser wrote:... how to fix the headers. Hell I fixed all my ROMs headers! ...
Code: Select all
goodnes fixnes
is there any other program that can fix a bunch of NES ROM' header automaticaly?
EDIT:
i also agree with with:
format that would cure the header/mapper/mirroring problem that plaque the current nes rom format.If the iNES format is insufficient then another format must be made.
As far as I know, a DAT has not been made for the new XML format. Without a program to automatically separate the PRG and CHR data and put them in a zip container, it's going to take a lot of manual labor.
Currently, the way NES roms are distributed is the opposite of MAME. It combines the multiple parts of an NES game into one (the order of which is subjectively determined), then attaches a subjectively defined header format at the beginning with PCB info. Obviously, this makes dumpers and datters cry, because now you are dependent on a complex scanning mechanism to verify and manage the rom data (i.e. GoodTools aka pokeroms) because it's no longer isolated. You are now dealing with a format that stores rom data in a way that is different from that which it was dumped. If I need to reference a PRG revision's checksum, and I'm dealing with a format that doesn't have that isolated... well, you can see how this is a massive time drain on a system with thousands of games. A slightly more convenient manner of use won over a supremely more convenient ease of coordinating the integrity of the data itself. No system was in more disarray with bad data thought to be good floating around than the NES.
Dat files on the other hand, can be created by anyone and are totally public and easily modifiable, also standing on their own as a convenient reference to current entry attributes. Way easier for dumpers like myself to coordinate their own efforts vs. all the submissions and waiting and errors and disagreement associated with programs that don't externalize the database attributes.
My current goal is to find a programmer who also understands the importance of sound verification and databasing across all systems in the emulator scene and agrees that even the current DAT interface programs are simply too confusing and platform dependent. Just a quick look at clrmamepro should be enough to convince anyone that the process of creating databases and using them is unnecessarily bloated and confusing. Romcenter is a little better, but the dats it creates are not as easy to modify and it's only for Windows. If I can reason with this person and make suggestions on its initial structure, I'm sure we could blow away anything else currently out there.
Currently, the way NES roms are distributed is the opposite of MAME. It combines the multiple parts of an NES game into one (the order of which is subjectively determined), then attaches a subjectively defined header format at the beginning with PCB info. Obviously, this makes dumpers and datters cry, because now you are dependent on a complex scanning mechanism to verify and manage the rom data (i.e. GoodTools aka pokeroms) because it's no longer isolated. You are now dealing with a format that stores rom data in a way that is different from that which it was dumped. If I need to reference a PRG revision's checksum, and I'm dealing with a format that doesn't have that isolated... well, you can see how this is a massive time drain on a system with thousands of games. A slightly more convenient manner of use won over a supremely more convenient ease of coordinating the integrity of the data itself. No system was in more disarray with bad data thought to be good floating around than the NES.
Dat files on the other hand, can be created by anyone and are totally public and easily modifiable, also standing on their own as a convenient reference to current entry attributes. Way easier for dumpers like myself to coordinate their own efforts vs. all the submissions and waiting and errors and disagreement associated with programs that don't externalize the database attributes.
My current goal is to find a programmer who also understands the importance of sound verification and databasing across all systems in the emulator scene and agrees that even the current DAT interface programs are simply too confusing and platform dependent. Just a quick look at clrmamepro should be enough to convince anyone that the process of creating databases and using them is unnecessarily bloated and confusing. Romcenter is a little better, but the dats it creates are not as easy to modify and it's only for Windows. If I can reason with this person and make suggestions on its initial structure, I'm sure we could blow away anything else currently out there.
-
- Veteran
- Posts: 637
- Joined: Sat Apr 21, 2007 8:05 pm
I've been curious about one thing. NTSC w/ Bilinear and TV Aspect looks like wider to me than for example Standard w/ TV Aspect. Look for yourself:
NTSC Bilinear, 2x, TV Aspect
Standard Bilinear, 2x, TV Aspect
Can someone explain this behaviour?
NTSC Bilinear, 2x, TV Aspect
Standard Bilinear, 2x, TV Aspect
Can someone explain this behaviour?
Last edited by diminish on Fri Jul 25, 2008 3:23 pm, edited 1 time in total.
the importance of sound verification and databasing across all systems in the emulator sceneFitzRoy wrote:As far as I know, a DAT has not been made for the new XML format. Without a program to automatically separate the PRG and CHR data and put them in a zip container, it's going to take a lot of manual labor.
Currently, the way NES roms are distributed is the opposite of MAME. It combines the multiple parts of an NES game into one (the order of which is subjectively determined), then attaches a subjectively defined header format at the beginning with PCB info. Obviously, this makes dumpers and datters cry, because now you are dependent on a complex scanning mechanism to verify and manage the rom data (i.e. GoodTools aka pokeroms) because it's no longer isolated. You are now dealing with a format that stores rom data in a way that is different from that which it was dumped. If I need to reference a PRG revision's checksum, and I'm dealing with a format that doesn't have that isolated... well, you can see how this is a massive time drain on a system with thousands of games. A slightly more convenient manner of use won over a supremely more convenient ease of coordinating the integrity of the data itself. No system was in more disarray with bad data thought to be good floating around than the NES.
Dat files on the other hand, can be created by anyone and are totally public and easily modifiable, also standing on their own as a convenient reference to current entry attributes. Way easier for dumpers like myself to coordinate their own efforts vs. all the submissions and waiting and errors and disagreement associated with programs that don't externalize the database attributes.
My current goal is to find a programmer who also understands the importance of sound verification and databasing across all systems in the emulator scene and agrees that even the current DAT interface programs are simply too confusing and platform dependent. Just a quick look at clrmamepro should be enough to convince anyone that the process of creating databases and using them is unnecessarily bloated and confusing. Romcenter is a little better, but the dats it creates are not as easy to modify and it's only for Windows. If I can reason with this person and make suggestions on its initial structure, I'm sure we could blow away anything else currently out there.
Step 1 is a universal format for the file that describes the media and how it connects to the hardware.
Step 2 is making sure all the data is correctly stored inside the zip file.
Both these steps could be partially/fully automated with the tool you want.
Step 3 is forcing end users to use the new format by slowly phasing out older formats and providing the tools to move to the new format with minimal effort by the end user
What you're actually doing is applying the aspect ratio correction twiceI've been curious about one thing. NTSC w/ Bilinear and TV Aspect looks like wider to me than for example Standard w/ TV Aspect.
![Smile :)](./images/smilies/icon_smile.gif)
You should UNCHECK the 'TV Aspect ratio' checkbox in the NTSC filter options, since the emulator has it's own setting to enforce TV Aspect Ratio.
[i]Have a nice kick in da nutz[/i] @~@* c//
That is not the case. Compare Screen Size 1x NTSC windowed with Screen Size 2x Standard windowed or any other filter, secondly Screen Size Max NTSC fullscreen on 16:10 resolution (I personally use 1280x800) with Screen Size Max Standard fullscreen or any other filter (TV Aspect checked in emu options with them all). In the first case image is narrower with Standard and others, wider with NTSC. In the second case NTSC produces narrower image. TV Aspect checked in NTSC filter options makes no difference to this behaviour.
-
- Trooper
- Posts: 376
- Joined: Tue Apr 19, 2005 11:08 pm
- Location: DFW area, TX USA
- Contact:
So I started playing Nestopia again after quite a long time away from NES gaming and noticed the sound was jumpy and unstable. Not all the time mind you, but randomly every 10 to 20 seconds. At first I thought it was my timing settings, but I just checked with Nestopia 1.37 and the sound is stable under the same timing settings. Version 1.39 has the same problem as 1.40, but I don't have a copy of 1.38 to check.
So at some point either in 1.38 or 1.39, the timing of the sound got screwed up. It's really bad when you watch the opening story to Castlevania 3, but I've also noticed it when I merely tried to play NSF music.
So at some point either in 1.38 or 1.39, the timing of the sound got screwed up. It's really bad when you watch the opening story to Castlevania 3, but I've also noticed it when I merely tried to play NSF music.
NES NTSC palette file:
http://www.firebrandx.com/downloads/fbx2pal.zip
http://www.firebrandx.com/downloads/fbx2pal.zip
The entire mapper system was scrubbed in favor of board classes in 1.38. Nothing was changed in the DirectSound code that should have any audible effect. As for 1.39, nothing was changed at all in the DirectSound code.
Try messing with the latency setting, or whether the buffer is in system memory or not? (Latter shouldn't have any effect in Windows Vista or newer.)
Try messing with the latency setting, or whether the buffer is in system memory or not? (Latter shouldn't have any effect in Windows Vista or newer.)
-
- Trooper
- Posts: 376
- Joined: Tue Apr 19, 2005 11:08 pm
- Location: DFW area, TX USA
- Contact:
Yeah I'm starting to notice the sound is glitchy even in 1.37 as well. I've tried all sorts of timing settings, but nothing seems to fully get rid of the problem. Even if I set the buffer to 10 frames, turn all sync timing off, and allow for frame skipping, the sound still has the occasional screwup. Sometimes it's a pop, sometimes it's a strange pitch to a tone, and other times it's a half-second skip.
What sucks is it kind of ruins the whole experience. I'd prefer to use Nestopia because it has the best user control over various features, but the sound is just way too unstable for my tastes. It needs to be smooth and glitch-free. I know my system can handle it. I've got a 7.1 digital surround card, a quadcore cpu, and plenty of ram. I guess I'll have to look for an alternative emulator.
What sucks is it kind of ruins the whole experience. I'd prefer to use Nestopia because it has the best user control over various features, but the sound is just way too unstable for my tastes. It needs to be smooth and glitch-free. I know my system can handle it. I've got a 7.1 digital surround card, a quadcore cpu, and plenty of ram. I guess I'll have to look for an alternative emulator.
NES NTSC palette file:
http://www.firebrandx.com/downloads/fbx2pal.zip
http://www.firebrandx.com/downloads/fbx2pal.zip