nesdev.org

Standardized advanced compression (7ZIP), proper integrity checking, proper naming schemes including a global naming system for linking different systems. Multiple name to rom linking. Ease of use, to support .GAME requires almost no code for the emulator itself and is more simple than an XML parse...

Agreed, I don't think INES is the best solution, but what you have offered is merely a minor improvement. yet it is exactly the kind of minor improvements which has lead in the past to the proposal of UNIF and iNES2.0 formats... what would you suggest as a major improvement? Well this is taking the...

Because a homebrew game might be released early and often, a database (or section) designed for homebrew should probably not list outdated dumps. For example, the entry for LJ65 on pdroms.de lists only the latest version (0.41). But common ROM cataloging tools are designed for commercial games, and...

As a developer I look at what you have done etabeta and go, what do I get out of it? If you can't offer developers a positive benefit they aren't going to take a new thing up. well, it replaces the need of a mapper number with a string of the board name: there would be no risk of multiple boards as...

Thanks for the replies to 65024U and MottZilla as well. I hope you won't get offended if I merged the counter-replies to your critics in a single post Well I definently think this is cool but I kinda think that it's a bad thing. iNES is the standard for a reason, so it can be standardized. I don't t...

thanks a lot for the comments, tepples In other words, "Now supports Pasofami split format!" I was not sure Pasofami format was exactly like this (no files seems to be still available), but then yes: I have resurrected the separate PRG/CHR thing But then how can a homebrew game add itself ...

Even if I've spent quite some time, in the past year, to improve compatibility in the NES emulation of MESS (by adding new mappers, by adding support for UNIF files and by implementing preliminary iNES 2.0 support), I have never been really happy with the current NES formats. Being my background mai...

this is true for iNES files, I don't think the same applies to FDS games

as for the reason why the game only works in NEStopia, you might want to take a look to its source (src/core/NstFds.cpp) and see how the problematic accesses are handled

thanks a lot guys for the answers (especially doppelganger for stepping through the code) it seems I have to add Snow Bros to the list (already including AD&D Hillsfar and Bill & Ted) of games failing if MMC1 detects INC 0xffff... it seems I will need to fix this problem sooner than I hoped ...

Hi, I post this here because I feel like the problem might be something very easy... however, I'm currently initializing MMC1 emulation by setting reg0 to 0xf, other regs to 0 and finally refreshing NMT, PRG and CHR like I would during emulation. the result is that at start I get bank 0 mapped in 0x...

if ( (!mmc3_alt_behavior || old != 0 || clear) && counter == 0 && enabled ) irq = true; @Blargg: I'm not 100% sure if I read correctly your code (and I wasn't able to find any clear answer searching though old topics, even if probably it is somewhere), so I have a question. Assume t...

thanks a lot for the answer, bootgod... however, I'm now a bit more confused than before ;) given that it seems very hard to find precise info on these dual carts, let me see if I have at least git the basic fact correct: a. Nantettatte Baseball!! was a Sunsoft cart with a small slot where the user ...

can anyone shed some light on the Sunsoft "Double Cassette System"?

Is there any info available in addition to NEStopia source?

what are the difference between this and plain Sunsoft-4/NTBROM?

which games use this? (Nantettatte Baseball?)

thanks in advance

oh great! thanks for checking.

I hadn't thought to bus conflict (because the old mapper 185 discussion claimed the game writes to addresses which would not suffer conflicts), however it seems the problem is not bus conflict: 1st write: 0 to 0x805c (value in memory: 0) 2nd write: 2a to 0x805d (value in memory: 2a) on the other han...