I know this topic has come up several times in the past and I've thought about it myself recently with the mess of Konami VRC games which use the same mapper yet not the same registers.
I think the general thoughts on altering the format or changing anything are that if it's not backwards compatible, then no one will use it. I hadn't heard anything like what my idea would be. I think there are atleast 3 unused bytes (0D,0E,0F) in the iNES header which I think could be used as a 24-bit file address pointer. The program would check this address for a second header, which could easily be appended to the file, and you wouldn't have to do anything fancy. An older emulator would see the ROM the same way. But a newer emulator could ignore the old iNES header, and read our new header located at the pointer. Then we could better define all the different variables in our new header, all while maintaining backwards compatibility.
It wouldn't solve the issue of having a database and a hash check for ROMs with original iNES headers, but perhaps over time people would update their sets. And it would help with hacked and translated roms that wouldn't match the hash values.
Any thoughts on this? I think it's a good way to add a new header, though what information would be stored there would need to be defined.
Some ideas I like would be changing mapper numbers around for a new format. I remember reading changing mapper 6 (used by some FFE mappr) to be the MMC6 variant. You could change 2 and 4 to be MMC-2 and MMC-4. You could have a sub-variant too I suppose so that you could have Mapper 1, Sub 0 be a regular MMC-1, but then have SOROM be Sub 1, SXROM sub 2, etc.
Does anyone think that any idea like this will ever get anywhere?
There were more detailed suggestions in the past and those didn't seem to get anywhere... so I doubt this one will.
There is simply no perfect solution for this, because even if you somehow find a way to describe every cart in existence, the hardware gurus will continue to come up with new stuff...
It would be really nice if emulators were capable of emulating each chip in the cart, following a wiring schematic that would be provided with the ROMs, but that seems to be out of the question.
I'm a total noob when it comes to advanced hardware stuff, but is it really that hard to emulate in software those programmable chips used in the PowerPak, for example, so that mapper and wiring information could be provided with each ROM? Then emulators would be just like a real NES, communicating with the cart through a slot without having to care about what happens outside of the console...
Quick answer: your problem doesn't translate a mapper ID problem.
Long answer: regarding the Konami mappers (21,22,23,24,25,26), they ARE different ones, even if operations and registers look very similar. Perhaps the docs bring some "code crush" (merging), but it isn't the case. So, leave the current mapper number and take a decision about merging them into a single subroutine. I had to put a CRC32 check to identify mapper 26, since the present GoodNES is reassigning 26 into 24.
MottZilla wrote:
I think the general thoughts on altering the format or changing anything are that if it's not backwards compatible, then no one will use it. I hadn't heard anything like what my idea would be. I think there are atleast 3 unused bytes (0D,0E,0F) in the iNES header which I think could be used as a 24-bit file address pointer.
Those bytes are already used to detect non-conforming headers such as "DiskDude!".
Fx3 wrote:
Quick answer: your problem doesn't translate a mapper ID problem.
Long answer: regarding the Konami mappers (21,22,23,24,25,26), they ARE different ones, even if operations and registers look very similar. Perhaps the docs bring some "code crush" (merging), but it isn't the case. So, leave the current mapper number and take a decision about merging them into a single subroutine. I had to put a CRC32 check to identify mapper 26, since the present GoodNES is reassigning 26 into 24.
But the documents seem to list multiple possibilities for register lines on mappers 21, 23, etc. I do handle all the VRC4 and VRC2 in one mapper. But a hash check is required. What I know for sure is a mapper id problem, is the MMC1 variants and MMC6. I agree with what I believe Disch said in the past, that it shouldn't take a hash check to figure out special settings for a game.
Tepples, you could use the bytes for both, as you could examine if they point to a valid secondary header, and if not assume it is garbage.
To be clear this is just to bring up discussion on the subject. I'm not proposing that anyone here needs to do anything. Also, I pretty much accept the fact that hash/database checks are going to be required no matter what.
Do any emulators (besides Nestopia) actually use or support iNES 2.0?
Dwedit wrote:
Do any emulators (besides Nestopia) actually use or support iNES 2.0?
I wanted to... but was still waiting for it to be finished/released. Kevtris was talking about it years ago, but then it just kind of fizzled out and disappeared. I never saw an official spec for it.
Personally I don't get what the big deal is with cross-emulator compatibility, especially if nobody but you uses your emulator.
tokumaru wrote:
I'm a total noob when it comes to advanced hardware stuff, but is it really that hard to emulate in software those programmable chips used in the PowerPak, for example, so that mapper and wiring information could be provided with each ROM? Then emulators would be just like a real NES, communicating with the cart through a slot without having to care about what happens outside of the console...
It's pretty hard and very tedious to come up with a sequential logic parser/simulator. I think if we're going that far, we may as well low level emulate the CPU and PPU too to properly interface the mapper. Everything doesn't have to be emulated to the gate level since there'd be no benefit, just to the digital symbol level. So for example a binary decoder would be abstracted to a switch block, a register to variables for the output and clock state. The overhead would be enormous but maybe with clever coding it could run in real time on a modern system... Considering how hard it is to get an iNES enhancement consensus, getting this adopted would be impossible :)
Oh it's at lest the 36th time something like that comes up... and like the 35 previous ones it's going to nowhere so I don't knwo why I even answer.
iNES2.0 was the closest to get to somewhere. With SRAM sizes added to NES header it's perfectly possible to emulate MMC6 and MMC1 variants without any problems : MMC6 is MMC3 but with 1kb RAM integrated, and MMC1 variants are just more ROM/SRAM controlled with higher CHR pins.
Bregalad wrote:
Oh it's at lest the 36th time something like that comes up... and like the 35 previous ones it's going to nowhere so I don't knwo why I even answer.
Because I asked nicely? :p
I missed most of these conversations and so I didn't get to heard too much about various problems that exist with iNES. I didn't realize iNES 2.0 that was never finished had WRAM sizes which would let you ID MMC6 that way, as well as MMC1's variants.
In fact there was already a variant of the original iNES header before iNES 2.0 that had a PAL/NTSC flag and SRAM size flags, which nobody used.
Honnestly people should try to make publitcity for iNES 2.0 instead of coming up with new format.
By the way a header at the end of a file is not a header but a footer
For example at the end of .spc files there is a 256 byte footer containing DSP data.
I always thought it was far more common to see the PAL flag in the filename, usually denoted by an (E).
Well searching around I finally found Kevtris's iNES 2.0 here:
http://nesdev.com/bbs/viewtopic.php?t=2090
Am I missing something or why isn't this considered to be complete? The lack of being able to specify 0k wram I heard was brought up. But then wouldn't the original WRAM flag just not be set? I do agree with you Bregalad, that iNES 2.0 outlined by Kevtris makes the most sense of any idea. So the real question I have then is why isn't this thing taking off? I suppose someone would need to make a utility to allow people to batch upgrade their ROM sets to really get it going.
MottZilla wrote:
But the documents seem to list multiple possibilities for register lines on mappers 21, 23, etc. I do handle all the VRC4 and VRC2 in one mapper. But a hash check is required. What I know for sure is a mapper id problem, is the MMC1 variants and MMC6. I agree with what I believe Disch said in the past, that it shouldn't take a hash check to figure out special settings for a game.
Could you tell me a few examples? I really dunno there's a Konami game that rufeses to work in my emu.
I think the "MMC1 problem" may just be MMC1 games which do not support bankswitching within CHR RAM, like Dragon Warrior 3 & 4.
Personally, I'm against adding a bunch of garbage around the ROM contents mainly because it makes it harder to extract them for the purpose of burning chips, as if people didn't already have enough trouble when doing that.
UNIF sucked because of this. Extracting the ROMs should be a simple task, simple enough to be accomplished without the use of any tools. It took me a while to locate the ROMs inside a UNIF file the last time I needed to extract them.
Tiny Toon Adventures (map23) works fine here.
Yeah I came up with an ines 2.0 extension that I used on the FPGANES. It was designed to be 100% backwards compatible, and specify the exact stuff needed to run games that didn't fully conform or could fully be "explained" by a stock ines header.
It was very carefully designed to NOT break "dickdude!!!" detection on emulators. The reason I never released it was because I was using an old goodNES set and I have to go through all 3000-5000 ROMs again by hand and update my tables :-/
I went through all the ROMs several times and it takes days and days, so I just gave up for now. I can post what I had though and maybe headers or something of my doctored ROMs.
The point of 2.0 was NOT as a replacement to 1.0, but just a way to specify extra needed information if the header wasn't enough. It was designed to be used on maybe 1-2% of ROMs at the very most- stuff that is using CRC checks and other hacks right now. The idea is to remove the hacks and have the header specify the few very specific things needed.
Tables for some sort of database? For updating the 1-2% of ROMs that need more information in their headers?
I think everyone would like you to release whatever you can. Otherwise I doubt anything will ever happen.