Atari 2600 TIA: Los Pestillos de Colisión Potencian la Detección de Sprites en Raiders of the Lost Ark

Dentro de un clásico de 8 KB con cambio de banco F8: pestillos por píxel, líneas de escaneo de 76 ciclos, y flujos de trabajo de emuladores que explican cada golpe, recogida y deslizamiento por la pared.

Puedes sentirlo en el momento en que Indy roza una pared o su “mano” en pantalla arranca un artefacto de un pedestal: Raiders of the Lost Ark en el Atari 2600 vive y muere por colisiones a nivel de hardware. No por cajas delimitadoras. No por físicas complejas. El juego se apoya en los pestillos de colisión del TIA—pequeñas basculaciones que se establecen cuando los píxeles en pantalla se encuentran en el mismo instante durante una línea de escaneo. Esos pestillos impulsan silenciosamente cada golpe, recogida y deslizamiento en un juego de 1982 comprimido en 8 KB de ROM y 128 bytes de RAM.

Eso no es nostalgia; es un diseño dictado por el hardware. La CPU 6507 del 2600 tiene 76 ciclos para atender cada línea de escaneo mientras el TIA dibuja la imagen en el televisor. La lógica del juego que no esté perfectamente sincronizada corre el riesgo de rasgar la pantalla. La detección de colisiones tenía que ser “gratuita” durante el dibujo y económica de consumir después. Raiders cumple con un modelo que es definitivo en este sistema: verdadero a nivel de píxel, por parejas, latente hasta ser limpiado, e independiente de la prioridad de dibujo. Comprenderlo aclara cómo los emuladores replican el comportamiento, cómo los hacks permanecen compatibles y qué necesitaría emular o reemplazar un remake fiel en un motor moderno.

Las limitaciones que dictaron la estrategia de colisión de Raiders

Raiders es un cartucho de 8 KB que utiliza cambio de banco de estilo F8—un esquema común del 2600 que alterna entre dos bancos de 4 KB dentro del pequeño espacio de direcciones visible de 4 KB del 6507. La RAM del sistema es de solo 128 bytes. El TIA dibuja el video directamente; el “núcleo” del juego debe configurar las posiciones de los sprites y los datos del campo de juego línea por línea de escaneo, dentro de los 76 ciclos de CPU por línea. La mayoría de la lógica del juego real, incluidas las decisiones de colisión, se ejecuta en los períodos no visibles: blanco vertical y sobreescaneo.

Esas limitaciones hacen imprácticas las colisiones de software. Las máscaras de bits por sprite o las comprobaciones de cajas delimitadoras barridas costarían ciclos y espacio de código que el juego no tiene, y complicarían el núcleo sincronizado con la línea de escaneo. Mientras tanto, Raiders también debe manejar dos joysticks: uno mueve a Indy; el segundo manipula la “mano” en pantalla, un interactuador similar a un cursor para los elementos. Esa división se mapea perfectamente al conjunto limitado de objetos dibujables del TIA y su sistema de colisión por hardware.

Cómo funcionan los pestillos de colisión TIA—y por qué son definitivos

El TIA proporciona detección de colisiones en hardware. Cuando dos píxeles opacos de diferentes clases de objetos TIA se superponen en el mismo reloj de color durante la pantalla activa, se establece un pestillo correspondiente. La CPU lee estos pestillos a través de direcciones dedicadas y los borra explícitamente a través de un solo registro de reinicio. Lo crucial es que los pestillos reflejan la superposición física, no lo que aparece visualmente delante; la prioridad de la pantalla no suprime la detección de colisiones.

Los registros de colisión:

• CXM0P ($30): Misil 0 con Jugador 0/1
• CXM1P ($31): Misil 1 con Jugador 0/1
• CXP0FB ($32): Jugador 0 con Campo de juego/Bola
• CXP1FB ($33): Jugador 1 con Campo de juego/Bola
• CXM0FB ($34): Misil 0 con Campo de juego/Bola
• CXM1FB ($35): Misil 1 con Campo de juego/Bola
• CXBLPF ($36): Bola con Campo de juego
• CXPPMM ($37): Jugador 0 con Jugador 1 y misil–misil

Los pestillos se limpian escribiendo en CXCLR ($2C). Semánticamente, cada bit significa “desde la última limpieza, ocurrió al menos una superposición”. No hay ubicación, no hay cuenta y no hay orden temporal en ese cuadro, solo sí/no para ese par.

La razón por la que esto es definitivo en el 2600 es simple: las comprobaciones de colisión ocurren enteramente en el TIA mientras la CPU “corre contra el rayo”. Después de la porción visible, la CPU necesita solo unas pocas lecturas para saber qué tipos de objetos se tocaron en cualquier punto de ese cuadro.

