Technical articleArtículo técnico

Introduction to Compression on Mega DriveIntroducción a la compresión en Mega Drive

A publisher-neutral introduction to how Mega Drive games store, decode, and rebuild compressed resources.Una introducción neutral a cómo los juegos de Mega Drive almacenan, decodifican y reconstruyen recursos comprimidos.

PublishedPublicado

August 24, 202624 de agosto de 2026

DifficultyDificultad

BeginnerInicial

Reading timeTiempo de lectura

14 min read14 min de lectura

Why compression mattersPor qué importa la compresión

Compression is one of the quiet systems that makes many Mega Drive games possible. It affects how much data fits in the cartridge, but it also influences how resources are grouped, when they are loaded, how much RAM is reserved for temporary output, how data reaches VRAM, and how much CPU time the game spends rebuilding assets before they are used.La compresión es uno de esos sistemás discretos que hacen posibles muchos juegos de Mega Drive. Afecta a cuántos datos caben en el cartucho, pero también influye en cómo se agrupan los recursos, cuándo se cargan, cuánta RAM se reserva para la salida temporal, cómo llegan los datos a VRAM y cuánto tiempo de CPU dedica el juego a reconstruir recursos antes de usarlos.

A ROM can contain graphics, tilemaps, fonts, level layouts, menus, animation data, audio samples, tables, scripts, and other game-specific resources. Compression lets developers store those resources more efficiently, then reconstruct them only when the engine needs the usable form.Una ROM puede contener gráficos, tilemaps, fuentes, diseños de niveles, menús, datos de animación, samples de audio, tablas, scripts y otros recursos propios de cada juego. La compresión permite almacenarlos de forma más eficiente y reconstruirlos solo cuando el motor necesita la forma utilizable.

What gets compressed?Qué se comprime

Almost any structured resource can be compressed if the game has code to decode it later. Common candidates include graphics or tile data, tilemaps, fonts, animation data, level data, menu layouts, audio samples, lookup tables, and custom binary data used by a specific engine.Casi cualquier recurso estructurado puede comprimirse si el juego tiene código para decodificarlo después. Entre los casos habituales están los gráficos o datos de tiles, tilemaps, fuentes, datos de animación, datos de niveles, layouts de menús, samples de audio, tablas de consulta y datos binarios propios de un motor concreto.

GraphicsGráficos

Graphics define the actual pixel data for tiles or sprites. After decompression, this data is often arranged so it can be transferred to VRAM and interpreted by the VDP as tile graphics.Los gráficos definen los datos de píxeles reales de tiles o sprites. Después de descomprimirse, estos datos suelen quedar preparados para transferirse a VRAM e interpretarse por el VDP como gráficos por tiles.

TilemapsTilemaps

Tilemaps describe how tiles are arranged. They may also store tile indexes, palette selection, priority bits, and horizontal or vertical flipping. A tilemap is not the same resource as the graphics it references.Los tilemaps describen cómo se colocan los tiles. También pueden guardar índices de tile, selección de paleta, bits de prioridad y volteo horizontal o vertical. Un tilemap no es el mismo recurso que los gráficos a los que apunta.

Because those resources have different shapes, the same game may store graphics with one compression format and tilemaps with another. There is no rule that forces both to use the same algorithm.Cómo esos recursos tienen estructuras distintas, un mismo juego puede guardar gráficos con un formato de compresión y tilemaps con otro. No hay ninguna regla que obligue a usar el mismo algoritmo para ambos.

Compression is softwareLa compresión es software

The Mega Drive does not provide a universal decompression feature. The VDP does not automatically understand Nemesis, Enigma, Kosinski, Saxman, RNC, RefPack, Huffman streams, RLE blocks, or any other named format. Those names describe software schemes, not hardware modes.La Mega Drive no ofrece una función universal de descompresión. El VDP no entiende automáticamente Nemesis, Enigma, Kosinski, Saxman, RNC, RefPack, flujos Huffman, bloques RLE ni ningún otro formato con nombre. Esos nombres describen esquemás de software, no modos de hardware.

