New File Format

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

If updating iNES, how could we describe more precisely the ammount of PRG/CHR ROM? iNES defines PRG in 16KB pages, but there should be support for smaller ROM's, no? Are those games even compatible with older emulators, or do their ROM files contain duplicated data to fill the necessary 16KB?

I think board names stored in text format are useless, especialy when we have only 8 bytes left to implement new stuff. Codes would be just fine.
User avatar
James
Posts: 431
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Post by James »

For a backwards compatible iNES header -- how about placing a unique byte (or bytes) in the unused header area to indicate that an updated header exists at either a specifc file offset (also in the header) or simply at the end of the file?
get nemulator
http://nemulator.com
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

James wrote:For a backwards compatible iNES header -- how about placing a unique byte (or bytes) in the unused header area to indicate that an updated header exists at either a specifc file offset (also in the header) or simply at the end of the file?
Too ugly! The remaining 8 bytes of iNES should be enough to expand it without breaking compatibility.
User avatar
James
Posts: 431
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Post by James »

Yeah, it's ugly, but it's flexible. Would allow for some pretty neat stuff too while still retaining backwards compatability:
  • Game name
    Game description
    Box images
    Checksum (to check file integrity, not for game identification/'fixes')
    ...
Admittadly, this is all fluff, and I'm sure many would be opposed to having such 'useless' info attached to the rom, but I would certainly like to have it. Heck, make it something like (buzzword alert) XML, and it can have as much or as little info as you want it to have.
Last edited by James on Wed Sep 13, 2006 12:25 pm, edited 1 time in total.
get nemulator
http://nemulator.com
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

I've to mostly agree with Dish.
Also, there is a infinite number of boards, and noone can come with a complete finished, official list. I think text boards name in the header isn't a good idea. It it would to be, only the second letter would care anyway. The first letter just is an alternate way to tell the mapper number, the second letter will tell the variant of board of that mapper and all this is just followed by "ROM" on normal cards, and "EPROM" on prototypes allowing the layout for standarded pinout EPROMs. So only the second letter would really have meaningfull information, but as long as PRG/CHR size is already mentionned and SRAM size have to be mentionned, the battery bit is also here to know if the RAM is backed up or not. Definitely, there is nothing we have to do with board names in the file.
Merge SRAM file and ROM file is a bad idea overall. You cannot copy/paste your SAV files to keep an infinite amount of game saves, wich isn't cool. Also, you cannot submit SAV files without submitting the whole ROM, and this kills any backward compability.
I think the second mapper nybble that tells only the high 8-bits of the mapper number still have another free nyble in the same byte. Something like this would be welcome in this byte :
bit 0-1 -> SRAM Size : 0-> NO SRAM; 1-> 8kByte 2-> 2x8kByte, 3-> 32kByte
bit 2 -> iNES version number : 0-> old iNES; 1-new iNES (notice : If old iNES, I think 8kb SRAM has to be assumed even if not specified)
bit 3 -> Someone else's parameter would come here
bit 4-5 -> High 8 bits of mapper number

EDIT :
Again, I'm against ANY image in the ROM, that's stupid. Buy the game or search the net if you want any.
Game Name is already specified in the file name of the ROM. I'd just go with the country and revision, that would fit one more bye I think.
Useless, lumbering half-wits don't scare us.
User avatar
James
Posts: 431
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Post by James »

Bregalad wrote:Again, I'm against ANY image in the ROM, that's stupid.
Certainly a valid opinion, but why not give the option? If the header is flexible enough, it shouldn't matter whether the image is there or not (nor require space if it isn't), but for those who want it (or any other info), the option is there.
get nemulator
http://nemulator.com
mattmatteh
Posts: 345
Joined: Fri Jul 29, 2005 3:40 pm
Location: near chicago

Post by mattmatteh »

if unif were to have another revision, what would have to be fixed and how?

i dont see the point in updating ines. if an emulator is going to support both then its new enough to support a new file format. if its too old, then the user probably has an old collection of roms that only works with older ines files.

i would rather come up with a new file format or update unif, than update ines.

matt
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

James wrote:
  • Game name
    Game description
    Box images
    Checksum (to check file integrity, not for game identification/'fixes')
    ...
What are you trying to do here people? Saving images along with the game? This is just crazy if you ask me. The goal of an emulator is to accurately execute a program, as the real platform would. Anything more than that is beside the point. I see no need to boost the size of ROM files way up just so you can see the box cover everytime you play the thing.

NES games are often so small that their size is comparable to that of JPEG images. If having the cover of a game means doubling the download size, no thanks. And it's not like you need that kind of stuff all the time. If you like pictures, build you own collection aside from the ROM collection.

Anything that is not pertinent to the execution of the program should not be contained in the ROM file (the PROGRAM!).

The goal here is to keep old games alive, and not to pirate them to the smaller possible detail.

Anyway, that is only my opinion. It's not like I'm the owner of all truth.
Mednafen
Posts: 60
Joined: Wed Sep 13, 2006 12:45 pm

Post by Mednafen »

Place a special, unique magic ID in the last 4 bytes of the iNES header.

Put UNIF header and chunks after all iNES data(PRG and CHR and trainer?).

Use new PRG/CHR chunk types to specify the offset(within the file) and length of each PRG/CHR ROM with the file.

Profit!
User avatar
James
Posts: 431
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Post by James »