Mapeando a Indy, la “mano”, y el mundo a los objetos del TIA

Un juego del 2600 tiene cinco tipos de objetos movibles: dos jugadores (P0, P1), dos misiles (M0, M1) y una bola (BL), además del campo de juego grueso y espejado (PF). Raiders los usa de una manera coherente con su diseño y la práctica contemporánea del 2600:

• Indy y grandes PNJs: Sprites de jugadores (P0/P1). Las colisiones con el terreno y la bola aparecen en CXP0FB/CXP1FB; las superposiciones jugador–jugador se registran en CXPPMM.
• El cursor de la “mano”: un misil o la bola. Muchos títulos del 2600 utiliza un misil o la bola como puntero porque el hardware puede posicionarlo independientemente y sus colisiones se exponen en los mismos registros CX. Con la segunda “mano” del joystick en Raiders, detectar “el cursor toca el objeto” o “el cursor sobre una facilidad ambiental” se deriva de CXM0P/CXM1P (misil–jugador), CXM0FB/CXM1FB (misil–campo de juego/bola), o, si se usa la bola para el cursor, a través de los bits relacionados con FB en los registros de jugador/misil y CXBLPF para bola–campo de juego.
• El mundo: Campo de juego para muros, barreras y siluetas de habitaciones. El bloqueo, la conducta de deslizarse por las paredes y los desencadenantes de puertas derivan de colisiones jugador/misil/bola contra el campo de juego—los registros CXFB y CXBLPF.

Este mapeo permite que el núcleo de dibujo haga la parte costosa—generar píxeles; el TIA establece pestillos pasivamente, y Raiders interpreta unos pocos bits por cuadro para decir lo que ocurrió.

Filtrando, ordenando y dando sentido a superposiciones ambiguas

El TIA solo te dice que ocurrió una colisión “al menos una vez desde la última limpieza”. Si Indy rozó una pared y simultáneamente se superpuso a un resaltado basado en una bola, CXP0FB iluminará ambos bits, pero la CPU no puede decir cuál ocurrió primero ni dónde. Tampoco importa la prioridad de la imagen: una colisión puede registrarse incluso si un sprite se dibuja “detrás” de otro debido a configuraciones de prioridad.

Raiders maneja esa minimalidad en software:

• Limpiar en el momento adecuado: Escribe CXCLR justo antes del segmento de pantalla donde las interacciones importan o al inicio del marco visible, de manera que los pestillos solo capturen contactos relevantes.
• Leer una vez por cuadro: Durante el blanco vertical/sobreescaneo, lee CXM0P…CXPPMM y elimina bits irrelevantes dependiendo del estado del juego (por ejemplo, ignora misil–PF si la mano está deshabilitada en una habitación).
• Aplicar una prioridad fija: Decide peligros antes de recogidas antes del entorno, o cualquier orden determinista que tenga sentido. Dado que el hardware no suministra una lista de eventos, el juego impone políticas: impactos letales preceden a todo; las recogidas requieren tanto contacto como un estado de “intención”; los rebotes ambientales o restricciones de posición aparecen al final.

Esa política es lo que los jugadores sienten como interacción consistente y predecible incluso cuando múltiples superposiciones son ambiguas en el fondo.

Contacto binario, umbrales y casos marginales de líneas de escaneo

No hay un radio ajustable o “proximidad” en el 2600—el contacto es binario y preciso por píxel. Para evitar disparos titilantes incorrectos, los juegos a menudo se basan en la persistencia: requiere que el mismo pestillo se establezca a lo largo de múltiples cuadros consecutivos, o solo cuando la intención de movimiento coincide (por ejemplo, solo recoge si la mano se superpone a un objeto y el jugador presiona la acción del segundo joystick). La dinámica mano-y-objeto de Raiders prácticamente exige este tipo de puertas adicionales.

Algunos casos extremos importan:

• Rozaduras de una sola línea de escaneo: Una superposición de una sola línea establece el pestillo en ese cuadro. Si el juego no filtra, rozar un peligro una línea se ve como un golpe. Las comprobaciones multiplano ayudan a suavizar contactos de roce.
• Posicionamiento horizontal sub-pixel: HMOVE posiciona con precisión y los desplazamientos de 4 bits firmados de HMPx significan que los pestillos corresponden a desplazamientos verdaderos en pantalla, no a pasos de cuadrícula de byte grueso. Eso hace que la detección de colisiones sea precisa sin trabajo adicional de la CPU.
• Escasez vertical: Si el arte alterna líneas de escaneo o se dibuja especialmente delgado, hay menos oportunidades para la superposición de píxeles, lo que puede hacer que las interacciones se sientan menos “pegajosas”. Los actores principales generalmente se dibujan en cada línea de escaneo relevante para minimizar el “tunelado” interno al cuadro.

