Satellaview ROM header

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 information

The header of a Satellaview ROM resides at one of two addresses when examining an unaltered ROM with a hex editor depending on the ROM's "map mode." All known Satellaview ROMs can be described as being mapped in either "HiROM" or "LoROM," 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.

LoROM

SFC Address	Hexadecimal	Length	Name
$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)

HiROM

SFC Address	Hexadecimal	Length	Name
$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)

Details

Title

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:

Example 1
Title (0xxFC1-0xxFCF)

Hex Address	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)

Example 2
Title (0xxFC1-0xxFCF)

Hex Address	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

Example 3
Title (0xxFC1-0xxFCF)

Hex Address	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 Allocation

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:

Block Allocation (0xxFD0-0xxFD3)

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 starts

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. 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)."

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

Limited Starts Field (0xxFD4-0xxFD5)

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 and locked memory packs. According to d4s, even deleted games (see below) can be played using an Ultra 16 unit.

Non-boot limits

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)

Date

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:

Example 1
Date Field (0xxFD6-0xxFD7)

Hex address	Hex value	Binary value	Name
0x7FD6	50	01010000	May
0x7FD7	A8	10101000	21

Example 2
Date Field (0xxFD6-0xxFD7)

Hex address	Hex value	Binary value	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.

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:

Example 3
Date Field (0xxFD6-0xxFD7)

Hex address	Hex value	Binary value	Name
0xFFD6	80	10000000	August
0xFFD7	A3	10100011	20?

Example 4
Date Field (0xxFD6-0xxFD7)

Hex address	Hex value	Binary value	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). 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 mode

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. Two examples follow:

Example 1:
ROM Speed & Map mode
(0xxFD8)

Hex address	Hex value	Binary value	Name
0xFFD8	31	00110001	Speed: FastROM (120ns) Map mode: HiROM

Example 2:
ROM Speed & Map mode
(0xxFD8)

Hex address	Hex value	Binary value	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.

Type

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:

ROM Type (0xxFD9)

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

Licensee / Maker

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 Number

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

Checkbits

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.

Pointers

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.

External links

• Internal ROM Header - An SMWiki article about the Internal ROM Header present in Mario games.
• BS-X Satellaview Header - An article about Satellaview ROM headers hosted at superfamicom.org's wiki.