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.
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]
|$00:FFB2||0x7FB2||?? Unknown, gets compared to 0001|
|$00:FFD0||0x7FD0||4 bytes||Block Allocation|
|$00:FFD4||0x7FD4||2 bytes||Limited Starts|
|$00:FFD8||0x7FD8||1 byte||ROM Speed & Map mode|
|$00:FFDA||0x7FDA||1 byte||Licensee / Maker|
|$00:FFDB||0x7FDB||1 byte||Version Number|
|$00:FFE4||0x7FE4||28 bytes||Pointers (16-bit)|
|$00:FFB2||0xFFB2||?? Unknown, gets compared to 0001|
|$00:FFD0||0xFFD0||4 bytes||Block Allocation|
|$00:FFD4||0xFFD4||2 bytes||Limited Starts|
|$00:FFD8||0xFFD8||1 byte||ROM Speed & Map mode|
|$00:FFDA||0xFFDA||1 byte||Licensee / Maker|
|$00:FFDB||0xFFDB||1 byte||Version Number|
|$00:FFE4||0xFFE4||28 bytes||Pointers (16-bit)|
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:
|0xFFC2||20||" " (space)|
|0xFFCE||20||" " (space)|
|0xFFCF||20||" " (space)|
|0x7FC2||20||" " (space)|
|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 instead of .
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.
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:
|$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.
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. ), 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 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 . If the first upper bit in the "limited starts" field were filled with a (i.e. ), then the game would be regarded as a boot-limited game. Assuming that upper bits 2 through 6 weren't all filled with (i.e. ), the BIOS would convert the leading (of upper bits 2 through 6) to . Thus, would become after the first boot, then after the second boot, after the third, after the fourth, and finally 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:
|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)
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.
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 , 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)
The date portion of the header comprises 2 bytes and is split between month (the upper 4 bits of the first byte, ) and day (the upper 5 bits of the second byte, ). 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 . Two examples of header dates are shown below:
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:
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 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 , , and describe SlowROM (i.e. the ROM Speed is 200 nano-seconds). For values of 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: represents LoROM and represents HiROM.[nb 2] Two examples follow:
|0xFFD8||31||00110001|| Speed: FastROM (120ns)|
Map mode: HiROM
|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.
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 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|
|80||1000xxxx||Error; used to skip the "J033-BS-TDM1 St.GIGA" intro?|
|A0||1010xxxx||Used in "Sound Novel" data packs|
Licensee / MakerEdit
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 , the ROM will boot properly and be viewable. For ROMs with a Licensee/Maker value of , 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.
The Version Number is an extension the actual format of which is 1 + ord(val($ffdb))/10.
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 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.
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 , and pointers are usually 16-bit pointers.
- ↑ 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.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.
- ↑ 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.0 4.1 4.2 4.3 This example comes from the August 20, 1995 broadcast of BS Zelda no Densetsu (Dai 3 Wa)
- ↑ This example comes from a broadcast of BS Zelda no Densetsu: Inishie no Sekiban (Dai 1 Wa) of unknown date.
- ↑ 6.0 6.1 6.2 This example comes from the May 21 broadcast of Zelda no Densetsu: Kamigami no Triforce.
- ↑ This example comes from the November 30 broadcast of Zelda no Densetsu: Kamigami no Triforce.
- ↑ This example comes from a broadcast of BS Zelda no Densetsu MAP2 of unknown date.
- ↑ 1.0 1.1 1.2 1.3 Callis, Matthew (maintainer). SNES Development: BS-X Satellaview Header. Superfamicom.org. 11 April 2010.
- ↑ 2.0 2.1 2.2 Anon. Technical.txt. BS Zelda Homepage.
- ↑ 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.
- ↑ KiddoCabbusses. The Perils of 8M Pack Purchasing; Kaizou Choujin Shubibinman Zero.. Satellablog. 2 January 2011.
- ↑ KiddoCabbusses. Just how difficult is getting new stuff? A sorta-personal story.. Satellablog. 1 June 2010.
- ↑ KiddoCabbusses. Redumps. Because sometimes identical ROMs happen, except for the times they aren’t -that- identical.. Satellaview. 9 April 2010.