Well, maybe to put this in perspective, I'm thinking about my DVD collection. All of my DVDs are in a box in the basement. The content, along with cover art, actor info, studio info, etc. is saved on a computer and played from there (think of each DVD directory as a rom file). My DVD player (i.e., emulator) reads all of the DVD info and I can view cover art, sort by release date, director, etc. I own the DVD (not pirated), but I still appreciate having all of the details easily accessible.

Now, this could all be stored in a separate database, but why not keep it with the game itself in a single file? Seems less complicated.

With the ubiquity of broadband and giant hard drives, additional file size should not be an issue. Although, again, if the header is flexible enough, feel free to strip out anything you don't want without worry.
get nemulator
http://nemulator.com
mattmatteh
Posts: 345
Joined: Fri Jul 29, 2005 3:40 pm
Location: near chicago

Post by mattmatteh »

the only thing that could be there is the game name, but the images, why ? maybe if your file broswer showed them, but that is kinda overkill.

the checksum is kinda pointless i think. i would use it to verify a rom but use a known checksum that wasnt in the file.

seems like this thread is going to be long.... perhaps we should figure our options.

first figure out if we want to fix ines, fix unif, or come up with a new format.

i vote to come up with a new format.
[edit] new format similiar to unif or fix unif

also, after this is decided, perhaps start the discussion of a standard save state? my emulator is not done and doenst have any save state yet (nothing worth saving anyway). has anyone tried the format proposed suggested awhile ago? the save state format might need a new thread!

matt

matt
mattmatteh
Posts: 345
Joined: Fri Jul 29, 2005 3:40 pm
Location: near chicago

Post by mattmatteh »

reply to what james said:

i was thinking of that too at one point. but then figured i would just put all that in a folder. then rom file, images, manuals, and perhaps any notes on playing the game like in a html page or something. then name the folder the game title.

matt
User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg »

Yet another doomed thread about improving the iNES file format. I was hopeful the last time, but it's clear that such threads are heard as a call for everything but the kitchen sink that people have been saving up over the years. Same for the save state format threads from earlier. :(
Disch wrote:
WedNESday wrote:I think that having the SRAM in the ROM file is an excellent idea. Not only is it very realistic
RAM usually doesn't exist in ROM.
A .nes file is a virtual NES cartridge, though I'd rather not have it modified when I save my game. I like being able to have multiple saved games and unmodified game files.
WedNESday wrote:If you believe that checksums are a waste of time, then what is the point of providing two bytes that tell you how many banks there are?
OK, I give you an iNES file that's 32784 bytes ($8010). Does it contain 16K of PRG data and 16K of CHR data (2 8K chunks), or 32K of PRG data? That's why. A checksum is entirely redundant, and which checksum do you use? CRC-32, SHA-1, MD5, etc.?
WedNESday wrote:I am very interested in a checksum because it means that people can't hack ROMs for there own needs. GameBoy and SNES ROMs have them and most emulators ignore them, but I like the idea of having a clean ROM image.
Oh noes! The ROM hax0rs will never figure out how to alter the checksum. For shame!
WedNESday wrote:I think that the reason that UNIF never took off is that the whole concept of having data chunks and so forth was just a bad idea.
Chunks allow anyone to add additional data to the file without breaking any programs and without having to notify anyone of this addition. Supporting chunks is trivial (I posted a single page of code a while back that completely implemented a chunked file format).
Memblers wrote:Hm, speaking of trainers, since they apparantly have no legit use (cartridge-wise), couldn't that also be hijacked for the new header info? Just say there's a trainer on the ROM, and have the header (with signature) in there.
Hah, I love this idea. Just put a JMP RESET at the beginning of the trainer data (or whatever would skip the rest) and you have 509 bytes for more info. Sweet.
User avatar
James
Posts: 431
Joined: Sat Jan 22, 2005 8:51 am
Location: Chicago, IL
Contact:

Post by James »

Chunks allow anyone to add additional data to the file without breaking any programs and without having to notify anyone of this addition. Supporting chunks is trivial (I posted a single page of code a while back that completely implemented a chunked file format).
This is what I was talking about when I was referring to a flexible format. I'm ashamed to say that I've never even looked at the UNIF format... :oops:
get nemulator
http://nemulator.com
WedNESday
Posts: 1284
Joined: Thu Sep 15, 2005 9:23 am
Location: Berlin, Germany
Contact:

Post by WedNESday »

blargg wrote:Yet another doomed thread about improving the iNES file format.
Merely your own opinion, and frankly a poor attitude to take so early on. Some of us are trying quite hard to make this work.
blargg wrote:
WedNESday wrote:I am very interested in a checksum because it means that people can't hack ROMs for there own needs. GameBoy and SNES ROMs have them and most emulators ignore them, but I like the idea of having a clean ROM image.
Oh noes! The ROM hax0rs will never figure out how to alter the checksum. For shame!
I know that they can still be hacked! But it just makes it more difficult.

However, despite your anti-new file format views, you have made some excellent points. I am very interested in having a bit/byte that selects 50hz/60hz or maybe a region code.

As for having the SRAM in the ROM. I stand by it. If you want to copy it out, then just use a hex editor. As for "your favourite (old) emulator not being compatible", tough! Why are you using such an old emulator? Use one of the new ones that becomes compatible, or download the source and modify it.

Here is a thought for the info byte;

1. Horizontal/Vertical Mirroring
2. SRAM
3. Trainer (WTF is a trainer anyway???)
4. 4 Screen VRAM
5. 1 Screen Mirroring
6. 50hz/60hz Select
Post Reply