## FANDOM

132 Pages

The internal header of a Satellaview ROM is the portion of the ROM's code used by coders to hold identifying information (such as the maker, title, and date), to impose play-through limits on gamers (such as start-up limits and deletion-imposed limits), to describe game specifics (such as size, speed, and pointer values), and to safeguard the integrity of the ROM (as by checksum counts). The fact that many emulators and ips patchers require the header to be removed in order to function properly demonstrates that header information is not necessary for the functionality of the Satellaview program, however the automatic removal of the header results in the loss of historical information that may never be recovered.

Information such as the date and the version number are of particular interest to Satellaview researchers and preservationists as these data indicate whether the ROM is a new ROM or a true redump as well as allowing for the proper naming of the restored game. Although some Satellaview games were re-broadcast on different dates with no alterations apart from the date in the header, other games were re-broadcast with subtly remixed content in order to provide a new experience even for players that had played through a previous run. The prototypical example of such an alteration is the positioning of the Mole character in BS Zelda no Densetsu: Inishie no Sekiban. By examining header information such as the date and version number, researchers are able to know for sure that all broadcasts of a game have been accounted for. This allows for the preservation (or at least the documentation) of even remix versions of Satellaview games.

## Technical informationEdit

The header of a Satellaview ROM resides at one of two addresses when examining an unaltered ROM with a hex editor[nb 1] depending on the ROM's "map mode." All known Satellaview ROMs can be described as being mapped in either "HiROM" or "LoROM,"[nb 2] and the header begins at the 32,688th binary digit (hex address 0x7FB0) for LoROM files and at the 65,456th binary digit (hex address 0xFFB0) for HiROM files.[nb 3]

 SFC Address Hexadecimal Length Name[1][2] $00:FFB0 0x7FB0 01$00:FFB2 0x7FB2 ?? Unknown, gets compared to 0001 $00:FFC0 0x7FC0 16 bytes Title$00:FFD0 0x7FD0 4 bytes Block Allocation $00:FFD4 0x7FD4 2 bytes Limited Starts$00:FFD6 0x7FD6 2 bytes Date $00:FFD8 0x7FD8 1 byte ROM Speed & Map mode$00:FFD9 0x7FD9 4 bits Type $00:FFDA 0x7FDA 1 byte Licensee / Maker$00:FFDB 0x7FDB 1 byte Version Number $00:FFDC 0x7FDC 4 bytes Checkbits$00:FFE0 0x7FE0 4 bytes Unknown $00:FFE4 0x7FE4 28 bytes Pointers (16-bit)  SFC Address Hexadecimal Length Name[1][2]$00:FFB0 0xFFB0 01 $00:FFB2 0xFFB2 ?? Unknown, gets compared to 0001$00:FFC0 0xFFC0 16 bytes Title $00:FFD0 0xFFD0 4 bytes Block Allocation$00:FFD4 0xFFD4 2 bytes Limited Starts $00:FFD6 0xFFD6 2 bytes Date$00:FFD8 0xFFD8 1 byte ROM Speed & Map mode $00:FFD9 0xFFD9 4 bits Type$00:FFDA 0xFFDA 1 byte Licensee / Maker $00:FFDB 0xFFDB 1 byte Version Number$00:FFDC 0xFFDC 4 bytes Checkbits $00:FFE0 0xFFE0 4 bytes Unknown$00:FFE4 0xFFE4 28 bytes Pointers (16-bit)

## DetailsEdit

### TitleEdit

