nesdev.com

Personally, I think the best bet is to stick with UNIF since most modern emulators do support it. The only problem I see with UNIF, is there is no official list of boards. This doesn't seem like an impossible goal to me. I don't think it is neccessary to stick strictly to board names either, especially with unlicensed games.

For instance, Color Dreams/Wisdom Tree/Bunch/AGCI all use the same kind of board, but there are at least 10 different boards with useless or no names at all. The only difference though is the lockout defeat schemes used. So you could dump all that stuff into one board desc like "CDR-LS377" as they use an LS377 as a mapper and CDR is a company abreviation. I think it is neccessary to have an abreviation like that, because there very well could be other boards out there that use an LS377 as well, but in a different manner.

Most other unlicensed boards do use conventions already. Like Tengen boards could be called "TEN-8000xx" where xx of course is replaced with appropriate number. Boards from AVE could be called "AVE-NINA-xx".

Boards from Camerica would need to be named by their mapper chip because the "BIC-xx" board names sometimes conflict. So you could call them "CAM-BF909x" refering to the BF9093,BF9096,BF9097, etc.

In the end, there just needs to be some collaboration in coming up with the names and they need to be defined somewhere like on the wiki.

And as a side note, I also like the idea of have ROM version stored somewhere.

People won't see it that way. They'll see it just the opposite.

"This format doesn't work in my emulator? Tough! Why should I use such a silly format!"

If you want this format to gain ANY ground, you have to make it as friendly for the user as possible... as they're ultimately going to be the ones that determine how much ground it gets.


Besides... from the get go you're pretty much declaring that this format is to have zero backwards compatibility. Which not only means it won't work in old emulators... but it won't work in ANY emulators for a good while. NEStopia is possibly the only "mainstream" emu still in very active and steady development... which means if Marty decides to impliment support for it, it'll pretty much be Joe Gamer's only option. People that use different emus (not necessarily out of date) will be SOL.

EDIT -- maybe Mednafen too? Though I don't know if the NES area is still being worked on?



I guess I don't see a distinction between unanimously coming up with a common board name and coming up with a designated mapper number. The only real difference is a string vs. integer.

*shrug*

Either way though. Updating UNIF would work -- but that would require the same emu update demand. Unrecognized board names won't load in popular emulators -- but most iNES mapper numbers are already covered.


EDIT AGAIN:



But why? I mean really... give me one single advantage to putting SRAM in the ROM image? It doesn't make any sense, doesn't offer any benefits, and adds a handful of complications for both emu developer AND emu user.

People that keep their ROMs on read-only media (a la CDs) won't be able to have saved games. Emus with .zip or other compressed file format support will have to recompress the ROM every unload. People wanting to retain their old save games won't be able to without having to do manual editing (which may seem easy for you, but Joe Gamer is generally clueless about such activities).

So those are some downsides -- what upsides do you have in mind for wanting to include SRAM? And do they outweigh the problems?

There isn't, and using just a number would be fine too. But using a string just seems more meaningful than a number.

if this is going to work, we all need to agree.

bootgod, i agree with you. we should fix unif. but instead of shorting the board name like ten-8000xx i would just leave it tengen-8000xx. minor details, probably not a big deal.

no need to have sram in the file; that goes in another file.

also, i think instead of having it be MAPR, i would suggest BOARD, i think thats more what it is. then where the BOARD fails, either from home brew or unknown boards, create a new chuck.

new chuck: not sure what to call it. CUSTOM ?

where if this chunk is present then a structure like discussed earlier could be used:

program rom size:
program ram size:
character rom size:
character ram size:

conroller: (where controller could be nintendo-mmc1 ?)

region:

i guess an improved ines header kinda. where either the custom or board name could be used. the purpose of this would be for the games/carts that do not work with unif and for home brew games that are either boards with eeproms, or no boards and someone is using chips on a bread board ?

hope this makes sense. ideas were comming as i was typing.

matt

also, for mappers or boards that are multicarts like 6 in 1 or 100 in 1 or what ever, those are boards themselves. so there would be a board chuck for that like ILLEGAL6in1 or something. better name needed though. also i have not looked at what those boards are.

matt

as i said before i dont think the update should be an issue. anyone using an older emu probably still has older roms. if they get newer roms, they can also get a newer emu too. also, with bootgods data base we could make a conversion util too.

One thing I just don't understand:

why people keep posting to these "let's extend this file format" threads with "I like this other format better". One person keeps mentioning it seeming every other post (and did the same thing in the last iNES update thread). OK, you like UNIF, but this thread isn't about UNIF, it's about making something iNES-like or extending iNES. "Use UNIF" is not an extension of iNES, and not appropriate here.

End rant.


Criticizing the idea just fuels the fire of the opposition. Stick to the simple question: how is the proposal better than how things currently are?

[MAPR] for a block name is misleading, it probably should have been called something else. btw, block names have to be 4 chars.

It would be nice if there was block for ines mapper, I suppose you could create one [INES]. I know it really shouldn't need to be there, but at least if an emu didn't recognize the board name, it could fall back on that.

TOPIC DRIFT

Sorry, but we are not here to talk about UNIF. Let's talk about the file format provided.

_________________
http://www.jamesturner.de/

I understand what you mean, but I disagree, I think it's totally on-topic. Otherwise you have one group going in the fix INES direction and another going in the UNIF direction. Which is counter-productive IMO.

the topic was new file format. i thought ines, unif and everything inbetween was on topic. seems blargg was right, this topic is doomed; but i kinda knew that.

I for one don't want backwards compatibility; I want to circumvent iNES alltogether. Don't you think though a different signature for a different format seems appropriate? Detecting between iNES and a new format via a 1A and 1B should be simple enough too heh


Colloquially it may be a ROM image but it's already much more than that; why should or shouldn't a game with SRAM be thought of similarly to a FDS disk?

Also technically trainers aren't ROM, they are just code loaded into 7000 before the game is started. One can use trainers in any emulator whether or not they support it by just placing the trainer at 7000-71FF in SRAM and loading SRAM along with the game. I support removing the iNES trainer.


Here is how I plan to do things in my emulator:

Signature, Game type (together 16 bytes)
Data type string (8 bytes), data size in bytes (32bits), data offset in file (32 bits)
"
"
"
header terminator character or string.

Chunk format without UNIF complexity. I'm also going to incorporate FDS into the format since the FwNES images are deficient in real hardware (the disks can actually store around 66400 bytes)

Someone once mentioned a hybrid format, where you have your normal iNES file, and then just slap UNIF chunks to the end of the file. That seems reasonable to me. You maintain backwards compatibilty, so long as the file is not rejected for having extraneous data at the end. If the UNIF blocks exist, then they supercede anything in the iNES header. I can't think of anything off-hand where this would be troublesome... anyone?

perhaps we/someone could test that and see how current emulators handle it. i dont think it is the best solution but should work to overcome the problems with ines and also push the use of unif at the sametime; a slow transition.

matt

The 1A is there for a reason, the same reason that PNG uses it: to stop MS-DOS TYPE from continuing to read the file.


Because the SRAM can be cleanly erased without affecting the ROM.

BootGod: I think I'm the one who suggested a UNIF file appended to the iNES file but without the PRG and CHR chunks. I called it iNIF.