Some ROM images for SNES have an SMC header, which consists of 512 extra bytes prepended to the start of the image. An image is a headered ROM if it has the SMC header; otherwise, it's a headerless ROM. The SMC header is not a part of any ROM bank and never appears in the SNES address space. A headerless ROM works exactly as well as a headered ROM. The only purpose of the SMC header was to configure a copier device. The typical emulator or hacking tool will ignore the information in an SMC header.

The SMC header is not the same as the (very much more important) SNES header.

Also, the *.smc file suffix does not imply a headered ROM, because some images have the wrong suffix. A good idea is to rename such images to *.sfc, which does not imply a header.

Contents 1 Annoyance 2 Detect a header 3 Add or remove a header 4 Header formats 4.1 Super Magicom *.smc 4.2 Super Wild Card (*.swc) 4.3 Pro Fighter (*.fig) 4.4 UFO Super Drive (*.UFO, *.1GM, *.2GM, etc) 5 References

Annoyance Edit

The SMC header is an annoyance to ROM hackers. Because the SMC header occupies 512 bytes, hackers must add 512 to every offset when they access the actual ROM data. If you forget to add 512 for a headered ROM, or you add 512 for a headerless ROM, then you hack in the wrong place. Some hacking tools require a headerless ROM, because these tools never add 512. Many hacking tools for Super Mario World tend to always add 512 and therefore require a headered ROM, but not all of them.

SMC headers also cause problems with IPS patches. If an IPS patch contains offsets for a headered ROM, then the patch will not apply correctly to a headerless ROM, and vice versa.

The best solution is to always use headerless ROMs. This removes the need to add 512, prevents having incorrect information in a header, and allows a user who has a copier device to prepend the correct header for that device.

Detect a header Edit

You may need to detect if your SNES ROM has the SMC header, so you know whether to add 512.

The easiest way is to use the size of the ROM image. Take the size in bytes, divide by 1024 and take the remainder.

• If the remainder is 0, then you have a headerless ROM.
• If the remainder is 512, then you have a headered ROM.
• If the remainder is not 0 nor 512, then you have a problem with the size of the ROM. Perhaps you have an incorrectly expanded ROM hack.

Here is a table for the common ROM sizes.

headerless ROM	headered ROM
262144 bytes	262656 bytes
524288 bytes	524800 bytes
1048576 bytes	1049088 bytes
2097152 bytes	2097664 bytes
4194304 bytes	4194816 bytes

Another way is to open the ROM image in a hex editor. SMC headers tend to contain mostly zero bytes. So if the first 512 bytes are mostly zero, then you probably have a headered ROM; but if the first 512 bytes are mostly nonzero, then you probably have a headerless ROM.

The most reliable way is to find the SNES header. If the SNES header is at offset 0x7fc0 or 0xffc0 in the ROM image, then you have a headerless ROM. If the SNES header is at offset 0x81c0 or 0x101c0, then you have a headered ROM.

Add or remove a header Edit

• To remove a header, delete the first 512 bytes from the ROM image.
• To add a header, insert 512 bytes at the start of the image. These can be 512 bytes of zeros, then the ROM will work with hacking tools or IPS patches that need a headered ROM.

Header formats Edit

The SMC header comes from a class of copier devices that can load a ROM image from floppy disk. (This needs to be checked. Perhaps copier devices never used floppy disks.)

The purpose of this class of device is to make a ROM dump of a SNES cartridge. The device has a slot for a SNES cartridge and can copy the cartridge ROM to internal RAM. The device can also plug into the SNES, for the user to play and test the ROM dump. The device has a floppy drive, so it can save the ROM dump to floppy disk. The device can also load a ROM image from floppy, so the user can try ROM hacks with a real SNES.

The 3.5 inch (8.9 cm) floppy disk held 1440 kilobytes, in the form of 2880 blocks of 512 bytes each. The disk wore a hard square shell, but the actual circular disk was floppy, not hard. There was a time when practically every computer had a 3.5 inch floppy drive, and floppy disks were common among computer users. These cheap disks provided the main way to move files between computers. The main problems with floppies were their small capacity, and their tendency to fail and lose all their data. The typical floppy disk contained a filesystem, which allows multiple files and directories, and permits the fragmentation of files across the disk.