The game code must read the compressed bytes and reconstruct the original resource. In many cases that work is done by a Motorola 68000 routine, although a game can involve other code paths depending on its engine and asset pipeline.El código del juego debe leer los bytes comprimidos y reconstruir el recurso original. En muchos casos ese trabajo lo hace una rutina Motorola 68000, aunque un juego puede involucrar otros caminos de código según su motor y su pipeline de recursos.

Different games, different compression formatsJuegos distintos, formatos distintos

There is no single standard compression format for Mega Drive games. Different studios, publishers, engines, and tools could use different algorithms, custom variants of known ideas, or proprietary formats designed around the needs of one project.No existe un único formato estándar de compresión para juegos de Mega Drive. Distintos estudios, editoras, motores y herramientas podían usar algoritmos diferentes, variantes propias de ideas conocidas o formatos propietarios diseñados alrededor de las necesidades de un proyecto.

Names such as Kosinski, Nemesis, Enigma, Saxman, RNC, RefPack, Huffman-based formats, RLE, LZ-derived formats, BPE, and proprietary systems are useful examples of that diversity. At this level, the important lesson is not the internal syntax of each format, but the fact that Mega Drive software is full of different compression choices.Nombres como Kosinski, Nemesis, Enigma, Saxman, RNC, RefPack, formatos basados en Huffman, RLE, formatos derivados de LZ, BPE y sistemás propietarios sirven como ejemplos de esa diversidad. A este nivel, la lección importante no es la sintaxis interna de cada formato, sino el hecho de que el software de Mega Drive está lleno de decisiones de compresión distintas.

Multiple formats in a single gameVarios formatos en un mismo juego

One game can use several compression methods at the same time. It may use one format for graphical tile data, another for tilemaps, another for level layouts, and raw uncompressed data for small tables where compression would not be worth the overhead.Un mismo juego puede usar varios métodos de compresión a la vez. Puede usar un formato para los tiles gráficos, otro para los tilemaps, otro para los layouts de niveles y datos sin comprimir para tablas pequeñas donde la compresión no compensa el coste añadido.

Basic decompression flowFlujo básico de descompresión

Conceptual flow
ROM
  -> Compressed resource
  -> Decompression routine
  -> RAM or temporary buffer
  -> VRAM / game engine
Flujo conceptual
ROM
  -> Recurso comprimido
  -> Rutina de descompresión
  -> RAM o buffer temporal
  -> VRAM / motor del juego

Compressed data stored in ROM usually cannot be used directly by the VDP or by game logic. The game first decodes it into a usable form. Depending on the resource, the output may go to RAM, a temporary buffer, VRAM, or another engine-specific memory structure.Los datos comprimidos guardados en ROM normalmente no se pueden usar directamente por el VDP ni por la lógica del juego. Primero el juego los decodifica a una forma utilizable. Según el recurso, la salida puede ir a RAM, a un buffer temporal, a VRAM o a otra estructura de memoria propia del motor.

Compression flow for ROM hackingFlujo de compresión para romhacking

Reinsertion flow
Modified asset
  -> Encoder / compressor
  -> Compressed resource
  -> ROM
Flujo de reinserción
Recurso modificado
  -> Codificador / compresor
  -> Recurso comprimido
  -> ROM

This direction matters because a decompressor only solves extraction. It can let you inspect the original asset, but modifying that asset and putting it back usually requires a compatible encoder that produces a stream accepted by the original game decoder.Esta dirección importa porque un descompresor solo resuelve la extracción. Puede permitirte inspeccionar el recurso original, pero modificar ese recurso y volver a insertarlo normalmente exige un codificador compatible que produzca un flujo aceptado por el decodificador original del juego.

Recognizing compressed dataReconocer datos comprimidos

