Technical articleArtículo técnico

The Mega Drive ROM HeaderLa cabecera ROM de Mega Drive

The fields commonly found in the ROM header and why they matter to tools and hardware.Los campos habituales de la cabecera ROM y por qué importan para herramientas y hardware.

PublishedPublicado

September 5, 20265 de septiembre de 2026

UpdatedActualizado

September 12, 202612 de septiembre de 2026

DifficultyDificultad

BeginnerInicial

Reading timeTiempo de lectura

6 min read6 min de lectura

Where the header livesDónde está la cabecera

In a conventional raw Mega Drive cartridge image, the console header occupies 256 bytes at offsets 0x100 through 0x1FF. It describes the software through fixed-position fields. It is not a directory of every graphic, sound or routine in the game.En una imagen de cartucho Mega Drive en formato binario lineal, la cabecera de la consola ocupa 256 bytes entre los offsets 0x100 y 0x1FF. Describe el software mediante campos de posición fija. No es un directorio de todos los gráficos, sonidos o rutinas del juego.

Before it, the first 256 bytes contain the 68000 vector table. At reset, the CPU reads the initial supervisor stack pointer at 0x000000 and the initial program counter at 0x000004. These are binary addresses, not part of the title or product information. The reset target tells you where execution starts; do not assume it is always 0x200.Antes de ella, los primeros 256 bytes contienen la tabla de vectores del 68000. Durante el reset, la CPU lee el puntero inicial de pila del supervisor en 0x000000 y el contador de programa inicial en 0x000004. Son direcciones binarias, no parte del título o de la información del producto. El destino del reset indica dónde comienza la ejecución; no des por hecho que siempre sea 0x200.

Check the dump format first. A copier header, interleaving or swapped byte order can move or scramble the apparent fields. The offsets in this article refer to the normalized ROM image, not a container file with extra bytes.Comprueba primero el formato del volcado. Una cabecera de copiador, el entrelazado o un orden de bytes intercambiado pueden desplazar o desordenar los campos aparentes. Los offsets de este artículo corresponden a la ROM normalizada, no a un contenedor con bytes adicionales.

Header fieldsCampos de la cabecera

OffsetBytesFieldCampo
0x100-0x10F16Console nameNombre de la consola
0x110-0x11F16Copyright / dateCopyright / fecha
0x120-0x14F48Domestic titleTítulo doméstico
0x150-0x17F48Overseas titleTítulo internacional
0x180-0x18D14Product code / versionCódigo de producto / versión
0x18E-0x18F2ChecksumChecksum
0x190-0x19F16Supported peripheralsPeriféricos compatibles
0x1A0-0x1A78ROM start / endInicio / fin de ROM
0x1A8-0x1AF8RAM start / endInicio / fin de RAM
0x1B0-0x1BB12Backup RAM descriptor / rangeDescriptor / rango de RAM de guardado
0x1BC-0x1C712Modem informationInformación de módem
0x1C8-0x1EF40Memo / reservedNotas / reservado
0x1F0-0x1FF16Region informationInformación regional

Ranges above are inclusive. Text fields have a fixed byte budget, and unused positions are commonly padded with spaces. Individual games may leave fields blank or use unusual values. Preserve those details when documenting a particular revision.Los rangos anteriores incluyen ambos extremos. Los campos de texto tienen un tamaño fijo en bytes y sus posiciones sobrantes suelen rellenarse con espacios. Algunos juegos dejan campos vacíos o utilizan valores particulares. Conserva esos detalles al documentar una revisión concreta.

Reading text and numbersLeer textos y números

Use the text pane of a hex editor for titles, but read address fields as big-endian integers. For example, the four bytes 00 1F FF FF represent 0x001FFFFF. They are not the characters of a decimal number. A title edit must overwrite within its field; inserting bytes would shift everything that follows.Utiliza el panel de texto del editor hexadecimal para los títulos, pero interpreta las direcciones como enteros big-endian. Por ejemplo, los cuatro bytes 00 1F FF FF representan 0x001FFFFF. No son los caracteres de un número decimal. Al editar un título debes sobrescribir dentro de su campo; insertar bytes desplazaría todo lo que viene después.

Illustrative 2 MiB ROM rangeEjemplo didáctico: ROM de 2 MiB
0x1A0: 00 00 00 00  -> 0x00000000
0x1A4: 00 1F FF FF  -> 0x001FFFFF

0x001FFFFF - 0x00000000 + 1 = 0x200000 bytes

Changing the header title does not redraw the title screen. Likewise, a peripheral marker does not implement controller support, and region text alone does not remove software region checks or adjust PAL/NTSC timing. Those behaviours depend on game code and hardware.Cambiar el título de la cabecera no redibuja la pantalla de inicio. Del mismo modo, un marcador de periférico no implementa compatibilidad con un mando, y el texto regional por sí solo no elimina comprobaciones regionales del programa ni ajusta los tiempos PAL/NTSC. Esos comportamientos dependen del código y del hardware.

Checksum and rangesChecksum y rangos

The conventional checksum is a 16-bit sum of big-endian words from offset 0x200 to the end of the ROM data, retaining the low 16 bits. The stored result is at 0x18E. The header itself is outside that summed region, so editing only its title does not change this conventional checksum.El checksum convencional es una suma de palabras big-endian desde el offset 0x200 hasta el final de los datos ROM, conservando los 16 bits inferiores. El resultado se almacena en 0x18E. La propia cabecera queda fuera de la región sumada, por lo que editar únicamente su título no modifica este checksum convencional.

If a hack expands the file, review the declared ROM end and checksum together. Also inspect the game's own validation routine: it may use a fixed range or additional checks. A matching checksum does not prove that pointers, compressed resources or game logic are correct, and successful emulator booting does not validate every header field.Si un hack amplía el archivo, revisa conjuntamente el final de ROM declarado y el checksum. Comprueba también la rutina de validación del juego: puede utilizar un rango fijo o controles adicionales. Un checksum correcto no demuestra que los punteros, recursos comprimidos o lógica del juego sean correctos, y arrancar en un emulador no valida todos los campos de la cabecera.

A practical inspection workflowFlujo práctico de inspección

  1. Record the ROM revision, file size and a hash before editing. Work on a copy.Registra la revisión, tamaño y hash de la ROM antes de editar. Trabaja sobre una copia.
  2. Confirm a linear big-endian image, then inspect the vectors and the 0x100-0x1FF header separately.Confirma que la imagen es lineal y big-endian; después inspecciona por separado los vectores y la cabecera 0x100-0x1FF.
  3. Decode fixed-width strings and numeric fields with the correct sizes. Compare the declared ROM range with the actual file.Decodifica cadenas de longitud fija y campos numéricos con su tamaño correcto. Compara el rango ROM declarado con el archivo real.
  4. Make one bounded edit, compare the resulting bytes and test the affected behaviour. Keep notes of anything the game handles differently.Haz una edición delimitada, compara los bytes resultantes y prueba el comportamiento afectado. Anota cualquier particularidad del juego.

ReferencesReferencias

SGDK: ROMHeader field definitionsMotorola M68000 User's Manual: reset and exception vectors