## FANDOM

131 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

One bit corresponds to one megabit block on the Data Pack, with the MSB being the last “page” (\$C80000-\$CFFFFF) and the LSB being the first (\$C00000-\$C7FFFF). No known Satellaview ROMs that are marked \$00 will detect on the Satellaview itself.

### Limited startsEdit

Many Satellaview downloads were designed to expire after a certain number of play-throughs. This primitive form of digital rights management (DRM) operates by employing a simple boot-up countdown that goes into effect for all programs with certain "Limited start" values. With a maximum of 5 play-throughs, each boot-limited game is altered by the BS-X BIOS in such a way as to decrease the "boots left"-count every time it is booted.

When a Satellaview download is booted from the BS-X BIOS, the BIOS makes a quick check of the "Limited starts" section (0xxFD4-0xxFD5) of the ROM header. If the value at this address represents "0 boots left" (i.e. $80_{hex}$), then the game is considered "locked" (or "expired"). Although the game can now no longer be booted in this state, however, the only difference between the "1 boot left" state and the "0 boot left" state is 1 bit. This is another way of saying that the game data has not been wiped clean, but that it has merely been marked as unplayable. During the period of Satellaview broadcasts between 1995 and 2000 this meant that the player would have had to re-download the game (if it was available) in order to play again with a full play-count. With modern emulation it means that the player will have to use an emulator that ignores boot limits or simply edit this portion of the ROM with a hex editor to restore functionality.[3] For Satellaview ROMs that are distributed as originally dumped data and that are therefore still "locked," researchers and recreationists have taken to marking the file name with the symbol "(L)."[4]

Boot limits didn't apply to SoundLink titles since they were never designed to boot and thus were "locked" from the outset, however boot limits were very common with most non-SoundLink titles. The two major exceptions to this general rule were Nintendo first party downloads (such as Special Tee Shot and the Kirby no Omocha Hako line) and Squaresoft's games.[3] These games had a value of $00_{hex}$ for the "Limited starts" field and were thus granted unlimited boots. These DRM-free gifts are valued today by collectors as the only way to play fully hardware Satellaview titles subsequent to the demise of the system and their lack of an expiry condition means that they have thankfully been preserved in large part for the enjoyment of subsequent generations of players.

To describe exactly how the boot-up countdown functioned, it is important to note that of the 8 bits present in the "Limited starts" field, only the upper 6 were used to convey limit information; the last 2 bits were always $0_{bin}$. If the first upper bit in the "limited starts" field were filled with a $1_{bin}$ (i.e. $1xxxxxxx_{bin}$), then the game would be regarded as a boot-limited game. Assuming that upper bits 2 through 6 weren't all filled with $0_{bin}$ (i.e. $100000xx_{bin}$), the BIOS would convert the leading $1_{bin}$ (of upper bits 2 through 6) to $0_{bin}$. Thus, $x11111xx_{bin}$ would become $x01111xx_{bin}$ after the first boot, then $x00111xx_{bin}$ after the second boot, $x00011xx_{bin}$ after the third, $x00001xx_{bin}$ after the fourth, and finally $x00000xx_{bin}$ after the fifth boot. Such a game would have expired at this point, would have failed the initial boot limit check, and would thus be locked.

The following table given the known limited boot header values:

 Hex value Binary Name FC 11111100 5 boots left BC 10111100 4 boots left 9C 10011100 3 boots left 8C 10001100 2 boots left 84 10000100 1 boot left 80 10000000 0 boots left(Game will not detect on BS-X) 00 00000000 Unlimited Boots

Note: It has been claimed that the Ultra 16, a hardware emulator shell similar to the Super UFO, can play locked ROMs[3] and locked memory packs. According to d4s, even deleted games (see below) can be played using an Ultra 16 unit.[5]

#### Non-boot limitsEdit

For a number of games, research appears to suggest that alternative means were used to preserve the digital rights to the media for the game creators. Rather than simply employing a boot-up countdown as described above, some other games appear to have semi-scrambled information contained within themselves. For Satellaview ROMs that had blank checkbit fields, the ROM would not boot properly. Similarly, for ROMs in which the Maker values were set at anything other than $33_{hex}$, the ROM would also fail to boot properly. Explanations for these seemingly corrupt ROMs include alternate methods of file deletion and corrupted dump data (missing data, corrupt image, or incorrect mapping)[2]

### DateEdit

The date portion of the header comprises 2 bytes and is split between month (the upper 4 bits of the first byte, $0xxFD6_{hex}$) and day (the upper 5 bits of the second byte, $0xxFD7_{hex}$). All other digits in the date portion (i.e. the lower 4 bits of the first byte and the lower 3 bits of the second byte) are filled with $0_{bin}$. Two examples of header dates are shown below:

 Hexaddress Hexvalue Binaryvalue Name 0x7FD6 50 01010000 May 0x7FD7 A8 10101000 21
 Hexaddress Hexvalue Binaryvalue Name 0x7FD6 B0 10110000 November 0x7FD7 F0 11110000 30