En otras palabras: las colisiones son exactas a los píxeles que ves, línea por línea, con todas las fortalezas y peculiaridades que eso implica.

Resolución y sincronización: dónde Raiders maneja realmente las colisiones

Un núcleo estable no puede permitirse sorpresas a mitad de cuadro. El 2600 te da 76 ciclos por línea visible para establecer los gráficos de la línea siguiente; sobrepasar ese presupuesto arriesga perder la sincronización. Raiders difiere la resolución a las zonas seguras:

• Limpia pestillos una vez por cuadro, a menudo temprano.
• Dibuja el cuadro visible mientras el TIA establece automáticamente los pestillos de colisión.
• Durante el blanco vertical/sobreescaneo, lee los registros CX una vez, aplica filtrado y ordenamiento de software, luego resuelve.

La resolución en sí misma es consciente del presupuesto: clamp-o-desliza para jugador-contra-pared, revierte-solo-el-eje-ofensor si un movimiento penetraría el campo de juego, luego procesa ítems y desencadenantes cosméticos. El resultado es esa sensación familiar de “deslizarse por las paredes”, nacida tanto por necesidad como por diseño.

Por qué los pestillos ganan en rendimiento y memoria

En un sistema con 128 bytes de RAM y 8 KB de ROM, los pestillos de colisión del TIA son un golpe de eficiencia:

• Son esencialmente gratuitos durante el dibujo. El TIA los establece mientras se componen los píxeles.
• El costo para consumir es minúsculo. La CPU lee unas pocas direcciones en blanco vertical/sobreescaneo y escribe una clara.
• Preservan la estabilidad del núcleo. No hay bucles a mitad de cuadro ni pruebas matemáticamente pesadas que interrumpan el presupuesto de 76 ciclos.

Contrasta eso con las colisiones de software: pruebas de máscara de bits por línea de escaneo para cada par de sprites o una cuadrícula de azulejos gruesos harían explotar el ROM y los ciclos. La detección continua de colisiones para prevenir el tunelado interno al cuadro—común en los motores modernos—es redundante en el 2600 porque las superposiciones se evalúan a la granularidad con que se dibuja la pantalla.

Peculiaridades y notas regionales que afectan la percepción, no la lógica

Algunas realidades moldean cómo los jugadores perciben las colisiones sin cambiar la lógica subyacente:

• NTSC vs. PAL: El conteo de líneas, la paleta y la cadencia difieren por región, pero la semántica de colisión del TIA es idéntica. Si PAL se siente un poco más “suelto” o “pegajoso”, se debe a la sincronización total del cuadro y diferencias visuales, no a un cambio en cómo se establecen los pestillos.
• Golpes ocultos: Porque la colisión ignora la prioridad de dibujo, puede registrarse una superposición incluso si un objeto está visualmente oculto por otro con prioridad más alta. Es un clásico problema del 2600 y puede sorprender durante hacks o al depurar golpes inesperados.
• Pestillos obsoletos: Olvidar limpiar a través de CXCLR lleva colisiones a través de cuadros, resultando en recogidas fantasma o paredes que parecen permanentemente “sólidas”. Es lo primero que se verifica cuando el comportamiento se vuelve extraño.

Estos no son errores en emuladores o revisiones de ROM; son endémicos a cómo funciona el TIA.

Pruebas y depuración en 2026: Stella, Gopher2600, y Distella

La cadena de herramientas actual hace transparente la maquinaria de colisiones de Raiders—sin tocar el ROM:

• El depurador de Stella expone los registros de colisión en vivo. Puedes establecer puntos de interrupción en lecturas/escrituras de CX, observar CXM0P…CXPPMM voltear conforme avanza el cuadro, e incluso “interrumpir cuando CXP0FB!= 0” para situarte en el código exacto de blanco vertical que maneja el choque Indy-contra-paredes. Ver cuadro por cuadro convierte esos pestillos abstractos en decisiones concretas.
• Gopher2600 enfatiza el comportamiento del TIA preciso al ciclo y la colocación de objetos por línea de escaneo. Eso es perfecto para validar cuándo podría ocurrir una superposición, especialmente con núcleos estrictos o gráficos que solo iluminan ciertas líneas.
• Distella desensambla el ROM de Raiders. Buscar lecturas de $30–$37 y escrituras a $2C señala el manejo de colisiones y el orden de resolución del juego. Estos anclajes son donde los hacks tienen éxito—respetando tiempo y estado—o chocan contra limitaciones invisibles.

