There are a couple reasons why I don't want to include this stuff at this time (it IS possible to add it later).

1) There are games which were released in the US and Japan (and possibly other places) with the exact same ROM data.

2) Some games (such as those made by Codemasters) only have 1 ROM, and are designed to self-detect PAL/NTSC mode, and autoswitch.

3) For many of the ROMs out there, most people cannot difinitively say where they really came from.

4) We already have a sorting system in place (albeit it's not perfect, but it does exist) as found in GoodNES.

5) We don't really know exactly what regions existed for NES games even today. This is lockout chip controlled more than anything

6) This information is not needed to run the games. The only info we really need to know is PAL/NTSC, and autodetect. Everything else is not required to run the game.

At this time, there's just not enough information about this stuff for me to feel good about it... I'm sorry that your idea didn't make it into the final draft of the spec, but I just didn't feel there was a rock solid foundation for it yet. This could very well change in the future.

As for tokumaru, I see absolutely no followups to the proposal I originally posted. Did I miss something I shouldn't have?

That's true, I didn't say anything about your proposal. In fact I think it is really good, you seem to have put a lot of work into this. What bothered me was the fact that soon Quietust put together that tool supporting your format, as if it was already some kind of "truth".

I felt that there were many opinions that didn't get the attention they deserved. I wish I could actively work on this, but since I'm not an emulator author, I'm not as familiar with the problems of iNES as other people are. I guess I can only watch how this goes now.

I appreciate your effort on posting such a complete description of a new format, really, but as soon as you did, everything that was said before was completely left aside.

I'm not really upset at anyone, I just want to see a good, backwards-compatible format being adopted. I wish there was a better involvement of the whole community, that's all.

I wish there was a better involvement of the whole community, that's all.

There was plenty of "community involvement" back in this thread, but, as you can see, nothing actually came out of it until kevtris posted a detailed proposal halfway through page 5. A few concerns were voiced (most of which were not actual problems, but just desires for out-of-scope data), and the format received a few minor updates. Personally, I'm glad kevtris has decided on this format, and that's why I wrote the header editor for it - without his initiative, nothing would have ever happened and the thread would have just died, like all of the other "new file format" discussions that have arisen in the past.

Previous 'new file format' threads all suffer from one thing - wanting perfection and arguing over the best way to attain it. Perfection, unfortunately, cannot be attained. We could argue (and, let's face it, we have been) for years on how to devise the perfect file format, but we've never gotten anywhere. "NES 2.0" addresses all of the important problems with emulation - size limits, mapper limitations, ambiguity in mapper numbers (especially some Famicom ones, where one number can be up to 5 different configurations), varying RAM sizes, and special details for VS Unisystem stuff which would otherwise require checksum lookups.

Implementing a brand new file format won't work, since everybody will have to keep two copies of every ROM (so they can actually use them in the many emulators which don't support the new format), and nobody wants to do that - this is part of the reason why UNIF failed. With "NES 2.0", an older emulator could read and run it just fine using its CRC checks to get everything to work, while newer emulators updated ones can use the extended header to handle everything without having to resort to checksum-specific hacks.

It's not perfect, it doesn't have everything, but it works - it's backwards-compatible (so users can just patch their ROMs and keep using them in most old emulators), it fixes the frequent headaches, and at least two people (kevtris and myself) are actively implementing support for it. With a working header editor, people can actually create "NES 2.0" ROM images and simplify the process of adding support to their emulators, and soon kevtris and/or myself will be releasing a tool to patch all ROMs in the GoodNES set (or, better yet, getting Cowering to add the functionality to GoodNES itself), removing the primary barrier to the new format's acceptance - widespread availability of ROMs, the main factor which caused UNIF to fail (due to resistance to making mass conversion utilities, insisting that every game be redumped before it be released in the new format).

_________________Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

No, but seriously, I'm completely an outsider looking in in that I don't write emulators. The only time I use the ines header is when I'm making repros I haven't made before.

It does seem to me that this format defines the technical specs well. If more is added, it becomes commentary that is somewhat useless to the ines purpose. It seems to me that that the region/pirate commentary is where it belongs when it's placed in the rom's file name.

To me the question should not be what other stuff can be crammed in here, but are there any important technical specs left out in Kevtris's proposition?

I would do things totally different if the new format weren't built for backwards compatability, but I think this specification plugs the holes while leaving a little tar to plug future holes. (can't wait till we find a board with battery backed up prg ram...)

At this time, there's just not enough information about this stuff for me to feel good about it... I'm sorry that your idea didn't make it into the final draft of the spec, but I just didn't feel there was a rock solid foundation for it yet. This could very well change in the future.

