Nestopia 1.40

Neo Kaiser · Post by **Neo Kaiser** » Wed Jun 11, 2008 5:35 pm

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

Post by **grinvader** » Wed Jun 11, 2008 8:28 pm

We don't need another db-taxing behemoth. Make new threads when they get too big so the old ones can die.

Rashidi · Post by **Rashidi** » Thu Jun 12, 2008 2:54 am

*download* ... and it works (obviously)

great release

Deathlike2 · Post by **Deathlike2** » Thu Jun 12, 2008 11:21 am

Great timing, especially when I was planning to play another FF1 hack.

Edit: Although, it seems to have issues in the menu screen for Mega Man 3.

blargg · Post by **blargg** » Thu Jun 12, 2008 12:05 pm

Deathlike2 wrote:Edit: Although, it seems to have issues in the menu screen for Mega Man 3.

You're praising it for its accuracy in this area, correct?

Deathlike2 · Post by **Deathlike2** » Thu Jun 12, 2008 10:04 pm

blargg wrote:
Deathlike2 wrote:Edit: Although, it seems to have issues in the menu screen for Mega Man 3.
You're praising it for its accuracy in this area, correct?

If that's supposed to be there, I plead ignorance.

Post by **odditude** » Thu Jun 12, 2008 10:17 pm

Deathlike2 wrote:
blargg wrote:
Deathlike2 wrote:Edit: Although, it seems to have issues in the menu screen for Mega Man 3.
You're praising it for its accuracy in this area, correct?
If that's supposed to be there, I plead ignorance.

It's there on hardware - both on the stage select screen (top line of lower third) and on the weapon select menu (top line).

Post by **Nach** » Fri Jun 13, 2008 2:25 am

grinvader wrote:We don't need another db-taxing behemoth.

I agree.

Neo Kaiser wrote: Core Additions:
* Database entries.

*Nach wipes Nestopia off his hard drive.

xamenus · Post by **xamenus** » Fri Jun 13, 2008 7:37 am

Nach wrote:*Nach wipes Nestopia off his hard drive.

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).

You may find the new NES XML format promising, though...

neo_bahamut1985 · Post by **neo_bahamut1985** » Fri Jun 13, 2008 4:19 pm

Nach wrote:
*Nach wipes Nestopia off his hard drive.

\

It's not that bad! It can't be as bad as Nesticle.

Rashidi · Post by **Rashidi** » Fri Jun 13, 2008 5:08 pm

if Nach releasing NES Rom(z) database, i would use it as external database instead

ZH/Franky · Post by **ZH/Franky** » Fri Jun 13, 2008 5:39 pm

*downloads new version*

declan · Post by **declan** » Fri Jun 13, 2008 11:30 pm

Yesturday Franky wrote:I swear you people are insane...

Bye

lol

welcome back XD

ZH/Franky · Post by **ZH/Franky** » Sat Jun 14, 2008 12:07 am

"Bye" in that context meant that I was no longer willing to take part in the discussion.

You know, frustration and all that.

Neo Kaiser · Post by **Neo Kaiser** » Sat Jun 14, 2008 6:27 am

xamenus wrote:
Nach wrote:*Nach wipes Nestopia off his hard drive.
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).

You may find the new NES XML format promising, though...

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! :-p

Rashidi · Post by **Rashidi** » Sat Jun 14, 2008 7:05 am

Neo Kaiser wrote:... how to fix the headers. Hell I fixed all my ROMs headers! ...

is the result from:

Code: Select all

goodnes fixnes

realible?
is there any other program that can fix a bunch of NES ROM' header automaticaly?

EDIT:
i also agree with with:

If the iNES format is insufficient then another format must be made.

format that would cure the header/mapper/mirroring problem that plaque the current nes rom format.

FitzRoy · Post by **FitzRoy** » Sat Jun 14, 2008 11:37 pm

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.

DancemasterGlenn · Post by **DancemasterGlenn** » Sun Jun 22, 2008 6:41 am

Arbee released the 1.4 source overlay. Yay! Thank you arbee.

diminish · Post by **diminish** » Fri Jul 25, 2008 12:27 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?

tetsuo55 · Post by **tetsuo55** » Fri Jul 25, 2008 2:52 pm

FitzRoy 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.

the importance of sound verification and databasing across all systems in the emulator scene

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

kick · Post by **kick** » Thu May 21, 2009 6:38 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.

What you're actually doing is applying the aspect ratio correction twice

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.

diminish · Post by **diminish** » Fri May 22, 2009 12:00 am

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.

FirebrandX · Post by **FirebrandX** » Wed Nov 18, 2009 9:38 am

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.

kode54 · Post by **kode54** » Wed Nov 18, 2009 12:45 pm

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.)

FirebrandX · Post by **FirebrandX** » Fri Nov 20, 2009 9:58 am

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.