Titles are rendered in SJIS using a combination of single-byte English characters, half-width katakana, and diacritics (all from JIS X 0201), and 2-byte kanji (from JIS X 0208 (JIS基本漢字)). Below we examine three examples:

 HexAddress Value Name 0xFFC0 42 "B" 0xFFC1 53 "S" 0xFFC2 20 " " (space) 0xFFC3 5A "Z" 0xFFC4 45 "E" 0xFFC5 4C "L" 0xFFC6 44 "D" 0xFFC7 41 "A" 0xFFC8 91 "第" 0xFFC9 E6 0xFFCA 82 "3" 0xFFCB 52 0xFFCC 98 "話" 0xFFCD 62 0xFFCE 20 " " (space) 0xFFCF 20 " " (space)
 HexAddress Value Name 0x7FC0 42 "B" 0x7FC1 53 "S" 0x7FC2 20 " " (space) 0x7FC3 BE "ｾ" 0x7FC4 DE "ﾞ" 0x7FC5 D9 "ﾙ" 0x7FC6 C0 "ﾀ" 0x7FC7 DE "ﾞ" 0x7FC8 00 unused 0x7FC9 00 unused 0x7FCA 00 unused 0x7FCB 00 unused 0x7FCC 00 unused 0x7FCD 00 unused 0x7FCE 00 unused 0x7FCF 00 unused
 HexAddress Value Name 0x7FC0 90 "神" 0x7FC1 5F 0x7FC2 81 "々" 0x7FC3 58 0x7FC4 82 "の" 0x7FC5 CC 0x7FC6 C4 "ﾄ" 0x7FC7 D7 "ﾗ" 0x7FC8 B2 "ｲ" 0x7FC9 CC "ﾌ" 0x7FCA AB "ｫ" 0x7FCB B0 "ｰ" 0x7FCC BD "ｽ" 0x7FCD 20 " " (space) 0x7FCE 20 " " (space) 0x7FCF 20 " " (space)

In the above 3 examples, it is clear that different naming conventions are used even for different games within the same series. Example 1 illustrates the importance of internal header names as a means by which to determine episode number as the title ends with "第3話" (Dai 3 Wa). This example also demonstrates variation that is introduced by the redundancy built into SJIS as the character "3" is encoded using the lengthier $8252_{hex}$ instead of $33_{hex}$.

Example 2 illustrates the use of JIS-X-0201-form combined characters as the half-width katakana, "ｾ", and the "ﾞ" diacritic together become "ｾﾞ" (and likewise "ﾀ" and "ﾞ" become "ﾀﾞ"). Taken together with example 1, this example also demonstrates variability of naming convention as example 1 terminated the title with a string of blank spaces whereas example 2 simply failed to use this part of the region reserved for title. In addition, example 1 used English characters to spell out "ZELDA" whereas example 2 used katakana to spell out "ｾﾞﾙﾀﾞ".

Example 3, then, illustrates yet a third naming possibility as the full internal title "神々のﾄﾗｲﾌｫｰｽ " (Kamigami no Triforce) is in fact nothing but the actual game's subtitle.

### Block AllocationEdit

The portion of the header describing which blocks are allocated for the software in question, i.e. where the data is actually stored on the data pack. The data packs can hold multiple ROMs and up to 32 Mbits can be allocated for them, although only 8 Mbit FLASH cartridges were manufactured. In general, retail re-releases and demos intended to be given a retail release were described as "FFFF". Satellaview-only games are described as "00-FF", and add-on maskrom data packs were described as "0000". Examples are given below:

 Value Data size Example $FF 8M Most download games, demos and SoundLink data. Largest filesize$0F 4M Uses the lower 4 blocks. Example - Tamori no Picross series $F0 4M Uses the upper 4 blocks. Example - Kirby no Omochabako series (?)$B8 4M Uses blocks 4, 5, 6 and 8. Example - Game Tora no Ooana Special magazine $07 3M Example - Satesupo DX Dai-4-Gou magazine$03 2M Example - Konae-chan no DokiDoki Pengin Kazoku $01 1M Example - Tsukuru-line Data Pack data$00 1M (?) Example - SameGame Koma Data data pack

### CheckbitsEdit