Compressed data often looks like arbitrary bytes when viewed directly. A graphic visible in-game may not appear in a tile viewer, or tile data may look meaningless until the game expands it. That does not necessarily mean the asset is encrypted or corrupted. It may simply be packed.Los datos comprimidos suelen parecer bytes arbitrarios cuando se miran directamente. Un gráfico visible en el juego puede no aparecer en un visor de tiles, o los datos de tiles pueden parecer sin sentido hasta que el juego los expande. Eso no significa necesariamente que el recurso esté cifrado o corrupto. Puede estar simplemente empaquetado.

  • A visible in-game asset cannot be found directly in the ROM.Un recurso visible en el juego no aparece directamente en la ROM.
  • A pointer leads to a small block that later expands into a much larger output.Un puntero lleva a un bloque pequeño que después se expande a una salida mucho mayor.
  • A routine reads bytes or bits sequentially and writes a larger output buffer.Una rutina lee bytes o bits secuencialmente y escribe un buffer de salida más grande.
  • Data is copied to RAM before being transferred to VRAM.Los datos se copian a RAM antes de transferirse a VRAM.
  • Several resources pass through the same decoding routine.Varios recursos pasan por la misma rutina de decodificación.

Some formats have recognizable signatures or headers, but many do not. Treat signatures as helpful clues, not as a universal method.Algunos formatos tienen firmas o cabeceras reconocibles, pero muchos no. Trata las firmas como pistas útiles, no como un método universal.

Identifying the decoderIdentificar el decodificador

Tracing flow
Resource pointer
  -> Loader
  -> Decoder
  -> Output buffer
Flujo de rastreo
Puntero del recurso
  -> Cargador
  -> Decodificador
  -> Buffer de salida

The most reliable method is often to follow the game code. Start from a resource pointer or loader, then trace the routine that consumes the bytes and writes the output buffer. Reverse engineering that decoder can reveal how commands are encoded, how lengths and offsets work, whether the stream uses bit-level reads, whether dictionary references exist, how run-length commands are represented, and how the end of the stream is detected.El método más fiable suele ser seguir el código del juego. Empieza desde un puntero o cargador de recurso y rastrea la rutina que consume los bytes y escribe el buffer de salida. La ingeniería inversa de ese decodificador puede revelar cómo se codifican los comandos, cómo funcionan longitudes y offsets, si el flujo usa lectura a nivel de bits, si existen referencias de diccionario, cómo se representan comandos RLE y cómo se detecta el final del flujo.

Decompression is only half the problemDescomprimir es solo la mitad del problema

A ROM hacker may successfully decode a resource and still be far from reinserting a modified version. Recompression introduces size limits, available ROM space, pointer relocation, alignment, bank boundaries, resource tables, loader assumptions, and decoder compatibility.Un romhacker puede decodificar correctamente un recurso y aún así estar lejos de reinsertar una versión modificada. La recompresión introduce límites de tamaño, espacio disponible en ROM, reubicación de punteros, alineación, límites de banco, tablas de recursos, suposiciones del loader y compatibilidad con el decodificador.

A valid encoder does not normally need to reproduce the exact byte stream produced by the original developer's compressor. The important requirement is that the original game decodes the new stream correctly and that the surrounding resource metadata still leads the loader to the right bytes.Un codificador válido normalmente no necesita reproducir exactamente el mismo flujo de bytes que generó el compresor original del desarrollador. El requisito importante es que el juego original decodifique correctamente el nuevo flujo y que los metadatos del recurso sigan llevando al loader a los bytes correctos.

Common compression familiesFamilias comunes de compresión

Run-Length EncodingRun-Length Encoding

Repeated values are stored as a value plus a repetition count. It is useful for repeated patterns, blank areas, simple map data, masks, or padding-like spans.Los valores repetidos se guardan como un valor más un contador de repeticiones. Es útil para patrones repetidos, zonas vacías, mapas simples, máscaras o tramos parecidos a relleno.

Dictionary / LZ compressionCompresión de diccionario / LZ

Repeated sequences are replaced with references to data that has already appeared. The key concepts are distance, length, and back-reference.Las secuencias repetidas se sustituyen por referencias a datos que ya han aparecido. Los conceptos clave son distancia, longitud y referencia hacia atrás.

Huffman codingCodificación Huffman