Anyone can write an iNES 2.0 spec. The people that tackle the issues and make concrete, realistic proposals and then write actual implementations of them are the ones that lead. Anyone with the skills and desire can do it; nobody has any special status here except that granted voluntarily and individually. All that's happened so far is Quietust has made an experimental program to edit the headers, and Kevtris is making hardware that parses the format. It's the doing that ultimately gives us progress, not talking.

tokumaru wrote:

I appreciate your [Kevtris'] effort on posting such a complete description of a new format, really, but as soon as you did, everything that was said before was completely left aside.

I'd say that he filled a need with something concrete and useful enough to be acceptable. It's also based on a lot more experience (i.e. thousands of cartridges) than probably any of us has, which gives it more authority, at least in my mind. The reason the previous attempts didn't work is that people placed no limit on their proposals. There's no way to come to a consensus when people keep adding more things to the table.

Given Quietust's tendency call SRAM "PRG RAM" in the wiki, that would appear to include the common games The Legend of Zelda (U) and Final Fantasy (U). And even in the more literal sense, where the entire program is stored in a RAM and the battery is the only thing keeping it from becoming a paperweight, that's the case in the early version of Datel's Game Action Replay accessory.

I agree with Tokumaru all the way. Kevtris has done though work and has come up with a solid definition as opposed to us wich just keep sending ideas in the air.
However, since that, while Kevtris has worked hard on testing one thousand of cartridge, his format is totally closed for any suggetion, and it doesn't seem that any external idea was even considered to be added/modified.
After all this format is at least above decent so I cannot complain, but still, I think something a bit better could have come up if more trough from more different people would be brough on it.
As for region check, effectivly, the main problem is that the number of exact regions isn't known, but for me different PAL regions isn't really much important (England and Germany regions doesn't have the same cards I think, because all England cards have a 'A' written on them (as far as I know), and all Germany ones a 'B' (that is all cards I have so far, exept import ones)).
At least, there is different between Japanese and American NTSC machines, on the controllers, on the expension sound wich is lacking in the states, and I've heard the RAW PCM is lacking to, but this info is probably wrong/corrupted because of Battletoads. Also, not all Japanese famicoms support short-looped noise mode.
And I really doubt the exact same ROM is found in Japan and America, because the copyrights that would come up on the screen are totally different. It is always written "Licenced by Nintendo" in America, but most japanese games that aren't by Ninendo most likely don't mention the big N at all in teir title or credits. The release dates are often different, and the copright is more long in the states (typically, a simple "(C) 1987 Capcom" in japan will become like "(C) 1989 Capcom USA co. LTD, Licenced by Nintendo of American Inc.".
Also, I don't like the current country system in the ROM name, because most names are annoyingly long. Almost everyone prefer have their rom named "FF3.nes" rather than "Final Fantasy III (J) - [T-Eng Dejap]" or something like that.

_________________Life is complex: it has both real and imaginary components.

At this time, there's just not enough information about this stuff for me to feel good about it... I'm sorry that your idea didn't make it into the final draft of the spec, but I just didn't feel there was a rock solid foundation for it yet. This could very well change in the future.

Anyone can write an iNES 2.0 spec. The people that tackle the issues and make concrete, realistic proposals and then write actual implementations of them are the ones that lead. Anyone with the skills and desire can do it; nobody has any special status here except that granted voluntarily and individually. All that's happened so far is Quietust has made an experimental program to edit the headers, and Kevtris is making hardware that parses the format. It's the doing that ultimately gives us progress, not talking.

True. Talk is cheap, implementation is what really matters. Props to Kevtris and Quietust for the work, but I am sure they already know they are awesome in that regard.

"Put your money where your mouth is" and flesh out/add more issues to the page. We can reply to each issue and eventually come to a more shared understanding of them. Just don't ramble on, since that kills productivity. Sheesh, I'm sounding like upper management now!

As for region check, effectivly, the main problem is that the number of exact regions isn't known, but for me different PAL regions isn't really much important (England and Germany regions doesn't have the same cards I think, because all England cards have a 'A' written on them (as far as I know), and all Germany ones a 'B' (that is all cards I have so far, exept import ones)).

The only difference between regions which actually affects emulation is timing - 60fps (NTSC) and 50fps (PAL). Special cases like France (SECAM) and Brazil (PAL-60) don't really affect emulation, just possibly the palette (and even there, the difference would be very slight).

Bregalad wrote:

At least, there is different between Japanese and American NTSC machines, on the controllers, on the expension sound wich is lacking in the states, and I've heard the RAW PCM is lacking to, but this info is probably wrong/corrupted because of Battletoads. Also, not all Japanese famicoms support short-looped noise mode.

These differences are irrelevant, since they only affect some machines within the region, and using such a machine would affect all games played on it. This sort of thing would only make sense as a user-configurable option in the emulator (and, even then, it doesn't make much sense to begin with). RAW PCM is fully supported on the Famicom, and only the oldest of the oldest units would lack looped noise.

Bregalad wrote:

And I really doubt the exact same ROM is found in Japan and America, because the copyrights that would come up on the screen are totally different. It is always written "Licenced by Nintendo" in America, but most japanese games that aren't by Ninendo most likely don't mention the big N at all in teir title or credits. The release dates are often different, and the copright is more long in the states (typically, a simple "(C) 1987 Capcom" in japan will become like "(C) 1989 Capcom USA co. LTD, Licenced by Nintendo of American Inc.".

There are plenty of counterexamples to this - with Super Mario Bros, Excitebike, Duck Hunt, Gyromite, Stack-Up, and plenty of other games, the ROM on the USA cartridge is 100% identical to the corresponding Famicom game.

Bregalad wrote:

Also, I don't like the current country system in the ROM name, because most names are annoyingly long. Almost everyone prefer have their rom named "FF3.nes" rather than "Final Fantasy III (J) - [T-Eng Dejap]" or something like that.

If it's really desired, it can be tacked on in "NES 3.0" in a backwards-compatible way, but for now, it's not really needed. Besides, the "current country system" is dictated only by ROM auditing tools (i.e. GoodNES), so either complain to Cowering about it or just tell it to not rename your ROMs.

_________________Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

However, since that, while Kevtris has worked hard on testing one thousand of cartridge, his format is totally closed for any suggetion, and it doesn't seem that any external idea was even considered to be added/modified.

But it has everything needed for proper emulation. Except for like with Squeedo and the PIC's CPU code, but that's to be expected (I guess an emulator could load it seperately, if anyone ever emulates it).

The 16-byte header is pretty cramped anyways, there's over 500 bytes of room for the future with the using the trainer for info idea I mentioned in the other thread. Since it'll inherit NES 2.0's extensions for good emulation, all that extra space could be used for the nice-to-have-but-not-absolutely-necessary things.

I'd still like a comment from kev on how external ROM data would be stored, such as PIC code in Squeedo, or the ROM stored in the speech chip in some Jaleco Famicom games. (if anyone will ever make the effort of manually extracting the ROM like in the CIC chip's case, rather than just record the samples)

I see three alternatives:
1) The data is stored among the PRG bank, as the last bank(s). Code in an emulator/FPGA console front-end/file processing tool supporting the mapper knows how many of the PRG banks belong to the external ROM, and will handle this properly. Code not supporting the mapper will just see an odd PRG size.

2) As above, but the data is stored among the CHR banks.

3) The data is stored after the PRG and CHR banks, where the file would normally have ended. As in the abovementioned cases, code that recognizes the mapper will handle this properly.

Any of this alternatives would do, but I'd like some thoughts on which of these would be the best one.

Do you plan to support any of the Jaleco games with external sample ROM on your FPGA console, btw?

I'd still like a comment from kev on how external ROM data would be stored, such as PIC code in Squeedo, or the ROM stored in the speech chip in some Jaleco Famicom games. (if anyone will ever make the effort of manually extracting the ROM like in the CIC chip's case, rather than just record the samples)

I see three alternatives:1) The data is stored among the PRG bank, as the last bank(s). Code in an emulator/FPGA console front-end/file processing tool supporting the mapper knows how many of the PRG banks belong to the external ROM, and will handle this properly. Code not supporting the mapper will just see an odd PRG size.

2) As above, but the data is stored among the CHR banks.

3) The data is stored after the PRG and CHR banks, where the file would normally have ended. As in the abovementioned cases, code that recognizes the mapper will handle this properly.

Any of this alternatives would do, but I'd like some thoughts on which of these would be the best one.

Do you plan to support any of the Jaleco games with external sample ROM on your FPGA console, btw?

#3 would probably work best - Playchoice-10 ROMs already do exactly this, dropping the Z80 code immediately after the CHR ROM data. In the unlikely (hell, impossible) event that a PC10 ROM have additional non-PC10 data appended, it would, of course, have to come after the PC10 data.

As for the Jaleco sound sample chip, there's 2 ways of getting accurate data: 1. decap the chip and read the ROM (quite difficult), or 2. put together a device to manually clock the chip, record what's on the audio output pin after each clock (could be done by kevtris's 3-in-1 tester with some modifications), and then convert that waveform back to what the chip is supposed to store internally. To my knowledge, neither has been done - all we have is a ~44kHz WAV file of all 16 samples for the Baseball game.

_________________Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum