Is there a similiar way to do this for SNES games ?
Provided there's an official algorithm to take a Super NES ROM and determine 1. where the header sits and 2. how big the expected SRAM is, I could add Super NES support to make_sram.
See SNES header for apparently good documentation of the various locations, and contents. There is a field for specifying size of battery RAM.
But it's still a lot more complicated than iNES or even NES 2.0; even finding the header is a heuristic process. Here's what I found on that page; is my understanding correct?
- File name suffix can be sfc (Super Famicom), smc (a copier), or swc (another copier).
- The internal header can start at $7FC0, $81C0, $FFC0, or $101C0 depending on whether LoROM or HiROM and whether or not it has a copier header. Presence of a copier header is not correlated with the file name suffix.
- internal_header[$15] is $20/$30 for LoROM or $21/$31 for HiROM.
- Whether or not there is a battery on the PRG RAM. For carts with no coprocessor, internal_header[$16] == $02 indicates a battery.
- Size of PRG RAM is 1024 << internal_header[$18] bytes; this byte must be in range $01 through $05.
- TV system is internal_header[$19] and should be less than $10.
- internal_header[$1e] = internal_header[$1c] EOR $FF, and internal_header[$1f] = internal_header[$1d] EOR $FF.
That looks generally correct (not that I'm a SNES "header" (midder?) expert). I do know that there are many more obscure file extensions (I'll let byuu elaborate). For the header, you could just look for it at offset (filesize%$8000)+$7FC0/$FFC0. I'm assuming the other header values you mentioned are just for the "is this really a SNES header?" check.
You also have to check those locations + 512, as some copiers stuck a 512 byte header on the front. Theoretically the file extension would tell you about that, but they're generally unreliable.
These are the SNES file extensions currently in use:
And yes, they are all still in use, and people will mention it if you don't support them. You can thank the ZSNES team for that. *.bin is my favorite.
*.smc is also used for Game Park images, standing for SmartMedia Card.
Headers can also be stored at $40ffc0 or $4010c0.
You can usually detect a copier header via bool hasCopierHeader = (fileSize & 0x7fff) == 512; but this will fail on a lot of PD ROMs, such as koitsu's.
RAM size calculation is different for SuperFX games, it is:
ramSize = 1024 << header[-3] & 7;
if(ramSize == 1024) ramSize = 0;
-3 is correct, Nintendo revised the header standard to start at 7fb0, etc in later cartridges. So it would be eg $7fbd, $ffbd, etc.
Detecting a SuperFX game is as "easy" as:
hasSuperFX = (mapperid == 0x20 && (rom_type == 0x13 || rom_type == 0x14 || rom_type == 0x15 || rom_type == 0x1a));
I don't know what make_sram is or does, but if its name is not deceptive, different games will break based upon which value you fill SRAM with.
Ken Griffey Jr's menu doesn't work unless SRAM is initialized to 0xff, and Powerslide FX will crash unless SRAM is initialized to 0x00.
Geez, why aren't there more SNES emulators, again? :)
Code:
*.sfc *.bs *.st *.nss
*.smc *.swc *.fig *.ufo *.gd3 *.gd7 *.dx2 *.mgd *.mgh
*.048 *.058 *.068 *.078 *.bin *.usa *.eur *.jap *.aus *.bsx
*.smc *.swc *.fig *.ufo *.gd3 *.gd7 *.dx2 *.mgd *.mgh
*.048 *.058 *.068 *.078 *.bin *.usa *.eur *.jap *.aus *.bsx
And yes, they are all still in use, and people will mention it if you don't support them. You can thank the ZSNES team for that. *.bin is my favorite.
*.smc is also used for Game Park images, standing for SmartMedia Card.
Headers can also be stored at $40ffc0 or $4010c0.
You can usually detect a copier header via bool hasCopierHeader = (fileSize & 0x7fff) == 512; but this will fail on a lot of PD ROMs, such as koitsu's.
RAM size calculation is different for SuperFX games, it is:
ramSize = 1024 << header[-3] & 7;
if(ramSize == 1024) ramSize = 0;
-3 is correct, Nintendo revised the header standard to start at 7fb0, etc in later cartridges. So it would be eg $7fbd, $ffbd, etc.
Detecting a SuperFX game is as "easy" as:
hasSuperFX = (mapperid == 0x20 && (rom_type == 0x13 || rom_type == 0x14 || rom_type == 0x15 || rom_type == 0x1a));
I don't know what make_sram is or does, but if its name is not deceptive, different games will break based upon which value you fill SRAM with.
Ken Griffey Jr's menu doesn't work unless SRAM is initialized to 0xff, and Powerslide FX will crash unless SRAM is initialized to 0x00.
Geez, why aren't there more SNES emulators, again? :)
byuu wrote:
These are the SNES file extensions currently in use:
Code:
*.sfc *.bs *.st *.nss
*.smc *.swc *.fig *.ufo *.gd3 *.gd7 *.dx2 *.mgd *.mgh
*.048 *.058 *.068 *.078 *.bin *.usa *.eur *.jap *.aus *.bsx
*.smc *.swc *.fig *.ufo *.gd3 *.gd7 *.dx2 *.mgd *.mgh
*.048 *.058 *.068 *.078 *.bin *.usa *.eur *.jap *.aus *.bsx
But which ones does the SNES PowerPak recognize?
Quote:
*.bin is my favorite.
The GBA scene used to use .bin until people got annoyed when they double-clicked a GBA ROM and a Genesis emulator opened. They soon switched to .gba despite the extension conflicting with GrabIt scripts according to filext.com. If I had my choice, it'd be headerless .sfc, but I have to deal with what's on SNES PowerPak owners' CF cards.
Quote:
RAM size calculation is different for SuperFX games
I'll keep that in mind once PowerPak supports Super FX.
Quote:
-3 is correct, Nintendo revised the header standard to start at 7fb0, etc in later cartridges.
I saw that. If anything for a PowerPak-supported game depends on it, my tool will probably call the extra 16 bytes internal_preheader.
Quote:
I don't know what make_sram is or does, but if its name is not deceptive, different games will break based upon which value you fill SRAM with.
Scroll to the top, click "this", then scroll up a few posts. It's a Python program that scans a CF card and makes blank .sav files for NES games that have the battery bit turned on because the FAT16/FAT32 driver in the PowerPak BIOS doesn't write to the directory or FAT. I wanted to extend it with Super NES support. I'm inclined to dismiss Powerslide FX because it requires Super FX, which the SNES PowerPak doesn't handle. Do Ken Griffey Jr. Presents MLB and Ken Griffey Jr.'s Winning Run use the battery?
> But which ones does the SNES PowerPak recognize?
Ah, beats me. Hopefully less, but including .sfc.
> If I had my choice, it'd be headerless .sfc
<3
> I'll keep that in mind once PowerPak supports Super FX.
Yeah, just wanted to cover the whole spectrum. Feel free to use only the relevant extensions / calculations.
> I'm inclined to dismiss Powerslide FX because it requires Super FX, which the SNES PowerPak doesn't handle. Do Ken Griffey Jr. Presents MLB and Ken Griffey Jr.'s Winning Run use the battery?
I don't know, just initialize to 0xFF for now, since we aren't worried about Powerslide FX. As far as we know, that is 100% compatible with all commercially released SNES games.
Ah, beats me. Hopefully less, but including .sfc.
> If I had my choice, it'd be headerless .sfc
<3
> I'll keep that in mind once PowerPak supports Super FX.
Yeah, just wanted to cover the whole spectrum. Feel free to use only the relevant extensions / calculations.
> I'm inclined to dismiss Powerslide FX because it requires Super FX, which the SNES PowerPak doesn't handle. Do Ken Griffey Jr. Presents MLB and Ken Griffey Jr.'s Winning Run use the battery?
I don't know, just initialize to 0xFF for now, since we aren't worried about Powerslide FX. As far as we know, that is 100% compatible with all commercially released SNES games.
So far I've only tried ROMs with the extensions of *.smc, *.fig & *.sfc, only one the PowerPack didn't see at all was the *.fig files.
I'm not sure if NSRT's source code is freely available, but I know that it will tell you helpful header information for SNES ROMs. However, I don't know if the header is actually read or if it just identifies the ROM and pulls the information from a database. If NSRT reads the header and gets the information directly from the header, that could be a good start in writing a tool to create SRAMs for ROMs.
NSRT seems to pull from a database as some of my "stuff" came up as not recognized, not in database....
I found another tool called CartSNS that seems to read header information and display it to the console. However, the tool is 16bit and won't run on 64bit operating systems. I tested the program on my old Thinkpad which runs Win98 and it displays nice output. I doubt that it looks up games from a database because the program itself is 37KB. I looked to see if it was open source and could be compiled to 32bit, but it appears to be closed source. Maybe the original author would be willing to release the source since it was originally coded in 2002.
OldNESJunkie wrote:
NSRT seems to pull from a database as some of my "stuff" came up as not recognized, not in database....
In fact, NSRT does display the information about a ROM based on the information found in the internal game header. Just try for yourself: take any ROM, change, say, the ROM makeup byte and see what NSRT will come up with (in the upper part of the ROM information section).
AFAIK, the only thing NSRT uses a database for is to clearly identify a ROM as a commercial game, as shown (if this is the case) in the section below the internal header information. If the ROM is not found (i.e., its CRC32 doesn't match any commercial game's in the database), a message will be shown saying that the ROM is probably corrupt.
Unfortunately, NSRT hasn't been updated for a while, so there are some newly discovered games that haven't been added to its database yet and thus cannot be identified, such as Cool World PAL, for example. Still, NSRT is perfect to read and verify a ROM makeup and/or its internal header information.
(N.B. In some cases, information about a ROM actually can't be retrieved from the internal header alone. To identify e.g. Super FX2 games you need to check the filesize as well, which will be greater than 8 Mbits. Another example is the ST-018 chip, which uses the same byte value as some SPC7110 ROMs. So, in such cases, you need to check multiple things to be sure. NSRT does this for you.
)pcmantinker wrote:
I found another tool called CartSNS that seems to read header information and display it to the console. However, the tool is 16bit and won't run on 64bit operating systems.
Super NES games are 16-bit and they run on a 64-bit operating system through an emulator. Perhaps you could run CartSNS through a PC emulator: either DOSBox or VirtualBox.
Here's my old code for reading a SNES internal header, it needs updated to deal with headers better but it works most of the time. Other game format headers in one directory up.
http://github.com/MatthewCallis/Lesminn ... doReader.m
It should make sense to anyone familiar with C.
http://github.com/MatthewCallis/Lesminn ... doReader.m
It should make sense to anyone familiar with C.
orwannon wrote:
Another example is the ST-018 chip, which uses the same byte value as some SPC7110 ROMs.
Sorry to pull a tepples, but it's the ST-0010 and ST-0011 that are identical. And yeah, ROM size is how you tell.
Code:
if(mapperid == 0x30 && rom_type == 0xf6 && rom_size >= 10) {
has_st010 = true;
}
if(mapperid == 0x30 && rom_type == 0xf6 && rom_size < 10) {
has_st011 = true;
}
has_st010 = true;
}
if(mapperid == 0x30 && rom_type == 0xf6 && rom_size < 10) {
has_st011 = true;
}
Man, I don't even remember how I tell SuperFX1 from SuperFX2, or if I even do anything differently. I know I have an option for it, just been a while since I've messed with it ...
byuu wrote:
Sorry to pull a tepples, but it's the ST-0010 and ST-0011 that are identical.
Regardless, Nach's old addon chip doc (which I was basically quoting) is accurate when it states about Seta's RISC processor (=ST-018):
Nach's doc wrote:
This chip is in Hayazashi Nidan Morita Shougi 2. (...) The D6 is also found in some SPC7110 ROMs, so be sure to check both values.
I just went ahead and checked the byte value in said game (LoROM offset $7FD6): $F5. In Momotarou Densetsu Happy and Super Power League 4, the corresponding byte (found at $FFD6 as they're HiROM games) is $F5, too.
So ... yeah. You're both right.
Oh I see. Yeah, you always want to compare both FFD5 and FFD6. But sometimes even that's not enough.