This could be easily proven by disassembling the original version and looking for this code.
#GAME BOY ROM LINKS AWAKENING CODE#
Link’s Awakening DX is a color remake of an older Game Boy game, so it might very well be that they lost the original source, disassembled the old code and used it again for the remake. The label names suggest that this code has been disassembled from existing Z80 machine code. But there is also some assembly code that looks like this: This is the list of files in their project directory at D:GAMEBOY:Īnd here comes the interesting part: There is actually some assembly source in the ROM here is a small snippet: If you have any idea why they look for this, please post it in the comments. In the final ROM image, this sequence appears once, at 0x442B. These bytes, interpreted as Z80 machine code, mean “CALL 0x29C6”. This writes the file offsets at which 0xcd,0xc6,0x29 was found in the ROM image into ttmp.asm. It is unclear which editor they used for what, but they might have used Turbo C to write DOS code to support building, as there is a complete copy of this C program in the ROM: The ROM image includes big chunks of Borland’s Turbo C IDE (Turbo Vision interface) for DOS, as well as traces of the “QBasic” MS-DOS Editor. Let’s call this “game development archeology”… If you look at the image starting at 0x106000, you will find all kinds of interesting data, which will tell you a lot about the game’s development. This is what happened with the 1998 Game Boy/Game Boy Color game “The Legend of Zelda – Link’s Awakening DX” (MD5: ee0424cf1523f67c5007566aed70696d). (seppel tells me that this can also be caused by seek()ing over EOF in MS-DOS, in which case the previous data on the hard disk will be in the image.) If you allocate 2 MB of RAM (the linker must have used a DOS extender or XMS), you’d get memory with random data in it: leftovers from whatever was in this memory before. While modern operating systems will always clear all malloc()ed memory, so that you cannot get to other processes’ data, this was uncommon in the single-user MS-DOS days. Your linker, probably written in C, calls malloc() of the runtime library of the C compiler. Just tell the linker to allocate 2 MB or RAM, put the actual data at the beginning, and then write a 2 MB “.gb” image to disk, which will then be sent to the ROM chip factory. No big deal, just pad the game to two megabytes, and use a 2 MB ROM in the cartridge.
Pocket Monsters - Pikachu (Japan) (Rev D).Pocket Monsters - Pikachu (Japan) (Rev C).Pocket Monsters - Pikachu (Japan) (Rev B).Pocket Monsters - Pikachu (Japan) (Rev 0A).Wario Land - Super Mario Land 3 (World).Notice that entry 0x1C, flags 0x03, hash 0x00 is actually a dummy entry, used for all games that are not found in the hash table or don't have a Nintendo Licensee code. The hash column contains all hashes (and disambiguation characters in parentheses) that result in the respective entry being chosen, the games for which are listed as well.
#GAME BOY ROM LINKS AWAKENING MANUAL#
There are a total of 45 unique palette configurations in here, six of which are shared with the Manual Select Palette Configurations. (Source: boot ROM disassembly) Assigned Palette Configurations
The entries are listed here in the order they are stored in the ROM. The button combinations trigger the respective configuration and are previewed in the respective shades while the Nintendo Game Boy Color logo is still being displayed on the screen. Six of these are unique to the manual selection mode and are underlined in the table. To complement the unused palettes documented on the main page, the many used palettes are documented here.Ī total of twelve palette configurations are in here. This page contains notes for the game Game Boy Color Bootstrap ROM.
0 kommentar(er)