The copier device had a floppy drive but did not use a filesystem. Instead it used the entire disk to store only one file, the ROM dump. The size of a typical ROM dump is less than 1440 kilobytes. So the copier device used the first 512-byte block of the disk to store the actual size of the ROM dump, and some other information about the SNES cartridge. This first block, the SMC header, remained in the ROM dump when the user copied the dump to a computer.

Super Magicom *.smc Edit

If you use the .SMC directive of wla-65816, then WLA DX will prepend the header in this format. This format matches the *.smc file suffix (though some images have the wrong suffix).

offset	size	contents
0	2 bytes	The size of the ROM dump, in units of 8 kilobytes, as a little-endian integer.
2	1 byte	Binary flags for the ROM layout and the save-RAM size.
3	509 bytes	All zero.

The flags at offset 2 are the binary-or of the ROM layout with the save-RAM size.

ROM layout:

• $00 is LoROM
• $30 is HiROM

Save-RAM size:

• $00 is 32 kilobytes
• $04 is 8 kilobytes
• $08 is 2 kilobytes
• $0c is 0 kilobytes

Some headers set the save-RAM size to 32 kilobytes instead of the actual save-RAM size. For example, Super Mario World uses 2 kilobytes, but the clean headered ROM of SMW has byte $00 (meaning LoROM with 32 kilobytes of save-RAM) at offset 2.

Super Wild Card (*.swc) Edit

This format matches the *.swc file suffix (though some images have the wrong suffix). You can probably use the 3 bytes at offset 8 to identify this format.

offset	size	contents
0	2 bytes	The size of the ROM dump, in units of 8 kilobytes, as a little-endian integer.
2	1 byte	Binary flags.
3	5 bytes	All zero.
8	3 bytes	The string $aa $bb $04, with $aa at offset 8, $bb at offset 9, $04 at offset 10.
11	501 bytes	All zero.

The flags at offset 2:

• $80 to jump to $8000 instead of the address in the reset vector.
• $40 if this is a split file but not the last image.
• $30 to use HiROM.
• $0c for the save-RAM size:
  • $00 is 32 kilobytes
  • $04 is 8 kilobytes
  • $08 is 2 kilobytes
  • $0c is 0 kilobytes

Pro Fighter (*.fig) Edit

This format matches the *.fig file suffix (though some images have the wrong suffix).

offset	size	contents
0	2 bytes	The size of the ROM dump, in units of 8 kilobytes, as a little-endian integer.
2	1 byte	$40 if this is a split file but not the last image, or $00 otherwise.
3	1 bytes	$80 for HiROM or $00 for LoROM.
4	2 bytes	DSP-1 settings.
6	506 bytes	All zero.

UFO Super Drive (*.UFO, *.1GM, *.2GM, etc) Edit

This format is used by the UFO Super Drive. The file extension will be *.UFO if it was converted from another rom format using UCON64. It will be *.#GM if it was made from a real UFO Super Drive (where # is 1 for either a single 4M game dump rom or a the first 4M segment rom of a larger game dump, and will be 2 3 4 etc for consecutive segments).

The header itself is nearly identical to that of the Pro Fighter.

offset	size	contents
0	2 bytes	The size of the ROM file, in units of 8 kilobytes, as a little-endian integer.
2	1 byte	$40 if this is a split file but not the last image, $10 is used instead of $40 some times and I'm not sure what the conditions are for that, and lastly $00 is used if it's the last segment of a multi segment game dump or if it's a single segment game dump.
8	8 bytes	The text string "SUPERUFO"
16	8 bytes	Various pieces of data between offset 16 and 23 (they differ from game to game, but not rom to rom in a split game, that's all I can tell), and I have no clue at all what they mean. Can someone help me out here with figuring this out?

References Edit

• README of WLA DX 9.5a, for the *.smc format.
• Sneskart.txt in snesmem.zip from Zophar's Domain, for the *.swc and *.fig formats.