I think that it's time someone proposed a new file format. I have been rewriting WedNESday recently and I have found the iNES format to be old fashioned and open to all kinds of problems (like people putting their names in the header).
Here is a basic makeup of the file.
PRG-ROM Banks
CHR-ROM Banks
SRAM Bank
Header
Here is the header itself.
00h - N
01h - E
02h - S
03h - PRG-ROM Banks
04h - CHR-ROM Banks
05h - Cartridge Board
06h - Mirroring etc.
Here is an example;
Super Mario Bros.
0000-8000h 2 PRG-ROM Banks
8000-A000h 1 CHR-ROM Bank
N/A
Header (see below)
4E 45 43 02 01 00 01
Please let me know your thoughts, opinions etc. I'll edit this post when I make editions to the format. Now I know that I am not too educated about the ins and outs of certain aspects of NES emulation (esp. cartridge boards), but this is something that I want everyone to contribute to. I am also interested in throwing in some checksums. I'm also very interested in discussing what could go into byte 06h along with the mirroring, trainer, VRAM, SRAM etc.
I don't know man. People have been talking about UNIF for a while and that never really caught, so I don't see why your simplistic new header would either. I have more faith in simplistic headers than UNIF, though.
I don't think checksums are the way to go. Emulators should be able to emulate a game without knowing wich one it is, 'cause it might well not be a commercial game.
A header should be used to identify specific hardware details that you don't have from just looking at the ROM. I think that by now everyone has a pretty good idea of all the different combinations possible for these details, and a new format without the limitations of INES, and not as complicated as UNIF could be made.
Well, I'm not an emulator programmer, I'm a game programmer. So maybe I shouldn't say anything about this.
Something retro-compatible with iNES would be fine, but hard to put in correctly. Again, I'm not an emulator programmer, but a game programmer.
It would be nice to have all emulators emulating things like MMC5 SRAM size correctly, because currently, EACH emulator will come with something different.
It's looking a lot like iNES already. Which isn't too bad, because I like simplicity. If I can make/edit the header for a ROM easily in a hex editor, I'm happy. But I'm pretty sure that one byte isn't enough to define a board type. Actually I like how UNIF spells out the board name.
I don't think a new format will catch on at all. I really think UNIF could, if there was some big archive up for download that included the box/cart hi-res artwork, manuals and stuff inside the ROMs. Most users won't care about the details, they'll just care if an emulator runs their favorite ROM or not.
What I've kinda wondered about before, is why not a footer? Is there already something defined that can be at the end of an iNES file? I'd imagine emulators just ignore whatever is after the ROM data. If it's not too hacky, one could put anything there I guess.
I suggested something like this a little while back:
http://nesdev.com/bbs/viewtopic.php?t=1809
Only I find it's much more feasable to update iNES to make a new version that's backwards compatible, rather than simply making a new format from scratch and it having zero support in 99% of emulators.
Ultimately the plan was more or less shot down. I would still be in favor of such an approach... but really... so far your new format seems to be a re-arranged iNES that's just harder to load.
I would say:
1) keep it backwards compatible as much as possible.
2) have the header at the head (start) of the ROM. Putting it at the end is criminal and makes for MUCH harder file loading, especially in an emu which supports multiple file types and/or zipped ROM loading. An additional footer after the PRG/CHR/whatever else is one thing... but the format should at least give the program a heads up as to what file type this is and the PRG/CHR/whatever else sizes before anything else.
OK, lets say everyone decides to update iNES in a backwards compatible way. The unused bytes in iNES would be used to further describe the game that follows, right?
There were some ROM's out there with garbage on the unused bytes of iNES, weren't there? These would probably break the game in emulators that support the newer format, right? How could this be prevented? How to verify the the information contained in there is valid (if not it won't be used)?
BTW, I'm all for the updating of iNES. I don't know what I could do to help, though.
tokumaru wrote:
There were some ROM's out there with garbage on the unused bytes of iNES, weren't there? These would probably break the game in emulators that support the newer format, right?
There could be ways to differentiate between standard iNES and the update by having a certain thing in the header. Perhaps having an short ID string in the last 3 or 4 bytes in the header. These will go ignored in most emulators which only support standard iNES, but emus which support both will be able to look at it to know what format to use.
Obviously 100% backwards compatibility isn't possible (if it were, a new format wouldn't be needed, right?) The idea is to make older emus support the updated format to a reasonable extent... but ultimately, an emu which does not actually support the update won't be able to run all the ROMs in that format.
i dont think we should update ines. there are still alot of roms with strange stuff in the header as it is now, adding more would really make a mess. ines is flawed from the begining.
since unif was supposed to replace ines, i think we should find out why and fix that. i think quietust said there were a few games that didnt work with it? then unif needs a new chunk so that it does ? but something that doesnt have confliting data either.
i am thinking about removing ines support from my emulator; change them all to unif.
matt
mattmatteh wrote:
i am thinking about removing ines support from my emulator;
But then most people won't use your emulator, since it won't play 99% of the ROM files out there. I don't know what your goal with your emulator is, though. Maybe you have a small target audience, that doesn't mind loosing iNES support, I don't know.
How about:
Signature (4 bytes) "NES",0x1B?
Game type in release order (4 bytes) - first/second bytes are strict logical mapper (which is more like board type, 512K MMC1 would be different mapper than normal 256K mapper), third/fourth is mirroring (V, H, mapper, none), CHR ROM/RAM, WRAM is V/NV, WRAM size, bus conflicts, extra misc ROM presence after CHR ROM such as expansion audio ROM or NT-ROM.
PRG data size (2 bytes in 8k blocks which is the smallest Nintendo maskrom)
CHR data size (2 bytes in 8k blocks, CHR RAM would be defined as 1 block)
Optional dumper (person, not hardware) signature (4 bytes) --not to be indexed to a username!
followed by SRAM, PRG, CHR, other data specified in game type.
Note: NO controller ID or ambiguous boardname. I thought the high byte of the mapper could be for unstandardized mapper numbers. By incorporating SRAM in the "ROM", it'll reduce file clutter and unofficially allow trainers to be incorporated into SRAM loading as well as make ROMs act more like their original cartridge) Emulators should then have an import/export SRAM option.
I'm pro to upload iNES. There is 8 free bytes and several more bits in theory, if those bastards didn't input "DiskDude" in it on several roms.
I think emus should either detect the "DiskDude" and interpret it as a old iNES rom, or simply do the smart trick that kyu said above, replace the mark with $1b so thing would be clear about wich version of iNES is done.
Here you are my opinion :
What could be added in iNES2 :
- SRAM size specification (including no SRAM), so all games that rely on open bus at $6000-$7fff will work fine, all games reliying on standard 8kb at the same place will work fine too, and MMC5 games doesn't have SRAM bankswitching problems any longer
- Fix all mirroring and SRAM wrong flags on some ROMs
- Add a byte that tells the "version/revision" of the ROM for commercial ROMs (or even homebrew), so that difference between FC, USA NES and PAL NES can be done, along with the different version (PRG0, PRG1, a1, a2, etc....) of each game
- Some system that auto-detect and fixes the horribly popular [hM02] versions of several japanese and fan-translated games (Final Fantasy II, DQ3 and others). The emulator could detect the chains of "bit $xxxx" (where xxxx is greather than $8000) and replace it with "sta $8xxx", and change the mapper to MMC1 and that would be done.
- I'm unsure if ANY mappers bit have to be added, as long as SRAM size is. SUROM can be any MMC1 pack with more than 256 kb of ROM for example. SOROM can be detected with SRAM size.
What shouldn't be added in iNES2 :
- Bus conflicts. No game rely on them, this is just a homebrew things. Emulators definitely can or cannot do something with them, but emulating no bus conflicts will always work. Some authors could just have the pleasure to have the [hM02] hacks not work, but actually just read above.
- Dumper hardware or person, nor footers. I think the goal of a ROM is to contain what the cartridge contains, with a few more information bytes. No person or hardware should be involved, and footers would be a bad idea as there is largly enough free space in 8 empty bytes.
Mabybe company name would be okay, but that wouldn't be of much use.
- Box or manual images. Because this is the main con by downloading a game instead of buying it (and that should remain the con I think, else what interest in buying a rare game ?) and you can just found pictures on the NES on sites like
Moby Games.
kyuusaku wrote:
Signature (4 bytes) "NES",0x1B?
Changing the file signature will kill backward compatibility.
If we want the ROM to load in older emus, it
must look just like a regular iNES file.
I really think a secondary signature is the way to go here.
Quote:
By incorporating SRAM in the "ROM", it'll reduce file clutter and unofficially allow trainers to be incorporated into SRAM loading
I don't really like the idea of "SRAM ROM" or trainers. RAM on the cartridge is just that -- RAM. Putting RAM in a ROM image doesn't really make a lot of sense. And ROM for iNES trainers aren't even
on the cartridge and probably should be excluded all around.
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. Or is that hacky/annoying/incompatible?
Just throwing out ideas.
Bregalad wrote:
- Add a byte that tells the "version/revision" of the ROM for commercial ROMs (or even homebrew), so that difference between FC, USA NES and PAL NES can be done, along with the different version (PRG0, PRG1, a1, a2, etc....) of each game
I like this idea.
Thanks for all of your replies, please do keep them coming. 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? The only reason that I can think of is that you can compare them with the file size to see if there is any junk at the end of the file. I am not aware of how many boards there are so if there are more than 256 I would provide an additional byte. I don't think that the following is very wise to do, though;
00h AAROM
01h BBROM
02h CCROM
...
I am much in favour of providing text for board names instead. However, if some boards behave in a similar fashion, then they should have the same byte number. How many boards are there? And can anyone provide me with a list?
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.
Why would having the header at the end of the file be a pain in the *** for? It would make bankswitching and file access easier as you don't have to add 10h every time.
I think that having the SRAM in the ROM file is an excellent idea. Not only is it very realistic, EVERY emulator can access it. None of that save state incompatibility rubbish.
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. Plus if there is no one around to champion the idea then yes it is going to die on its arse. In terms of old emulators not being able to read the ROM? Good. Old emulators have been surpassed by the new active ones and frankly no one uses them anymore. Either comply, or die!
WedNESday wrote:
what is the point of providing two bytes that tell you how many banks there are?
So you know how much PRG/CHR there is. How can you load a ROM unless you know how big it is? Seeking to EOF and backtracking is a luxury that isn't always all that easily performed -- ideally, the ROM should be loadable with a single parse, rather than the emu having to seek around and jump through hoops.
Quote:
I am much in favour of providing text for board names instead.
I could go either way... though I prefer a nice simple single number. Text strings are typically more complicated... and having the board name isn't really any more descriptive than a properly designated mapper number.
Not to mention there aren't board names for some games -- or two boards with the same name might have different mappers (one of the real big problems with UNIF).
Quote:
Why would having the header at the end of the file be a pain in the *** for?
Seeking around the file is a pain. If you know everything up front loading is easier since you can load the whole file in one pass.
Quote:
It would make bankswitching and file access easier as you don't have to add 10h every time.
Or you could do things the "normal" way and just load PRG/CHR into buffers when you load the ROM, then close the file and never have to deal with it again once you load it. Don't have to add anything for the header -- both PRG and CHR start at offset 0 of their respective buffers.
Quote:
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.
Quote:
EVERY emulator can access it.
Every emulator can read an 8k .sav file. Cross-emu SRAM support was never an issue... in fact I'm sure every NES emulator in existence uses the same 8k dump (it's not even really a file format... just a dump).
Quote:
None of that save state incompatibility rubbish.
Save
state have nothing to do with the file format. Nothing you can put in file specs will change how an emu emulates.
Quote:
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.
It's actually superior in many ways. It's much more flexible, and much easier to expand. Chunk/block formats are actually pretty common and once you're used to them they're easy to work with.
I opted for a block-style savestate format for my emu -- works great.
Quote:
In terms of old emulators not being able to read the ROM? Good. Old emulators have been surpassed by the new active ones and frankly no one uses them anymore. Either comply, or die!
No one will want to use your format if they can't play the games in their favorite emulator. Joe Gamer doesn't care how accurate the file format is as long as it works when he runs it.
Killing old emulator support is pretty much a guarantee that this format will never get off the ground.
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.
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?
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.
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.
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.
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.
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
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.
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!
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.
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
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
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.
Quote:
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...
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
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.
Quote:
As for "your favourite (old) emulator not being compatible", tough! Why are you using such an old emulator?
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?
Quote:
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.
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:
Quote:
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.
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?
Disch wrote:
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. interger.
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:
Quote:
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.
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.
Quote:
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.
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?
mattmatteh wrote:
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.
[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.
Quote:
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.
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.
Disch wrote:
Changing the file signature will kill backward compatibility.
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
Disch wrote:
I don't really like the idea of "SRAM ROM" or trainers. RAM on the cartridge is just that -- RAM. Putting RAM in a ROM image doesn't really make a lot of sense. And ROM for iNES trainers aren't even on the cartridge and probably should be excluded all around.
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
kyuusaku wrote:
Disch wrote:
Changing the file signature will kill backward compatibility.
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
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.
Quote:
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?
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.
BootGod wrote:
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.
This thread is for people who want to take the iNES-style direction, as the original post outlined. I think it's productive to let people go the direction they want, and having people try both approaches is better than attempting to steer one against its will. What you end up with is incoherence, since the two approaches are fundamentally different. "Format wars" can suck, but not as much as forced monoculture.
Quote:
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.
I rather like this idea too. Sounds like something to discuss in a UNIF revival thread.
I do have another suggestion and that is, each of our emulators has a database (the same database). Two bytes are used to identify a ROM in the database (LSB first).
4E 45 53 12 05
Example;
ROM # 1298 (0512h)
Title: Super Mario Bros.
PRG: 2
CHR: 1
etc.
That way we can make all kinds of additions and removals etc. Personally, I am quite excited by this idea.
A numbered database. That's what Pocket Heaven uses to identify ROM releases that have a release group's intro animation appended to them. It also makes it difficult for an emulator to support new releases, such as newly dumped prototypes or homebrew.
tepples wrote:
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.
Who uses type? :) Are there any other escape characters that could be used to do essentially the same as EOF?
Quote:
Because the SRAM can be cleanly erased without affecting the ROM.
But why shouldn't they be packaged together? If the SRAM is chunked or in a predictable place, everyone capable of using a hex editor can clean or remove it. Having it packaged would also allow people to use SRAM between emulators without having to reconfigure the SRAM directories unless SRAM is defaulted to the ROM directory which makes clutter. It would also allow people to distribute extra code in SRAM (sorta like the GAR.) If people really wanted to store ROMs as read only archive files, they could have the emulator redirect SRAM to a file.
kyuusaku wrote:
tepples wrote:
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.
Who uses type?
I don't know, but a lot of C standard libraries under DOS and Windows stop before the first ^Z when reading files where fopen() specified text mode. Given that some FTP programs behave the same way, it's also useful to make sure the file was transferred in binary mode.
Quote:
Are there any other escape characters that could be used to do essentially the same as EOF?
In CP/M, ^Z is end of file. MS-DOS is Microsoft's fork of QDOS, a clone of CP/M. I know of no other character that MS-DOS file readers use as end-of-file.
Quote:
Quote:
Because the SRAM can be cleanly erased without affecting the ROM.
But why shouldn't they be packaged together? If the SRAM is chunked or in a predictable place, everyone capable of using a hex editor can clean or remove it.
But buggy implementations may overwrite the ROM. In general, applications are not as well tested as an operating system's file system code. Putting the responsibility to keep the data streams separate on the file system will result in less chance of data loss.
Quote:
Having it packaged would also allow people to use SRAM between emulators without having to reconfigure the SRAM directories unless SRAM is defaulted to the ROM directory which makes clutter.
Storing SRAM in the ROM file also clutters up the Last Modified dates. And would you also want to store the save states for a game in the ROM file itself? This would make it more difficult to trade save states, as a lot of online communities encourage trading of SRAM files, save states, and movies but
not the ROM files themselves due to copyright.
Quote:
It would also allow people to distribute extra code in SRAM (sorta like the GAR.) If people really wanted to store ROMs as read only archive files, they could have the emulator redirect SRAM to a file.
Which reintroduces having to reconfigure the SRAM directories.
I've decided to put the header at the start of the file after all. I think that using "NES" as an identifier is the best solution. Including data like ROM name and information like cover art and such is
such a waste of time. I am not trying to implement a ROM database here, just a header.
As for the SRAM being in the ROM? Well, IMO the ROMs should be a digital copy of the cartridge itself, and having the SRAM inside of the file is a good idea. Someone said that people running ROMs off of CDs couldn't save their SRAM data. Well, you still couldn't save your SRAM data anyway, even if it wasn't in the file. It would have to be directed to the hard drive which would defeat the whole point of having the ROM on a CD.
So something like;
Code:
4E 45 53 02 01 00 01 00
| | | | | | | |
| | | | | | | +- (to make it 8 bytes so debuggers look ok)
| | | | | | +- Mirroring etc.
| | | | | +- Mapper/Board
| | | | +- CHR Banks
| | | +- PRG Banks
| | +- S
| +- E
+- N
What more could we possibly want?
BTW What's the biggest ROM possible? Is it 512k PRG and 512k CHR and 1024k of each?
Now, several points have to be made up :
- UNIF is totally useless and nobody will ever use it aside of a few people that seems very involved to it, but this remain very few people
- iNES is incomplete and should be updated to have less problem with the support of some technically complex ROMs that causes problems with the current format
- iNES is a standard format and cannot be altered like that
- Most emulators support only iNES and more accurate emus now use crazy checksum techniques to bypass techincal problems by the few ROMs that causes problems with the current format.
- iNES have still several reserved bytes for the purpose of any uploads
What should be done in my opinion :
- Create a programm that have a large programm in and that can easily convert all old iNES ROMs to new iNES format without killing them, and have an easy to use interface (just like Nestopia's internal database)
- Create a system that can detect old and new iNES ROM format
- Create a system to definitely detect region and video standard
- Create a system to found out SRAM sizes.
- Don't alter the current stucture of an iNES ROM; aka it stills remain 16 byte header, PRG data and CHR Data. Battery-backed data is in a sparate 8kb .sav file, that all emulators can read
- Implement the new format in emulators and force the user to convert its roms using either a link to the programm in point 1, or have a built-in converter inside the emulator.
instead of using program banks, you could use an unsigned int 32, for teh total program size. i dont see how the mapper/board could be only 1 byte, then you are limited to 256 and will have the same problem as ines.
matt
Why ? The current banking count works just fine.
The current mapper numbering woks just fine as well, as far as I know. There is no problem with the 256 limit (btw this isn't one byte, but two separate nybbles). More bits could be added anytime anyway.
However, the only problem with iNES is all about SRAM (open bus or more than 8kb), and with territories.
Please stop this flow of crazy ideas, and just apply the actual fixes, and idea to make them popular ! Flowing crazy ideas will help noone !
Bregalad wrote:
The current mapper numbering woks just fine as well, as far as I know.
I was thinking that at first also. But then I started to think about those who are making new mappers (ie Quietust, and maybe Brian Provincio?). If people make new mappers that will work on the NES, there'll be need for more room to identify in the header of the file system. I'm not sure if there'll be alot of new mappers made, but it's better safe than sorry.
Bregalad wrote:
Flowing crazy ideas will help noone !
No true. We are all brainstorming, and some excellent points have been raised.
I agree that crazy ideas won't help here. As I see it, we do not need a "revolution". We need to expand what we have to overcome some difficulties.
Creating a new, ideal format sounds just great, but it's just too difficult to do by now. It has been tried before, and always failed.
Updating iNES sounds much more feasible, and could possibly solve all compatibility issues. It's not like we'd be forcing anyone to update their ROM files, but if they want to get those weird games to work, they may have to update the headers and grab newer emulators.
Come on, guys, a revolution is not the way to go. There is no way everyone would agree on something new, and even if they did, implementing it (having everything comply to the new format) would be a bitch. Just improve iNES already, and people who are not concerned about this will not even notice something changed.
tokumaru wrote:
It's not like we'd be forcing anyone to update their ROM files, but if they want to get those weird games to work, they may have to update the headers and grab newer emulators.
Well, if they are going to update it then they should be prepared to convert it.
Let's say that iNES has been around for 10 years. Whatever we introduce now, could last from now to eternity, so it is
never too late. Staying compatbile with the iNES format is something I don't think is possible. The first six bytes are ok, but then you have this higher nibble lower nibble rubbish followed by eight bytes or so of total and utter crap, namely someones name which would confuse an emulator if we implemented the unused bytes but bad ROMs still had bad headers. What's wrong with my previous post which has a diagram of the new format. Not only is it very similar to iNES, it is also very easy to implement into ROMs. You don't need a convert utility, only a HEX editor, and you can do the whole thing by hand.
how often do you need to change a header on a game ?
mattmatteh wrote:
how often do you need to change a header on a game ?
Well if we were to implement a new format, then only once.
if its only once then a convert utility would probably work better anyway. and use a script or util to change many roms in a folder.
matt
WedNESday wrote:
but then you have this higher nibble lower nibble rubbish
This just makes the value a bit more difficult to read. If a person is too lazy to to form a byte out of 2 nibbles this does not justify a new file format.
Quote:
followed by eight bytes or so of total and utter crap, namely someones name which would confuse an emulator if we implemented the unused bytes
A second identifier can prevent this. If this ID is not present (wich would be the case if crap was written in those 8 bytes), the emulator should just consider this an old format iNES file, and ignore those 8 bytes, just as it is today.
Quote:
What's wrong with my previous post which has a diagram of the new format. Not only is it very similar to iNES, it is also very easy to implement into ROMs.
It makes no sense to come up with a format that is so similar to iNES. The point here is not that iNES is good. The only reason we're trying to expand iNES (as opposed to comming up with something new) is compatibility. If we were to come up with something new (and kill compatibility altogether), I'm sure it could be better than iNES or the format you proposed.
Quote:
You don't need a convert utility, only a HEX editor, and you can do the whole thing by hand.
Again, laziness from the part of the programmer does not justify a new format.
Bregalad, your summary is a good idea. Helps get people on the same page of the debate.
WedNESday wrote:
Well, IMO the ROMs should be a digital copy of the cartridge itself, and having the SRAM inside of the file is a good idea.
I do agree that a .nes file is not just a ROM, rather a virtual NES cartridge. This isn't a technical reason for having SRAM inside the file, more a common-sense reason.
WedNESday wrote:
Someone said that people running ROMs off of CDs couldn't save their SRAM data. Well, you still couldn't save your SRAM data anyway, even if it wasn't in the file. It would have to be directed to the hard drive which would defeat the whole point of having the ROM on a CD.
What if a person wants to keep all umpteen-thousand games on a CD-ROM and their save states on the hard drive? Or keep the game files on a directory for which they have read-only access, in order to prevent rogue programs from wiping out their game collection? Or they want to avoid having their backup program re-copy entire game files every time they play, rather than just the smaller save state file?
tepples wrote:
a lot of online communities encourage trading of SRAM files, save states, and movies but not the ROM files themselves due to copyright.
That ends the debate about save states in game files in my mind: due to this reason alone, it is just not viable.
WedNESday wrote:
Code:
4E 45 53 02 01 00 01 00
| | | | | | | |
| | | | | | | +- (to make it 8 bytes so debuggers look ok)
| | | | | | +- Mirroring etc.
| | | | | +- Mapper/Board
| | | | +- CHR Banks
| | | +- PRG Banks
| | +- S
| +- E
+- N
All I see is a mere rearrangement of bytes, with even less room for expandability. What the heck is the gain over iNES?
tokumaru wrote:
I agree that crazy ideas won't help here. As I see it, we do not need a "revolution".
Would a Wii in November do?
blargg wrote:
All I see is a mere rearrangement of bytes, with even less room for expandability. What the heck is the gain over iNES?
Exactly. It's like he just doesn't like to mess with nibbles. Even though this is a thing that the emulator author has to do only once...
Quote:
Would a Wii in November do?
I don't need a revolution, nor a Wii. Or a PS3. Or an XBOX 360. The PS2 I have at home is already too much. 3D sucks (words from a guy who is trying to make a "3D" raycaster for the NES! O.o).
Wii sucks.
Honestly, I enjoy the NES. ^_^;;..
About the "new" format, well...
The iNES seems deprecated because of arcaic times of emulation, do you remember? Yes, lots of "l33t" offering iNES ROM images and "signing them" right in the header. The most (un)famous is DiskDude junk that makes a lot of ROMs to fail when loaded in an emulator.
Now, you CANNOT suggest an "updated" iNES thing by cruching it. Plus, any format must need free space to be expanded somewhat. You should discuss what information is REALLY required to get the game EMULATED or RUNNING into a NES. This is the point, which UNIF seems to choose the 2nd option...
Quote:
The most (un)famous is DiskDude junk that makes a lot of ROMs to fail when loaded in an emulator.
If emulator finds 16th byte of iNES header is non-zero, clear 8th through 16th bytes to zero before parsing. Problem solved?
You mean 15th byte, right ?
Anyway, the current iNES specification DOES SAY all bytes 8-15 must be zeros. All ROMs having something in there aren't valid iNES ROMs, so they won't be valid on a updated iNES either.
However, a converting/fixing tool like good NES could fix all the ROMs with junk in their header. However, this shouldn't have anything to do with the FORMAT itself.
EDIT : About recent console, I don't need any PS3/XBC360/Wii either. 3D sucks, except if it is really well done. The only 3D graphics I ever loved are in Final Fantasy X. (Dragon Quest VIII is also have fair landscapes and characters, but it still hurt eyes a bit).
And I'm against 3D in the NES more than anything else. However, I'm very pro 2D (or 3D isometric) recent games, even if there is REALLY a few titles here.
blargg wrote:
If emulator finds 16th byte of iNES header is non-zero, clear 8th through 16th bytes to zero before parsing. Problem solved?
Bregalad wrote:
You mean 15th byte, right ?
Byte 15 is the 16th one, because 0 is the 1st. I think that blargg meant "clear 9th through 16th bytes" though, since the 8th byte is byte 7 and it is used by iNES.
blargg wrote:
WedNESday wrote:
Code:
4E 45 53 02 01 00 01 00
| | | | | | | |
| | | | | | | +- (to make it 8 bytes so debuggers look ok)
| | | | | | +- Mirroring etc.
| | | | | +- Mapper/Board
| | | | +- CHR Banks
| | | +- PRG Banks
| | +- S
| +- E
+- N
All I see is a mere rearrangement of bytes, with even less room for expandability. What the heck is the gain over iNES?
Firstly, then information is better provided and easier to read. I know that someone has said that programmer laziness is no need for a new header, I disagree. I do agree that no extra information is needed other than to run the ROM (i.e. checksums, ROM name etc). As for there being no room for expansion, iNES has never needed those eight extra bytes, and they were just abused. With the given format, what more could we possibly need?
Code:
4E 45 53 02 01 00 01 00
| | | | | | | |
| | | | | | | +- (to make it 8 bytes so debuggers look ok)
| | | | | | +- Mirroring etc. (see below)
| | | | | +- Mapper/Board
| | | | +- CHR Banks
| | | +- PRG Banks
| | +- S
| +- E
+- N
Byte 7 (06h) (maybe this order)
bit 0 - Horizontal/Vertical Mirroring
bit 1 - SRAM
bit 2 - 50/60hz
bit 3 - 4 Screen VRAM
bit 4 - Trainer
bit 5 - 1 Screen Mirroring (overrides bit 0)
bit 6 - 0 (reserved)
bit 7 - 0 (reserved)
As far as the mapper/board number goes, can we stop talking about why this format will be no good and actually start brainstorming. We will stick with the mapper numbers or move on to boards instead?
0..255 is not enough to some multigame carts with maximum capacity... Anyway, mostly maximum number is 256, so at least it needs to hold hi bit of each PRG and CHR banks number along with common flags or something... But easier way is to assign 2byte values to bank numbers...
Mirroring is better to represent with two bits:
00 - one-page mirroring
01 - Vertical mirroring
10 - Horizontal mirroring
11 - Four screen mirroring...
But actually there is hardware mapper mirroring so all this bits is unnecessary... So probably there is need one another bit, if it 1, then hardware used and first two ignored, else selected as above...
Code:
As far as the mapper/board number goes, can we stop talking about why this format will be no good and actually start brainstorming. We will stick with the mapper numbers or move on to boards instead?
One more thin you should do before brainstorming.
Rearraging mappers information... It needs collecting all mappers info such banking registers, irq handlers, mirrorings and memory ranges... Then you will probably find out that many mappers is duplicated or just have smal difference between each others, but many mappers contain two or three emulated hardware board in one... First should be merged, other ones should be splitted.
I'm trying to do something, but anyway I've made many dupes for mappers and boards.
I don't think more mirroring bits than iNES are needed. There is no problem with mirroring support now. The only mappers that use one-screen mirroring are mapper-controlled, there is NEVER hardwired one-screen mirroring, because the fact that you couldn't switch between both nametable banks for all 4 nametables mapped in PPU would loose all the interest of this mirroring mode.
The H/V mirroring bit is only here for harwired mirroring mappers, and ignored for all other mappers. The four-screen bit is here for several MMC3 games that use 4-screen mirroring. I don't think there is more than a couple of game, tough.
Again, the structure of iNES WON'T BE CHANGED for reasons that already have been mentionned : Noone (from "Joe Gamer" to myself) will care about any new format. Only a update of iNES would be of any pratical use. It is a simple of this.
I was waiting awhile before I brought this up, but I had an idea for a slightly modified .NES header format myself.
I have gone through over 4000 ROMs, doing various testing on my FPGA NES console now, and I believe I'm in a fairly good position to recommend some changes.
The goals of my changes are thus:
1) retain absolute backwards compatibility (for existing ROMs)
2) this format must be "future proof"
3) the changes I make must be carefully documented and must make sense.
4) The changes must make "sense" from both a hardware and software standpoint.
This thread has kind of made me post my ideas early before I've had a chance to fully revise and pull together exactly what I want to do, but you should be able to get a good idea for what I wanted to do.
So, without further ado...
As mentioned before, the format will be retained as it is. For a recap, here is the existing format:
byte 0-3: 'NES<eof>'
byte 4: # of PRG pages
byte 5: # of CHR pages
byte 6: flags byte 0
byte 7: flags byte 1
byte 8-15: not used
There are two free bits on flags byte 1.
I propose the following:
D3 set and D2 clear of flags byte 1 will indicate that this is an extended header. DiskDude! in the header will have D2 set and D3 clear, so this will prevent interference with those old dirty ROMs. (thanks to Q for this suggestion)
If D3/D2 are not set and clear respectively, this is not a "Version 2" header. This should be a pretty definitive way to prevent confusion. Again, if the emulator does not support the extended header, the game loads like normal and the emulator is none the wiser.
Now that we know this is an extended ROM, the following things were concidered as problem areas for .NES
1) Vs. Unisystem.
The Vs. Unisystem has no less than 11 different PPUs and various protection schemes on some of the Namco/Atari games (such as RBI baseball). Some way has to be found to accomodate this.
2) PRG ROM in excess of 2Mbytes, CHR ROM in excess of 1Mbyte.
This has already occured, and has been causing trouble for some
ROMs. So far, the hack has been to set PRG ROM to 00h to indicate 4Mbytes of ROM (since FFh is 16K short of 4Mbytes), and in the case of
exceeding the 2Mbyte-8K CHR barrier, ROMs have been allocating the CHR in the PRG space, and the emulator has to sort this out. Very messy.
3) "sub mappers".
Some of the allocated mappers are actually multiple mappers with 1
number. The only way to sort this mess is to use CRC checks in the emulator. This of course is messy, since when a new ROM comes along that isn't in the CRC table, things break.
4) mapper numbers.
Face it, we're running out of mapper numbers. 256 was alot at the start (heck, 16 even was alot to begin with!) but we're filling the space up.
5) WRAM.
Not all carts that support WRAM support 8K of it. Some support less, some support more, and some even have EEPROM!
So, after testing nearly every ROM in goodNES, those are the trouble areas I have found.
The proposed solution is thus:
Code:
byte8:
7 0
---------
SSSS xxxM
S: sub-mapper number
This specifies the sub-mapper for this ROM. If the ROM has no
sub-mappers, this field shall be 0000b.
M: mapper bits 8.
This specifies 1 more mapper number bit, which extend the total
number of possible mappers to 512. The other three bits are
earmarked for more mappers- up to 4096 total if needed- but I wish to stress that we should NOT just willy-nilly allocate mapper numbers greater than 0ffh until it is absolutely required. See below for more on this. The "x" bits shall thusly be clear at all times.
byte9:
7 0
---------
CCCC PPPP
C: 4 more CHR ROM size bits
P: 4 more PRG ROM size bits
These combine with the existing 8 bits of each to form 12 bits total for the number of PRG and CHR banks... this is enough for 64Mbytes-16K of PRG data and 32Mbytes-8K of CHR data.
byte10:
7 0
---------
CCCC PPPP
C: quantity of CHR RAM present which is not battery backed
P: quantity of WRAM present which is not battery backed
each nybble:
0 - no RAM of this type is present.
1 - 128 bytes of RAM
2 - 256 bytes of RAM
3 - 512 bytes of RAM
4 - 1K of RAM
5 - 2K of RAM
6 - 4K of RAM
7 - 8K of RAM
8 - 16K of RAM
9 - 32K of RAM
10 - 64K of RAM
11 - 128K of RAM
12 - 256K of RAM
13 - 512K of RAM
14 - 1M of RAM
15 - reserved, do not use
byte11:
7 0
---------
CCCC PPPP
C: amount of battery backed CHR RAM (yes, carts exist with this!!!)
P: amount of battery backed WRAM or EEPROM.
Certain Famicom cartridges use an EEPROM for storing their game data, instead of a static RAM.
Like above, these values follow the size table listed.
byte12:
7 0
---------
xxxx xxBP
P: this is a PAL ROM. when set, indicates PAL mode.
B: when set, indicates this ROM works on both PAL and NTSC machines (some of the Codemasters games actually will adjust the game depending on if it detects you running on a PAL or NTSC machine. It adjusts the timing of the game, and fixes the music).
Not many games would have this B flag set.
x: this bit is not used yet. They shall be maintained clear.
byte13:
7 0
---------
UUUU PPPP
This byte is reserved for the Vs. Unisystem only. If this is not a Vs. Unisystem ROM, then this byte shall be all 0's.
P: PPU type. This specifies the type of PPU used for this game. I have a list of this, but I have not processed it yet. There's around 11 different PPU's that exist.
U: various Unisystem flag bits. Again, I am working hard on this stuff so it's not fully complete.
I am working on buying 1 of every Unisystem game so I can study the hardware and come up with a coherent methodology. If anyone has any Unisystem games that I don't have, I could REALLY use them.
So far, for the Unisystem flags I can come up with, there's a special copy protection chip or chips that exist on games such as RBI Baseball. I totally RE'd RBI baseball's chip, but I know at least 2 other namco/atari games use similar but different chips... since running those games with my clone of the chip doesn't work.
Well, that in a nutshell is my proposal. It has been extensively thought out, future proofed, and carefully designed to fit in with existing emulators and ROMs. In fact, these additions would probably only affect around 5% of the existing ROMs, but they would banish CRC and mapper hacks forever.
I propose making a "fixup" program for existing ROMs which need it, and CAREFULLY documenting all the updates needed in 1 central location so that the existing mapper issues cannot occur again.
Also on the mappers issue, I have made an absolutely comprehensive mapper guide vs. mapper number which I will be posting to my page at some point. It lists every single implemented mapper number, where it can be found, and what it is composed of. Everything on it has been tested and revised, since it was produced when I made the FPGA NES.
And as such, the extra mapper bits should NOT be used until we run out of existing mapper numbers to prevent confusion and needless trouble.
Here's my Vs. byte proposal. I still need to figure out what to do about the dual Vs. games such as Baseball... I will probably allocate a bit or two on the flags byte for those... anyways, here is what I have.
Code:
Vs. Unisystem Byte Proposal
---------------------------
09/15/06
K.Horton
----
This is my proposal for the Vs. Unisystem byte on my proposed
.NES header expansion. It takes into account all known aspects
of the Vs. Unisystem.
There are three different methods of making the Vs. Unisystem games
hard to copy for arcade operators.
1) Different PPU's. This was done to prevent operators from
buying 1 conversion kit and then burning 9 copies of the EPROMs
for other machines.
2) Different control layouts. Again, this was done to prevent
operators from just burning up N copies of the EPROMs for their
machines. Not many games use a munged layout... I suspect the
number is around 5 to 7, with maybe 4 or 5 different pinouts.
3) Custom chips. Only Namco/Atari appears to have done this. There
only seems to be four different games which use one of these things.
RBI Baseball, TKO Boxing, Super Xevious, and possibly 1 other
Japan-only game. This chip is designed of course to prevent an
operator from burning another set of ROMs for a different game.
The proposed byte:
7 0
---------
MMMM PPPP
P: PPU type.
0 - RP2C03B
1 - RP2C03G
2 - PR2C04-0001
3 - RP2C04-0002
4 - RP2C04-0003
5 - RP2C04-0004
6 - RC2C03B
7 - RC2C03C
8 - RC2C05-01
9 - RC2C05-02
10 - RC2C05-03
11 - RC2C05-04
12 - RC2C05-05
13 - not defined
14 - not defined
15 - not defined
I have dumped the palettes from ALL of these PPUs, and have exact bit for
bit copies of them. The last 5 PPUs (RC2C05) have the standard NES
palette in them, however they return a specific word in the lower 5 bits
of 2002h, and registers 2000h and 2001h are flipped around. I'm fairly
certain that these are all the PPU's that exist. I have a good cross
section of games now.
M: Vs. mode.
0 - Normal- no special mode(s)
1 - RBI Baseball
2 - TKO Boxing
3 - Super Xevious
4 - ...
The rest of the mode settings are undefined at this time- I am hard at work
coming up with a complete set of Vs. stuff. It's just taking awhile since I
have to buy the stuff on ebay when it comes through. If anyone has any
Vs. stuff they can let me borrow, let me know what you have and we will
go from there. I have around 15 games so far, and I have most of the
esoteric stuff which used the add-on boards. I'm in most interested in
Atari/Tengen/Namco games such as TKO boxing.
(thanks Q for the corrections/additions)
Wow ! Your new format looks pretty decent.
However, I've some minor problems with it :
- What on earth are those PPU types ? I've never heard of that. Normally, a NES game should work with all PPU revisions, huh ?
- Why CHR-RAM could be battery backed ? I don't see much interest with that. What game could have any use of this ? To save space, a game would write all its save to the CHRRAM ? That make no sense to me, while technically possible.
- Why CHR-RAM/SRAM size could be less than 8kb (exept 0kb) ? I doubt any 128-byte RAM chips are used in any NES game. I think less bits would do for the RAM size.
- More info on what exactly "submappers" would look like would be welcome.
- Why don't put a bit that tells if the cartridge is american on japanese ? Both are NTSC and there isn't much difference in emulation issues, but I guess it would still be cool to have that.
Something like 3 bits :
000 -> Japan, NTSC
001 -> America, NTSC
010 -> Europe, PAL
011 -> (Australia ?), PAL
100 -> Pirate/Homebrew/Unlicenced, NTSC
110 -> Pirate/Homebrew/Unlicenced, PAL
111 -> Pirate/Homebrew/Unlicenced, support both video standards
Emulators could just look the middle bit to know if they must emulate PAL or NTSC, or have a more complex system to emulate all regions... ?
Other than this, it looks great.
EDIT : Totally outtopic, but I'm very curious to know wich games use EEPROM instead of RAM+Battery to hold saves. Wich mapper support that ? Are those licenced games or only pirate games ?
Excellent proposal. If everyone else agrees and once all the details are in place, I'd like to get started right away.
Bregalad wrote:
- What on earth are those PPU types ? I've never heard of that. Normally, a NES game should work with all PPU revisions, huh ?
Probably, but there might differences we don't know yet. Besides, knowing the PPU type is a must if we want to display the VS games in correct colors.
Bregalad wrote:
- Why CHR-RAM/SRAM size could be less than 8kb (exept 0kb) ? I doubt any 128-byte RAM chips are used in any NES game. I think less bits would do for the RAM size.
Then what about the Bandai mapper 16/157 EEPROMS? Mapper 16 may have a 24C01 (128x8 bits) or a 24C02 (256x8 bits). Mapper 157 (Datach Joint System) may have both a 24C01 and a 24C02 (384x8 bits). MMC6 has 1k RAM only and some unlicensed carts may also have less than 8k.
Bregalad wrote:
- More info on what exactly "submappers" would look like would be welcome.
A few examples on how it could be laid out:
mapper 4 sub-mappers: MMC3A, MMC3B, MMC3C, MMC6, MIMIC-1, NAMCOT 108/109/119
mapper 33 sub-mappers: TC0190, TC0350
mapper 69 sub-mappers: FME-7, SUNSOFT5A, SUNSOFT5B
Bregalad wrote:
- What on earth are those PPU types ? I've never heard of that. Normally, a NES game should work with all PPU revisions, huh ?
True, Nintendo lot check tried each licensed NES game in consoles with all PPU revisions (including one NES with a dying PPU that
The Three Stooges helped uncover). But as Marty said, it's a matter of Famicom/NES NTSC PPU, NES PAL PPU, PlayChoice PPU, and especially different Vs. Unisystem PPUs.
Quote:
- Why CHR-RAM could be battery backed ? I don't see much interest with that. What game could have any use of this ? To save space, a game would write all its save to the CHRRAM ? That make no sense to me, while technically possible.
Because a 16 KiB CHR RAM may be cheaper than an 8 KiB CHR RAM, an 8 KiB PRG RAM, and the extra decoder circuitry.
Quote:
- Why CHR-RAM/SRAM size could be less than 8kb (exept 0kb) ? I doubt any 128-byte RAM chips are used in any NES game.
How big is the PRG RAM in HKROM carts?
Quote:
- More info on what exactly "submappers" would look like would be welcome.
Mapper 4.x: T*ROM (MMC3) vs. H*ROM (MMC6).
Mapper 34.x: BNROM vs. NINA.
Quote:
Something like 3 bits :
000 -> Japan, NTSC
001 -> America, NTSC
010 -> Europe, PAL
011 -> (Australia ?), PAL
Would that be a lockout chip ID? The way the Sega Genesis does it is one bit for screen and one bit for ideographic:
- 60 Hz ideographic: Japan
- 60 Hz alphabetic: North America
- 50 Hz ideographic: mainland East Asia
- 50 Hz alphabetic: Europe, NZ, Australia
Quote:
100 -> Pirate/Homebrew/Unlicenced, NTSC
110 -> Pirate/Homebrew/Unlicenced, PAL
111 -> Pirate/Homebrew/Unlicenced, support both video standards
And this would fit into the lockout chip ID more than anything. Some people won't be satisfied until the CIC is emulated.
Quote:
Because a 16 KiB CHR RAM may be cheaper than an 8 KiB CHR RAM, an 8 KiB PRG RAM, and the extra decoder circuitry.
This forces the game to have no graphics when it saves and when it resumes the saved game, this removes random acess, and anyway you need extra circcuitry to bankswitch CHRRAM wich cannot exed 8kb without any extra logic, and this remove the other advantage of having SRAM (have more work RAM to bypass the very limiting 2kb of the NES, to decompress data, etc...).
Also I don't think any 16kb RAM chips exists, you'd either need to have a 32kb one, or to use only a 8kb one, biut that means your game has almost no room for graphics.
If one would do the choise to save money and have slow acess times, he better have to use an EEPROM, so it saves the battery, and still allow graphics to work normally.
I did not meant to "emulate" the lockout chip, but rather to provide info about the region and all, wich means about the same.
Effectivly, one bit for licenced/unlicenced, onother for video standard and the third for the sub-region of a video standard would seem pretty good.
Bregalad: mapper 16 Bandai games use several types of EEPROM chips (that I can't find any documentation of by the way).
I like your proposal kevtris, nice step forward from the chaos in this thread. A next step would be an official mapper list, including sub-mappers, backwards compatible with the current GoodNES. (not sure what should be done with semi-official ones unknown to GoodNES like mapper 155 (MMC1 without WRAM protection), or mapper 210 (N106 stripped down) )
Out of curiosity, how would "odd possibilities" such as a cart with an extra CPU containing custom code be handled? (Squeedo comes to mind, but I seem to remember talk about some japanese speech chip that would also fit in this category, even if the data would be samples rather than code)
I reckon you could get away with the hack of putting such "external ROM" data among the PRG or CHR pages, since such a cart would use a custom mapper number anyway and an emulator that supports it would know which pages are not PRG/CHR but "external ROM" data. Even if it's an ugly hack, it seems to be the best way to allow such games to be supported in iNES without using external files.
I'm still not convinced what would be the best solution, Kevin's proposed extension or a UNIF footer at the end of the iNES file. The last alternative has the advantage of being more easily upgradable, but the first one might just be more realistic due to its minimalistic approach.
Still, the list of possible RAM sizes leave a lot to be desired, since the probability of encountering a cart that uses two SRAM chips (say a 32kB + 8kB combination), and thus doesn't fit in the category, is about as high as encountering a cart that uses the 4kB or 1MB SRAM size. It seems to me these definitions try cover all possible/likely cases, but fail none the less. Maybe we CAN'T cover every possible case with a fully backwards compatible format, but then at least we shouldn't pretend it's doable.
Though I suppose any of the alternatives would be decent, if only we'll see less talk and more action on this matter. ;)
Bregalad wrote:
This forces the game to have no graphics when it saves and when it resumes the saved game
But is it an issue? Save/load during vblank, or fade to black (commonly seen when sleeping in an inn in an RPG).
Quote:
, this removes random acess, and anyway you need extra circcuitry to bankswitch CHRRAM wich cannot exed 8kb without any extra logic
Which may already be present in your mapper ASIC if it is also used for games with CHR ROM.
Quote:
Also I don't think any 16kb RAM chips exists, you'd either need to have a 32kb one, or to use only a 8kb one, biut that means your game has almost no room for graphics.
8 KiB for CHR + 8 KiB for each of 3 save files = 32 KiB.
Why shouldn't SRAM size be defined by the board/mapper? Since the bankswitching will be mapper specific, it makes sense to me for the size to be mapper-defined. If you can make an NROM with 16k of SRAM, what does that mean? 16k SRAM games can't be assumed to work the same like they are with 8k SRAM. Would a 16k SRAM NROM game be legal in this new format?
It doesn't make sense to me, I think the only stuff that should go in a header are things that can apply to any game.
I think a new format also needs provisions for expansion audio and a way to store audio samples if present.
Adding all these new bits just makes more things to enter.
While kev's proposal looks good, certainly the best ines upgrade I've heard yet, I'm still leaning towards the UNIF footer idea. It would be more easily incorporated into current apps and has the ability to store so much more.
Like kyuusaku said, audio data could be stored in a block. For VS. Unisystem, dip switch info could be stored in a block and maybe a palette block as well. It would be nice if an emulator did not have this info hard-coded.
Quote:
Would a 16k SRAM NROM game be legal in this new format?
It would make no sense, but technically it would be doable, just like now you can do a NROM card (mapper 0) with 256kB PRGROM for example, wich aslo make no sense. There isn't much issue with that, just don't use nonsense header combinations. Most emulators currently just give error messagebox if a nonsense header is found, so I don't think that would change.
Quote:
I think a new format also needs provisions for expansion audio and a way to store audio samples if present.
The provisions for expansion audio have nothing to do with the format, but with the mappers themselves. Also, if any samples are used, the game HAVE to store them in ROM, huh ?
For complex mappers (Squeedo, etc...), I just think the emus could use a plugin system. This would allow easy implementation of newer version of the same mapper, and is easy to use for both emu developpers and users.
Quote:
But is it an issue? Save/load during vblank, or fade to black (commonly seen when sleeping in an inn in an RPG).
Now you said that, I think this is kinda interesting. After a bit ot thinking it is a very good idea after all. You just save a chip, and for the only price of a bit slower acess times and forcing to fade to black when saving/loading games. The only main problem is the deletion of random acess, wich definitely is a pain. You just cannot load a file of 8kb : Where do you want it to load ? You don't have RAM for that, the NES has only 2kb. So you must load it in another part of CHRAM, and you can only read that in VBlank via a complex buffering system, same for writing. This is a pain, but it still saves a chip.
Bregalad wrote:
It would make no sense, but technically it would be doable, just like now you can do a NROM card (mapper 0) with 256kB PRGROM for example, wich aslo make no sense. There isn't much issue with that, just don't use nonsense header combinations. Most emulators currently just give error messagebox if a nonsense header is found, so I don't think that would change.
You can currently make a NROM with 8k SRAM which works in most emulators. My point is that there's no point in defining SRAM size in the header if it's all up to the board anyway. In other words I'd rather see a 8k version of Mapper A and a 16k version of Mapper A than SRAM size bits. MMC1 and MMC3 normally only have provisions for 8k or smaller SRAM, if somebody decides to create a game which uses 32k, a new mapper can be added since the logic will have to be anyway.
Bregalad wrote:
The provisions for expansion audio have nothing to do with the format, but with the mappers themselves. Also, if any samples are used, the game HAVE to store them in ROM, huh ?
No, I mean samples which are not necessarily accessible by the CPU at all, ones which are played back by other emulated hardware.
Effectivly, SRAM size depend of the board, but I disagree with you because a single mapper can have slightly different SRAM sizes, and also the same board can have SRAM that is battery backed to save the game or just additionnal Work Ram for the game.
For example :
Code:
Zelda -> MMC1 -> SNROM; 8kb SRAM+battery
Kid Icarus -> MMC1 -> SNROM; 8kb SRAM
Both are the exact same, exept one has battery, 2 diodes and one resitior in addition. With the new system, one game will have 8kb save-RAM and 0kb work RAM, and the other one 0kb save-RAM and 8kb work RAM, as I undrstand things.
For the other thing :
Code:
Caslevania III; Laser Invasion : MMC5; ELROM; no SRAM
Just Breed; Gemfire : MMC5; EKROM; 8kb SRAM+battery
Uncharted Waters; Napoléon L'emprereur -> MMC5; ETROM, 16kb SRAM+battery (only first 8kb batteried)
Romance of the 3 Kingdoms II : MMC5; EWROM, 32kb SRAM+battery
You don't want 4 different MMC5 mappers just because these only differs technically by their SRAM size ? That makes no sense to me.
Also, the new format allow 32kb Batteried and 8kb non-batteried or such combinations, wich are absolutely possible with a real MMC5 (but aren't used in commercial games, it would be possible to modify a ETROM board to gain such ability I think).
Bregalad wrote:
Effectivly, SRAM size depend of the board, but I disagree with you because a single mapper can have slightly different SRAM sizes, and also the same board can have SRAM that is battery backed to save the game or just additionnal Work Ram for the game.
A board can only have different SRAM sizes if it matches the pinout and is smaller. The only time this can happen on original boards is with MMC5 (using a 6264/62256/62512 in the same socket.) AFAIK, no NES device can accept a universal DIP and configure itself to access it. Why is having a handful of MMC5s so bad? No matter what, mapper code has to implement the different sizes of SRAM and it's no more work to type in mapper 1XX than it is to define a SRAM size. In the grand scheme of things, there are VERY few variations of SRAM between the same board.
Quote:
For example :
Code:
Zelda -> MMC1 -> SNROM; 8kb SRAM+battery
Kid Icarus -> MMC1 -> SNROM; 8kb SRAM
Both are the exact same, exept one has battery, 2 diodes and one resitior in addition. With the new system, one game will have 8kb save-RAM and 0kb work RAM, and the other one 0kb save-RAM and 8kb work RAM, as I undrstand things.
Earlier in this thread I suggested having a nonvolatile bit to describe the SRAM. Having two definitions of the exact same thing (SRAM/WRAM) doesn't make sense. If a board were to have 4 separate SRAM areas, some volatile, some nonvolatile, that would again have to be described in a new mapper which defeats the new header feature's purpose.
Quote:
You don't want 4 different MMC5 mappers just because these only differs technically by their SRAM size ? That makes no sense to me.
Yes because in the end it's far more economic than defining SRAM for the 4,000 ROMs with 8k battery backed RAM... It also allows for possibilities which this header is not capable of such as 4M of SRAM.
Well, I don't like doubling mappers. Maybe you could do something with sub-mappers, but I'm unsure how this works. I don't think SRAM size should be a part of sub-mappers, but should be defined as it in a byte reserved for it.
Also, even if no MMC1 card has ever had 32kb SRAM for example, it would be perfectly possible to build a card to handle that using the CHR selection line to select the SRAM banks. Bandits King of Ancient China does this with two 8kb SRAM chips, but one could have up to 32kb or even 64kb using the same trick. So if no submaper with that availability has been defined, the person who wants to devlop a MMC1 game that use a lot of SRAM will never be able to test his programm other than having a plugin for an existing emulator or to put all this together on a real cartridge. I found it would be better to keep the format open to anything new to just commercial boards.
Bregalad wrote:
Wow ! Your new format looks pretty decent.
However, I've some minor problems with it :
- What on earth are those PPU types ? I've never heard of that. Normally, a NES game should work with all PPU revisions, huh ?
The Vs. system games use a bunch of different PPUs to prevent arcade operators from burning a new set of EPROMs to update their games.
The differences are approximately like so:
RP2C03x, RC2C0x:
Standard RGB palette, very similar to that of the regular PPU found in NTSC consoles... however 1 or 2 colours were changed on a few of them.
RP2C04-000x
These PPUs have scrambled palettes and extra colours. A good example of this would be Vs. Ice climber or Vs. SMB, or Vs. Gradius... all three use various forms of the RP2C04 PPU, and if you play these games with the regular palette, it looks like an acid trip
Each of the four PPUs has a different scrambling of the palette, and a few differences in the colours. I have dumped all four bit for bit accurately using a special device I made.
RP2C05-0x
These five PPUs have the stock palette (as far as I know, except I have not seen 2 of the chips). The difference here is register 2000h and 2001h are flipped around. Also, reading 2002h returns the usual three bits in D5 to D7 (VBL, sprite overflow, sprite 0 hit) but the lower 5 bits are different depending on the -0x revision. Games check these bits, and crash or fail to start if they are wrong.
Quote:
- Why CHR-RAM could be battery backed ? I don't see much interest with that. What game could have any use of this ? To save space, a game would write all its save to the CHRRAM ? That make no sense to me, while technically possible.
That bicycling game cart, Racermate does. It has 64K of CHR RAM- 32K is battery backed, the other 32K is not. They store all the stats and such in this RAM. Why they battery backed CHR RAM, I don't know... but it DOES exist
Quote:
- Why CHR-RAM/SRAM size could be less than 8kb (exept 0kb) ? I doubt any 128-byte RAM chips are used in any NES game. I think less bits would do for the RAM size.
Because the EEPROMs used on some Japanese games are only 128, 256, or 512 bytes. Also, the MMC6 RAM is only 1K. This covers all possible bases, and costs nothing to implement. Having a range of 128 bytes to 1Mbyte is very decent IMO and shouldn't be a problem.
Quote:
- More info on what exactly "submappers" would look like would be welcome.
Yeah I was kinda holding off until I got some feedback.. but here is where it's really needed.
For example, there are multiple kinds of MMC1 cartridges- "regular", 16K of WRAM (8K battery backed, 8K not), Dragon Warrior 3/4 (512K of PRG ROM), and games which require WRAM to always be enabled ("The Money Game" and a few others, Japanese only).
So the submapper for MMC1 would be something like...
0 - normal MMC1.
1 - 16 WRAM present (a few Koei games do this)
2 - 512K of PRG ROM present (DW3, DW4)
3 - WRAM write protection disabled
It might be better to make the "WRAM protection disabled" a bit, so it could be turned on and off by itself, regardless of the other modes. The 16K of WRAM and 512K of PRG ROM though are mutually exclusive, since they use CHR ROM mapper bits.
Quote:
- Why don't put a bit that tells if the cartridge is american on japanese ? Both are NTSC and there isn't much difference in emulation issues, but I guess it would still be cool to have that.
Something like 3 bits :
000 -> Japan, NTSC
001 -> America, NTSC
010 -> Europe, PAL
011 -> (Australia ?), PAL
100 -> Pirate/Homebrew/Unlicenced, NTSC
110 -> Pirate/Homebrew/Unlicenced, PAL
111 -> Pirate/Homebrew/Unlicenced, support both video standards
Maybe, but that doesn't directly help emulation per se. I'm not opposed to such things though.
Quote:
Emulators could just look the middle bit to know if they must emulate PAL or NTSC, or have a more complex system to emulate all regions... ?
Yah... I'm not 100% sure about regioning... The only thing really enforcing regions is the lockout chip, and NTSC/PAL.
Quote:
Other than this, it looks great.
EDIT : Totally outtopic, but I'm very curious to know wich games use EEPROM instead of RAM+Battery to hold saves. Wich mapper support that ? Are those licenced games or only pirate games ?
That is mapper 16. Yes, licensed games by Bandai... I'm not 100% sure on titles at the moment, but there's around 10-12 that use it. There are two kinds of EEPROM they support- I^2C and a different, similar format. Look up the datasheet for the 24C02 to get an idea of what they are doing.
I emulate both styles of EEPROM in my console and it works great.
Unfortunately, mapper 16 is really something like 5 or 6 different mappers :-/
kevtris wrote:
Also on the mappers issue, I have made an absolutely comprehensive mapper guide vs. mapper number which I will be posting to my page at some point. It lists every single implemented mapper number, where it can be found, and what it is composed of. Everything on it has been tested and revised, since it was produced when I made the FPGA NES.
Annnnnnnny chance of you releasing that any time soon? I don't mind if it is not finished, and I think that it will help us all discuss a new format.
Quote:
Also, even if no MMC1 card has ever had 32kb SRAM for example, it would be perfectly possible to build a card to handle that using the CHR selection line to select the SRAM banks. Bandits King of Ancient China does this with two 8kb SRAM chips, but one could have up to 32kb or even 64kb using the same trick. So if no submaper with that availability has been defined, the person who wants to devlop a MMC1 game that use a lot of SRAM will never be able to test his programm other than having a plugin for an existing emulator or to put all this together on a real cartridge.
How would an emulator know how you wired up your 64KB RAM?
Quote:
How would an emulator know how you wired up your 64KB RAM?
Effectivly, you're right, there is plenty different ways of wiring it. I think the 3 lowest bits of CHR selection would logically be used, but since BanditKings of Ancient China uses the upper bit to select between both 8kb chips, this makes much less sense. I'm unsure of this, but the lowest bit is forced to be used on the 4kb CHRRAM bankswitching (that nobody uses exept the crazy Lagrange Point), so we'd either cut that track, or use the 3 upper bits of CHR Bankswitching. That's quite confusing.
Kevtris : About the VS games, I'm unsure of what exactly they are, but doesn't they belong to the arcade category ? Anyway, you seem to have more knowledge about that, so I'm confident you can found a good support them.
Thanks for telling me what games has weird saving system.
About the sub-mappers, I really don't think they're needed, at least not for MMC1.
Since the new format support SRAM sizes, a game with 8kb batteried and 8kb unbatteried would mean a SOROM board (Bandit kings of Ancient China), and a game with 512kb of PRGROM would mean a SUROM board (Dragon Warrior III-IV; Dragon Quest IV). I don't see much problems with that. There is also Final Fantasy I&II (both on one cartridge, not the separate games) wich uses 16kb SRAM (all batteried) and also 512kb of PRGROM.
Bregalad wrote:
About the sub-mappers, I really don't think they're needed, at least not for MMC1.
It's a good point, but it seems a little hacky to do memory size checks to determine the board type. I'm not an emu author though.
Personally, I'd like to see a header say what revision the mapper is. If it's gonna describe the mapper, might as well be detailed. It's possible for a program written for one revision to not work on another (I've experienced that problem myself). Maybe that's what causes problems with "The Money Game". If we don't know all the differences now, the bit will always be there for when we do.
I second this idea of storing mapper revision information. The problem is, how do we determine the revision? When I was testing other boards a while back, I found two MMC3B chips manufactured just weeks apart that behaved differently. I didn't check the boards thoroughly for an external explanation, but it is still a possibility.
Bregalad wrote:
Kevtris : About the VS games, I'm unsure of what exactly they are, but doesn't they belong to the arcade category ? Anyway, you seem to have more knowledge about that, so I'm confident you can found a good support them.
Yeah they are arcade versions of NES games. Some are very interesting, like Vs. SMB. This is a MUCH MUCH harder version of SMB, and if you like SMB and haven't played the Vs. version, you really should. They removed almost all the powerups and 1-ups, except at the very start.
Quote:
Thanks for telling me what games has weird saving system.
About the sub-mappers, I really don't think they're needed, at least not for MMC1.
Since the new format support SRAM sizes, a game with 8kb batteried and 8kb unbatteried would mean a SOROM board (Bandit kings of Ancient China), and a game with 512kb of PRGROM would mean a SUROM board (Dragon Warrior III-IV; Dragon Quest IV). I don't see much problems with that. There is also Final Fantasy I&II (both on one cartridge, not the separate games) wich uses 16kb SRAM (all batteried) and also 512kb of PRGROM.
Yeah I was thinking that too, but it's still kinda hacky. It's always good to have confirmation that yes, this really is an SOROM board. This breaks down for the Final Fantasy 1 and 2 multicart that Nintendo relased in Japan. This is a legit cartridge, and has 16K of WRAM and 512K of PRG ROM... and the bits used I think are different still. I don't have one of the carts so I cannot confirm.
But again, it's good to have a definite submapper set up for it. The submapper would be more useful to determine the type of MMC1 board we're dealing with.
* * *
I do like the idea of a way of telling an MMC1 or MMC3 revision also, but I'm not 100% sure how useful this would be from an emulation standpoint, and I'm sure many games were released with multiple MMCx revisions. As far as I know, only 1 game "cares" about this... that Japanese board game that does a funky scrolling thing by hitting the IRQ every scanline or something. I'm not sure what the game's name is right now.
Here's my big lists of mappers and stuff. NOTE: do not take this as the absolute gospel just yet... This is how mappers are allocated on the FPGA NES. Some of the assigned numbers are for "fixing" things such as mapper 16 (i.e. EEPROMs, WRAM, etc). So... those mapper numbers are "unofficial" and will go away if this V2.00 plan goes through. I adhered to FCEU's "fixup numbers" for the most part... but I'd really like to see all that go away by using the submapper thing.
http://tripoint.org/kevtris/cartz.txt
Please do not distribute this yet- again, it's very preliminary and I hope alot of the numbers will go away and stuff.
Quote:
Yeah I was thinking that too, but it's still kinda hacky. It's always good to have confirmation that yes, this really is an SOROM board. This breaks down for the Final Fantasy 1 and 2 multicart that Nintendo relased in Japan. This is a legit cartridge, and has 16K of WRAM and 512K of PRG ROM... and the bits used I think are different still. I don't have one of the carts so I cannot confirm.
I'm not sure what you mean by "hacky". A game wouldn't need a SUROM board to have 256kb PRGROM and leave the special bit unused, this makes no sense. This would be SNROM then. So I don't see anything hacky, the SUROM board is just a way that makes 512kb PRGROM possible on the MMC1.
Bregalad wrote:
Quote:
Yeah I was thinking that too, but it's still kinda hacky. It's always good to have confirmation that yes, this really is an SOROM board. This breaks down for the Final Fantasy 1 and 2 multicart that Nintendo relased in Japan. This is a legit cartridge, and has 16K of WRAM and 512K of PRG ROM... and the bits used I think are different still. I don't have one of the carts so I cannot confirm.
I'm not sure what you mean by "hacky". A game wouldn't need a SUROM board to have 256kb PRGROM and leave the special bit unused, this makes no sense. This would be SNROM then. So I don't see anything hacky, the SUROM board is just a way that makes 512kb PRGROM possible on the MMC1.
Yes, but what if they use a different bit for the extra PRG bank select like they did on the FF1/FF2 cart in Japan? You cannot tell that strictly by ROM size, since both have 512K (DW3 or DW4 vs. this FF1/FF2 cart)
kevtris wrote:
Yeah they are arcade versions of NES games. Some are very interesting, like Vs. SMB. This is a MUCH MUCH harder version of SMB, and if you like SMB and haven't played the Vs. version, you really should.
You mean like Lost Levels hard, or Battletoads hard?
tepples wrote:
kevtris wrote:
Yeah they are arcade versions of NES games. Some are very interesting, like Vs. SMB. This is a MUCH MUCH harder version of SMB, and if you like SMB and haven't played the Vs. version, you really should.
You mean like Lost Levels hard, or Battletoads hard?
Lost Levels hard would be an adequate description, as at least one level was taken
directly from SMB2j (5-3 or 6-3, I think).
kevtris wrote:
Yes, but what if they use a different bit for the extra PRG bank select like they did on the FF1/FF2 cart in Japan? You cannot tell that strictly by ROM size, since both have 512K (DW3 or DW4 vs. this FF1/FF2 cart)
I think he means it could also check the SRAM sizes (8kB battery versus 16kB battery in that case). Sounds like it'd work, but seems kinda indirect also. Like an implied sub-mapper.
Memblers wrote:
kevtris wrote:
Yes, but what if they use a different bit for the extra PRG bank select like they did on the FF1/FF2 cart in Japan? You cannot tell that strictly by ROM size, since both have 512K (DW3 or DW4 vs. this FF1/FF2 cart)
I think he means it could also check the SRAM sizes (8kB battery versus 16kB battery in that case). Sounds like it'd work, but seems kinda indirect also. Like an implied sub-mapper.
Yep... it's kinda wishy-washy though. The submapper says exactly what to expect, whereas the RAM thing may not fully explain it. Again, I think having both at once would be the best option.
Quote:
Yep... it's kinda wishy-washy though. The submapper says exactly what to expect, whereas the RAM thing may not fully explain it. Again, I think having both at once would be the best option.
Well, if you think so... But my opinion is that just sizes and mapper should tell everything about the cart content. Effectivly, the same bit doesn't have the same meaning, but on a given board with given PRGROM and SRAM sizes, each bit has always the same meaning, so I don't see anything hacky.
On the current iNES format, emus have to check the checksum or the rom's name to make the difference between DW4 and FF1&2.
Also, DW4 and FF1&2 uses the same bit for PRG bankswitching, it's just that FF1&2 uses another bit to select the SRAM chip than Bandit King of Ancient CHina. Emus that doesn't support FF1&2 proprely will think it's a SUROM cart with only 8kb SRAM, and they won't switch the SRAM. As a result, playing FF1 works fine as long as you don't touch FF2, but playing FF2 will totally overwrite FF1 saves, as far I know.
Since SRAM sizes are supported by the new format, I really see no need of submappers.
Bregalad wrote:
Quote:
Yep... it's kinda wishy-washy though. The submapper says exactly what to expect, whereas the RAM thing may not fully explain it. Again, I think having both at once would be the best option.
Well, if you think so... But my opinion is that just sizes and mapper should tell everything about the cart content. Effectivly, the same bit doesn't have the same meaning, but on a given board with given PRGROM and SRAM sizes, each bit has always the same meaning, so I don't see anything hacky.
On the current iNES format, emus have to check the checksum or the rom's name to make the difference between DW4 and FF1&2.
Also, DW4 and FF1&2 uses the same bit for PRG bankswitching, it's just that FF1&2 uses another bit to select the SRAM chip than Bandit King of Ancient CHina. Emus that doesn't support FF1&2 proprely will think it's a SUROM cart with only 8kb SRAM, and they won't switch the SRAM. As a result, playing FF1 works fine as long as you don't touch FF2, but playing FF2 will totally overwrite FF1 saves, as far I know.
Since SRAM sizes are supported by the new format, I really see no need of submappers.
Maybe for MMC1, but for other mappers they are absolutely required. A good example is the Bandai mapper 16 games with their various EEPROMs and such, and light pens and things... and mapper 83 which can have two different hookups for the CHR ROM, which results in 2 different CHR bank sizes. There's probably 10-20 mappers like this which have undetectable submappers (other than via CRC or similar).
Is it fair to say that you want a unique identifier for each hardware configuration (mapper chip plus wiring plus whatever else?). Other than memory size, which is represented already.
Mapper numbers were supposed to be this unique identifier, but it sounds like there are a handful of mapper numbers that were used for multiple different configurations.
Regardless of how we got in that situation, you don't want to re-map the conflicting ROMs to unique mapper numbers. (a) that breaks backward compatibility, and (b) there will always be old ROMs floating around out there.
So the idea is to add a sub-mapper number and use it to disambiguate those cases, which sounds pretty sensible to me.