Frequently occurring symbols use shorter bit codes, while less frequent symbols use longer codes. This is a bit-level idea rather than a tile-specific format.Los símbolos frecuentes usan códigos de bits más cortos, mientras que los menos frecuentes usan códigos más largos. Es una idea a nivel de bits, no un formato específico de tiles.

Differential / delta encodingCodificación diferencial / delta

Values may be stored as differences from previous values instead of absolute values. This can work well when neighboring values change gradually.Los valores pueden guardarse como diferencias respecto a valores anteriores en vez de como valores absolutos. Puede funcionar bien cuando los valores cercanos cambian gradualmente.

Byte Pair EncodingByte Pair Encoding

Common pairs of values can be represented by replacement symbols. The decoder expands those symbols back into their original pairs.Pares comunes de valores pueden representarse mediante símbolos de sustitución. El decodificador expande esos símbolos de vuelta a sus pares originales.

Hybrid formatsFormatos híbridos

Real game formats often combine ideas: LZ plus bit flags, RLE plus literals, Huffman plus custom tokens, or differential coding plus entropy coding.Los formatos reales de juegos suelen combinar ideas: LZ con flags de bits, RLE con literales, Huffman con tokens propios o codificación diferencial con codificación de entropía.

Why so many formats?Por qué hay tantos formatos

Compression is always a trade-off. Developers balance compression ratio, decoder speed, encoder complexity, RAM requirements, 68000 CPU cost, ease of streaming, resource type, and the tools available to the team. A format that works well for graphics may be a poor fit for tilemaps or audio samples.La compresión siempre es un compromiso. Los desarrolladores equilibran ratio de compresión, velocidad del decodificador, complejidad del codificador, requisitos de RAM, coste de CPU 68000, facilidad de streaming, tipo de recurso y herramientas disponibles para el equipo. Un formato que funciona bien para gráficos puede ser mala elección para tilemaps o samples de audio.

Compression and the Motorola 68000Compresión y Motorola 68000

Most decompression routines are ultimately software executed by the game. On Mega Drive this often means Motorola 68000 code reading compressed data, maintaining counters or bit buffers, and writing decompressed bytes to RAM or a destination prepared for VRAM transfer.La mayoría de rutinas de descompresión son, en última instancia, software ejecutado por el juego. En Mega Drive esto suele significar código Motorola 68000 leyendo datos comprimidos, manteniendo contadores o buffers de bits y escribiendo bytes descomprimidos en RAM o en un destino preparado para transferirse a VRAM.

This introductory article does not need to dive into assembly syntax. Later Knowledge articles can analyze real decoding routines instruction by instruction, once the conceptual model is clear.Este artículo introductorio no necesita entrar en sintaxis ensamblador. Artículos posteriores de Knowledge pueden analizar rutinas reales de decodificación instrucción por instrucción cuando el modelo conceptual ya esté claro.

Typical reverse-engineering workflowFlujo típico de ingeniería inversa

  1. Identify the resource visible in-game.Identifica el recurso visible en el juego.
  2. Locate references or pointers to its data.Localiza referencias o punteros a sus datos.
  3. Follow the loading routine.Sigue la rutina de carga.
  4. Identify or reverse engineer the decoder.Identifica o haz ingeniería inversa del decodificador.
  5. Decompress the resource.Descomprime el recurso.
  6. Determine the uncompressed format.Determina el formato descomprimido.
  7. Modify the resource.Modifica el recurso.
  8. Recompress it using a compatible encoder.Recomprímelo con un codificador compatible.
  9. Reinsert or relocate the data.Reinserta o reubica los datos.
  10. Test the result on emulator and, when possible, real hardware.Prueba el resultado en emulador y, cuando sea posible, en hardware real.

Where to go nextDónde seguir

68K Revival documents specific compression formats and implementations separately. Once the general flow is clear, the next step is to study individual algorithms, real decoders, and publisher-specific systems in their own articles.68K Revival documenta formatos e implementaciónes concretas de compresión por separado. Cuando el flujo general está claro, el siguiente paso es estudiar algoritmos individuales, decodificadores reales y sistemás específicos de editoras en sus propios artículos.