The portion of the header comprising the checkbit data can be found in the 4 bytes between hex addresses 0xxFDC and 0xxFDF. The first 2 bytes (0xxFDC and 0xxFDD) represent the ROM's Checksum and the second 2 bytes (0xxFDE and 0xxFDF) represent the Inverse Checksum. When added together, these two figures should total $FFFF_{hex}$ for a proper ROM. If the Checksum and Inverse Checksum are blank, then the ROM will not boot. This has been observed in some ROMs in the past and there has been speculation that this may represent an attempt by the original creators to disable the ROM for DRM reasons.

Additionally, when calculating the Checksum (0xxFDC and 0xxFDD) for each title saved on the data pack, the Block Allocation bits (located at 0xxFD0) should be used to determine which blocks the checksum will be calculated from.

### PointersEdit

The portion of the header comprising the pointers can be found in the 28 bytes at the end of the header between hex addresses 0xxFE4 and 0xxFFF. The main pointer that points to the Program Start is usually located at $0xxFFC_{hex}$, and pointers are usually 16-bit pointers.[1]

## NotesEdit

1. Hex editors are programs that allow users to access the raw binary data (1s and 0s) making up all computer programs. This kind of editor allocates hexadecimal addresses to strings of binary in order to enable simplified navigation of the program and to help see the structure of the low-level programming language such files are written in - assembly language (or ASM for short).
2. 2.0 2.1 The terms "HiROM" and "LoROM" are actually ways to describe how the program responds to the addresses found on the SFC's Address Bus A - the 24-bit bus associated with WRAM. If the ROM is mapped as "LoROM" then the ROM data only successively associates with the first half of each data bank on the SFC. This allows easy access to the WRAM which maps from the second half of each data bank, however it limits the size of each data bank to 32K. If the program designers had instead mapped the ROM as "HiROM" then each data bank has a maximum size of 64K, however this means that the location of code writing to the SRAM must be shifted. The decision to use "LoROM" or "HiROM" mapping is up to the program designers, and the internal heuristics of most modern emulators allow for a high degree of map mode detection.
3. Complicating matters somewhat, many Satellaview ROMs extracted from 8M memory packs and existing online also contain "ROM Copier headers" that were added to the ROM as part of the copying process. ROM Copier headers were not originally part of the broadcast ROM, however they have little or no effect on the ROM apart from introducing a 200-byte offset to all internal addresses. For a ROM-Copier-headered LoROM file, the original internal header can be located at hex address 0x81B0 for a LoROM file and at hex address 0x101B0 for a HiROM file.
4. 4.0 4.1 4.2 4.3 This example comes from the August 20, 1995 broadcast of BS Zelda no Densetsu (Dai 3 Wa)
5. This example comes from a broadcast of BS Zelda no Densetsu: Inishie no Sekiban (Dai 1 Wa) of unknown date.
6. 6.0 6.1 6.2 This example comes from the May 21 broadcast of Zelda no Densetsu: Kamigami no Triforce.
7. This example comes from the November 30 broadcast of Zelda no Densetsu: Kamigami no Triforce.
8. This example comes from a broadcast of BS Zelda no Densetsu MAP2 of unknown date.

## ReferencesEdit

1. 1.0 1.1 1.2 1.3 Callis, Matthew (maintainer). SNES Development: BS-X Satellaview Header. Superfamicom.org. 11 April 2010.
2. 2.0 2.1 2.2 Anon. Technical.txt. BS Zelda Homepage.
3. 3.0 3.1 3.2 KiddoCabbusses. Explaining BS-X “lockout” – why your Zelda pack won’t play anymore. (sorry dude.). Satellaview. 29 March 2010.
4. KiddoCabbusses. The Perils of 8M Pack Purchasing; Kaizou Choujin Shubibinman Zero.. Satellablog. 2 January 2011.
5. KiddoCabbusses. Just how difficult is getting new stuff? A sorta-personal story.. Satellablog. 1 June 2010.
6. KiddoCabbusses. Redumps. Because sometimes identical ROMs happen, except for the times they aren’t -that- identical.. Satellaview. 9 April 2010.

## Edit

Community content is available under CC-BY-SA unless otherwise noted.