Juntos, estos flujos de trabajo reflejan la mejor práctica orientativa de las guías de programación clásicas añadiendo observabilidad moderna. También subrayan un punto clave: ejecutar el ROM original en emulación preserva el comportamiento de colisión exactamente porque la lógica vive en el modelo TIA, que los emuladores reproducen por píxel y por línea de escaneo.

Emulación, hacks de ROM, y lo que realmente haría un remake moderno

Ejecuta Raiders bajo Stella o Gopher2600 y obtienes el mismo sistema de colisión per-píxel, latente hasta ser limpiado, con la misma sincronización. Los emuladores replican el pipeline de composición del TIA y el comportamiento del pestillo; las lecturas y limpiezas del ROM ocurren en los mismos lugares relativos al cuadro. La ventaja práctica en 2026 es mejor instrumentalización, no diferente jugabilidad.

Los hacks del ROM que retocan el arte, colores, mapas, o pequeñas reglas pero retienen el motor original heredan semánticas de colisión idénticas. Aún leen CXM0P…CXPPMM y escriben en CXCLR en las mismas ventanas de cuadros y están limitados por la misma ambigüedad “desde-última-limpieza”. Los hacks que reutilizan la mano, intercambian qué jugador representa a Indy, o rediseñan habitaciones deben respetar este pareo y temporización o enfrentarse a fallas desconcertantes: golpes invisibles por independencia de prioridad, o estados fantasma por limpiezas perdidas.

Un remake desde cero con la etiqueta “Raiders2600” enfrentaría una elección. Si embebe el ROM original y un núcleo 2600, las colisiones se reducen al modelo TIA por diseño. Si no lo hace, debe reemplazar los pestillos con software:

• Amplia fase AABB para jugador-contra-mundo, con pruebas de máscara estrecha para recogidas precisas.
• Comprobaciones barridas/continuas para prevenir tunelado a velocidades más altas—innecesario en el 2600 porque las superposiciones ocurren línea de escaneo por línea de escaneo.
• Filtrado de capas/máscaras para reflejar el esquema por parejas del TIA pero con control más rico.
• Una simulación de pasos de tiempo fijos para estabilizar respuestas—similar en espíritu a la cadencia bloqueada por cuadro del original.

El resultado podría sentirse notablemente similar, especialmente con resolución de clamp-y-deslizar y un orden de eventos determinista, pero sería una reimplementación más que reutilización del mecanismo original.

Un veredicto conciso sobre el modelo de colisión de Raiders

Raiders of the Lost Ark en el Atari 2600 es un estudio de caso en dejar que el hardware haga el trabajo pesado. Los pestillos de colisión por píxel del TIA—establecidos en el instante en que dos clases de píxeles se superponen, indiferentes a la prioridad de dibujo, y latentes hasta ser limpiados explícitamente—impulsan un espectro completo de interacciones: paredes que empujan a Indy a un lado, peligros que tienen prioridad, y una mano de segundo joystick que “toca” tesoros.

Tres decisiones de diseño hacen que funcione:

• Aceptar la verdad binaria, por cuadro: un puñado de bits CX leídos una vez en blanco vertical/sobreescaneo y un orden de software disciplinado para resolver la ambigüedad.
• Mantener la lógica fuera del núcleo: dibujar durante el presupuesto de 76 ciclos; pensar durante el enmascaramiento.
• Gastar ciclos donde cuentan: sin pruebas de píxeles por software; resoluciones de clamp-y-deslizar que son estables y económicas.

Para emuladores y hacks, el mandato es simple: preservar las semánticas de los pestillos y la sincronización y todo encajará. Para un remake, el objetivo está claro: replicar el contacto por píxeles y la resolución determinista, o enviar el ROM original dentro de un núcleo fiel.

La lección perdurable es que las restricciones generan claridad. El modelo de colisión de Raiders no solo es correcto para la época—es una clase magistral en obtener interacciones decisivas por píxel de forma gratuita, y luego hacer lo justo en software para hacerlas sentir como una aventura. 🎮

Apéndice: Referencia rápida de registros de colisión

Registro	Par(es) latched
CXM0P ($30)	Misil 0 con Jugador 0/1
CXM1P ($31)	Misil 1 con Jugador 0/1
CXP0FB ($32)	Jugador 0 con Campo de juego/Bola
CXP1FB ($33)	Jugador 1 con Campo de juego/Bola
CXM0FB ($34)	Misil 0 con Campo de juego/Bola
CXM1FB ($35)	Misil 1 con Campo de juego/Bola
CXBLPF ($36)	Bola con Campo de juego
CXPPMM ($37)	Jugador 0 con Jugador 1; misil–misil

Fuentes y Referencias