Posted: Thu Sep 14, 2006 12:01 pm
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
matt
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.WedNESday wrote:but then you have this higher nibble lower nibble rubbish
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.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
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.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.
Again, laziness from the part of the programmer does not justify a new format.You don't need a convert utility, only a HEX editor, and you can do the whole thing by hand.
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: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.
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?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.
That ends the debate about save states in game files in my mind: due to this reason alone, it is just not viable.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.
All I see is a mere rearrangement of bytes, with even less room for expandability. What the heck is the gain over iNES?WedNESday wrote:Code: Select all
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
Would a Wii in November do?tokumaru wrote:I agree that crazy ideas won't help here. As I see it, we do not need a "revolution".
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...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?
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).Would a Wii in November do?
If emulator finds 16th byte of iNES header is non-zero, clear 8th through 16th bytes to zero before parsing. Problem solved?The most (un)famous is DiskDude junk that makes a lot of ROMs to fail when loaded in an emulator.
blargg wrote:If emulator finds 16th byte of iNES header is non-zero, clear 8th through 16th bytes to zero before parsing. Problem solved?
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.Bregalad wrote:You mean 15th byte, right ?
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?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?WedNESday wrote:Code: Select all
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
Code: Select all
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)
Code: Select all
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?
Code: Select all
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.
Code: Select all
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.
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:- What on earth are those PPU types ? I've never heard of that. Normally, a NES game should work with all PPU revisions, huh ?
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:- 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.
A few examples on how it could be laid out:Bregalad wrote:- More info on what exactly "submappers" would look like would be welcome.