New File Format
Moderator: Moderators
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.
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.
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
http://nemulator.com
Too ugly! The remaining 8 bytes of iNES should be enough to expand it without breaking compatibility.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?
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')
...
Last edited by James on Wed Sep 13, 2006 12:25 pm, edited 1 time in total.
get nemulator
http://nemulator.com
http://nemulator.com
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.
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.
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.Bregalad wrote:Again, I'm against ANY image in the ROM, that's stupid.
get nemulator
http://nemulator.com
http://nemulator.com
-
- Posts: 345
- Joined: Fri Jul 29, 2005 3:40 pm
- Location: near chicago
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
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
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.James wrote:
- Game name
Game description
Box images
Checksum (to check file integrity, not for game identification/'fixes')
...
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.
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.
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
http://nemulator.com
-
- Posts: 345
- Joined: Fri Jul 29, 2005 3:40 pm
- Location: near chicago
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
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
-
- Posts: 345
- Joined: Fri Jul 29, 2005 3:40 pm
- Location: near chicago
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.
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.Disch wrote:RAM usually doesn't exist in ROM.WedNESday wrote:I think that having the SRAM in the ROM file is an excellent idea. Not only is it very realistic
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: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?
Oh noes! The ROM hax0rs will never figure out how to alter the checksum. For shame!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.
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).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.
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.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.
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...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).
get nemulator
http://nemulator.com
http://nemulator.com
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:Yet another doomed thread about improving the iNES file format.
I know that they can still be hacked! But it just makes it more difficult.blargg wrote:Oh noes! The ROM hax0rs will never figure out how to alter the checksum. For shame!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.
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