Dates like those given in the examples above are extremely helpful for Satellaview researchers and preservationists to give a sense of whether or not ROM material is new (previously undumped material) or redump material. Although some data broadcasts were identical save for their header dates, such information is still of great importance to researchers as unique dates represent possibilities of new material within a finite set of data broadcasts. Examples such as that of the positioning of the Mole character in BS Zelda no Densetsu: Inishie no Sekiban discussed above demonstrate that remixed versions of the same game did exist and are of great interest to collectors and Satellaview enthusiasts. For this reason, Satellaview researchers have taken to marking the ROM file name with the header date.[6]

Below are two further examples, however, that demonstrate that header date information is not always a perfect means by which to identify discrete ROM dumps:

 Hexaddress Hexvalue Binaryvalue Name 0xFFD6 80 10000000 August 0xFFD7 A3 10100011 20?
 Hexaddress Hexvalue Binaryvalue Name 0xFFD6 02 00000010 ? 0xFFD7 0A 00001010 1?

As the two examples above show, ROM header information may occasionally be corrupt. In example 3, a possible date of August 20 can be determined from the header, however the issue is clouded by the unexplained presence of trailing $1_{bin}$ characters (lower 2 bits of the second byte - 0xFFD7).[nb 4] In example 4, however, the date information appears to be scrambled beyond usability. Problems like this may be due to improper dumping of the original ROM, subsequent corruption of the header data by ROM hackers or due to data decay, or possibly even attempts by the original creators to scramble the information for DRM reasons.

### ROM Speed & Map modeEdit

The portion of the header describing the ROM Speed and map mode comprises only a single byte with the upper 4 bits representing the ROM speed and the lower 4 bits representing the map mode. For the ROM Speed, values of $0000_{bin}$, $0001_{bin}$, and $0010_{bin}$ describe SlowROM (i.e. the ROM Speed is 200 nano-seconds). For values of $0011_{bin}$ and greater, FastROM (i.e. a ROM Speed of 120 nano-seconds) is described. Map mode descriptions are even simpler, with only two allowed values: $0000_{bin}$ represents LoROM and $0001_{bin}$ represents HiROM.[nb 2] Two examples follow:

 Hexaddress Hexvalue Binaryvalue Name 0xFFD8 31 00110001 Speed: FastROM (120ns)Map mode: HiROM
 Hexaddress Hexvalue Binaryvalue Name 0x7FD8 20 00100000 Speed: SlowROM (200ns)Map mode: LoROM

Note that the two characteristics of ROM Speed and Map mode are not tied together as the above examples might indicate, and the two values do not have direct bearing on each other. Thus, a Hex value of 30 would indicate a FastROM speed for a LoROM map mode.

### TypeEdit

The portion of the header describing the ROM Type comprises only the upper 4 bits of a single byte - 0xxFD9. The lower 4 bits are all $0_{bin}$ characters. There are 4 normal types allowed in ROM headers and a 5th default error type for all other values. The following chart describes the 5 values:

 Hex value Binary value Name 00 0000xxxx Executed from the FLASH memory, SoundLink enabled 10 0001xxxx Executed from the FLASH memory, SoundLink disabled 20 0010xxxx Part-size, executed from the 4 Mbit PSRAM (copied from FLASH), SoundLink enabled 30 0011xxxx Part-size, executed from the 4 Mbit PSRAM (copied from FLASH), SoundLink disabled 40 0100xxxx Error 50 0101xxxx Error 60 0110xxxx Error 70 0111xxxx Error 80 1000xxxx Error; used to skip the "J033-BS-TDM1 St.GIGA" intro? 90 1001xxxx Error? A0 1010xxxx Used in "Sound Novel" data packs B0 1011xxxx Error? C0 1100xxxx Error D0 1101xxxx Error E0 1110xxxx Error F0 1111xxxx Error

The portion of the header describing the Licensee/Maker comprises a single byte - 0xxFDA. There are 2 normal types allowed in ROM headers and only one that allows the ROM to be booted. For ROMs with a Licensee/Maker value of $33_{hex}$, the ROM will boot properly and be viewable. For ROMs with a Licensee/Maker value of $FF_{hex}$, the ROM will not be bootable. There has been some speculation that this may have been an attempt by the original creators to disable the ROM for DRM reasons.

### Version NumberEdit

The Version Number is an extension the actual format of which is 1 + ord(val(\$ffdb))/10.[1]

### 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.